On 3/4/2014 11:55 AM, Jon Elson wrote: > 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. And of course, this is the way ring buffers work when the number of buffers is two.
Ken > > 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 ------------------------------------------------------------------------------ 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
