Thread safety issue (I think) with defaultdict

[Gene Heskett]

On Friday 03 November 2017 10:50:13 Chris Angelico wrote:

> On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James <rhodri at kynesim.co.uk> 
wrote:
> > On 02/11/17 20:24, Chris Angelico wrote:
> >> Thank you. I've had this argument with many people, smart people
> >> (like Steven), people who haven't grokked that all concurrency has
> >> costs - that threads aren't magically more dangerous than other
> >> options.
> >
> > I'm with Steven.  To be fair, the danger with threads is that most
> > people don't understand thread-safety, and in particular don't
> > understand either that they have a responsibility to ensure that
> > shared data access is done properly or what the cost of that is. 
> > I've seen far too much thread-based code over the years that would
> > have been markedly less buggy and not much slower if it had been
> > written sequentially.
>
> Yes, but what you're seeing is that *concurrent* code is more
> complicated than *sequential* code. Would the code in question have
> been less buggy if it had used multiprocessing instead of
> multithreading? What if it used explicit yield points? Multiprocessing
> brings with it a whole lot of extra complications around moving data
> around. Multithreading brings with it a whole lot of extra
> complications around NOT moving data around. Yield points bring with
> them the risk of locking another thread out unexpectedly (particularly
> since certain system calls aren't async-friendly on certain OSes). All
> three models have their pitfalls. It's not that threads are somehow
> worse than every other model.
>
> ChrisA

I think that this discussion of threads and threading must be a different 
context than threading as I am using it in linuxcnc.

There, one assigns a function to run in a certain sequence in an assigned 
thread, which there can be several of. There, each thread is assigned a 
repetition rate, and the higher repetition rate stuff can always 
interrupt the slower threaded function in order to get the real time 
stuff done in a usable for the job time frame, and the high frequency 
thread can be as fast as every 25 microseconds on a good motherboard.  
Surprisingly, this seems to be far more board dependent than processor 
dependent, altho its pushing an AMD processor quite hard at 40 
microseconds, while the slower intel atoms can do 25 microseconds with 
about the same effort.

This is where a stepper motor is being stepped by software which didles 
pins on a parport. And it limits how fast you can move the motor 
compared to using an fpga card running at 200 MHz, not because of the 
step rate, but because of the latency of the mobo/cpu combination.

Jitter in step rate issuance is death to high performance with stepper 
motors because torque to do usefull work vanishes when the instant speed 
of the motor is wobbling with that timing jitter.

OTOH, hand controls of a machine using an encoder dial are nicely done in 
a thread running at 100 Hz, far more reliably that I can do it from the 
keyboard on a raspberry pi 3b. Why? The dials data goes into linuxcnc by 
way of a hardware fpga card that talks to the pi over an SPI buss, with 
the pi writing 32 bit packets at 41 megabaud, and reading the results at 
25 megabaud. It doesn't have to get thru that usb2 internal hub in the 
pi that all the other i/o has to go thru. Mouse and keyboard events get 
dropped on the floor, particularly dangerous when its a keyup event that 
gets dropped. The machine keeps moving until it crashes into something, 
often breaking drive parts or cutting tooling, all of which cost real 
money.

My point is that with an interpretor such as hal managing things, threads 
Just Work(TM).

It does of course take a specially built kernel to do that magic.
I'll get me coat.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>