On 03/04/2014 06:59 AM, andy pugh wrote: > On 4 March 2014 12:52, Stuart Stevenson <[email protected]> wrote: > >> Gentlemen, >> It would help me understand and follow some of the current threads if I >> knew the definition of atomic as used in this context. > > It refers to the original meaning of "atomic", "can not be cut". > > Unless steps are taken to prevent it, it would be possible for the base > thread to interrupt the servo thread while it was half-way through writing > a new value to a variable, the value read from memory would be some bytes > from the new number combined with some bytes from the old number. The value > read would potentially be completely wrong. This is probably only true when the program needs to store a value of greater length thanthe write (store) instruction does at one time. For instance, a store 32-bit woord instruction can be used to write a 64-bit floating point variable in two parts. An interrupt could stop the process between the two sequential writes, and the other process could read a fractured value. This is ALL extremely hardware-dependent, what is automatically atomic on one CPU may be completely impossible to make atomic on another, without masking off all interrupts. And, it can get even messier on multi-core systems. > > The problem is slightly more complicated here, as we need to make sure that > complete sets of numbers that are related to each other are written as-one > with no danger of an interrupting thread reading a bad combination. > And, this then produces another level of "atomic" that hardware really cannot solve. If you can't guarantee the fast thread is not interrupted, then you have to use semaphores to flag some region as "in flux" and hold off the faster thread from using it until the slower thread has finished the updating. This is NOT a great way to do things, as deadlocks or "deadly embrace" problems can develop.
Another way this can be dealt with is to have double buffers shared between the two tasks, the "master" task swaps out a pointer to the most recent buffer when it is ready to be used by the "slave" task. Not sure that is a great way to do things, but it alleviates the deadlock situation. Jon ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
