Tony,
Where XCHG ("exchange') is an atomic operation [...]
thanks heaps for the detailed explanation. That makes a lot more sense to me now. Are there any books on this whole subject matter, you could suggest?
Typically you shouldn't use spinlocks, unless you are working really low level and know what you are doing, and if do_work() is very short - ie a few processor instructions.
Well, what I am doing is setting two boolean flags. This happens in an app where interactivity/responsiveness if of utmost importance. I'm writing a plugin for this app. I find using the locking with shared- and unique locks giving me no noticable performance issues on Linux. However, with the same app, on OSX, I experience intolerable slowdowns (which disappear when I remove all locking code -- with the expected "side effects" on stability). That's why I am looking into spinlocks. Also, most libraries I use in this project (e.g. OpenImage IO -- http://www.openimageio.org/ and PTex -- http://ptex.us/), do use spinlocks more or less exclusively. And the operations they protect by these locks are absolutely comparable to what I do.
Once you are experienced with MT programming, STILL stick to simple mutex locking/unlocking.
So why would these people use spinlocks? Some of the people working on these libs do have quite extensive backgrounds in writing multi-threaded apps. Namely 3d renderers. .mm