Re: [Boost-users] Q: N00b spinlock

Subject: Re: [Boost-users] Q: N00b spinlock
From: Moritz Moeller (boost_at_[hidden])
Date: 2010-01-21 00:38:42

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