Something as simple as incrementing an integer can fail in a concurrent environment. This article illustrates the failure scenario and introduces the PowerPC’s coping mechanism: atomic instructions. Learn how to close the Window of Death with these assembly-level instructions to update memory correctly, even in the face of concurrency.
PowerPC atomic instruction prevents code meltdown
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Isn’t this basic thread safety? I mean, InterlockedIncrement and friends have existed forever on Windows/x86. While interesting articles are good to see, I’d have to agree with Yousef that this isn’t actually news. It’s just a minor detail of how threading libraries are implemented.
Everyone who knows even just a bit about concurrency knows that you need atomic instructions for that.
So after using 2/3rds of the article to present stuff from any operating systems course, the author presents a solution and marks it as non-production code (because ‘real’ code needs sync instructions, but the author doesn’t say where), so the reader can’t apply the article.
Overall this was just a wasted couple of minutes for me (but then so are most IBM articles, probably to any programmer who has a clue about C or C++).
inc [gConnectCount]
Be careful. Inc isn’t automatically atomic on x86
You need to use the ‘lock’ prefix for that.
I actually liked this article. PPC’s synchronization instructions seem interesting compared to x86’s. The ability to perform arbitrary operations on a value while the “lock” is held seems a lot more flexible than only having fixed operations like ‘inc’, ‘dec’, ‘xchg’, etc.
I suspect Luke is too used to single processor systems
(inc [mem] should work perfectly as an atomic instruction there without a lock prefix, but for multicpu you really do need lock)
Will those cpu read the “RESERVATION FLAG”? I mean each cpu will have each one set of registers, but it wasn’t clear from the article whether the RESERVATION FLAG is shared among the cpu’s.
Imagine Xbox2, it’s powered with that processor, and has more than one cpu. Rumours are saying PS3 might use that (cell might be based on that)… And gamecube was PowerPC user…
I suspect Luke is too used to single processor systems
Admittedly I know nil about multi CPU programming.
While the current CPU is not the bus master, it monitors the memory access from other devices and can stop the memory access and transfer the data from it’s own cache instead.
Thus the current CPU places a reservation on the memory address, if the processor sees any other device accessing the memory, then the reservation is released. Also, note that the store checks to make sure the reservation is still in effect.
So you have two processors. One sets a reservation on a memory cell. Then the other sets a reservation on the memory cell, clearing the first reservation.
Okay, so the first CPU does a conditional store, which fails, and loops back to try again. It grabs the reservation, which clears the reservation of the 2nd CPU.
Then the 2nd CPU does a conditional store, which fails, and loops back to try again. Isn’t a pair of infinite loops theoretically possible here?
Caj