Boost logo

Boost :

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-07-18 14:09:05

On Wed, 18 Jul 2001 williamkempf_at_[hidden] wrote:
> Spin locks are inherantly non-portable (on some platforms I'd expect
> it to be impossible to have a spinlock for the same reasons that
> atomic_t is difficult to implement, only that the ways to work around
> it will result in something that's not truly a spinlock any way).
> More importantly, code that makes use of a spin lock is not likely to
> be in code that's portable, since most portable code will be better
> served by a mutex.

Suppose that I'm a programmer who only writes code for an operating system
X for which it is possible to write a good spin lock and suppose I have a
performance critical but low contention situation that really requires the
use of spin locks. Should I be able to turn to Boost.Threads for the spin
lock, or do I have to write my own? I think the answer should be that I
can go to Boost.Threads.

If you don't put spinlock into Boost.Threads then I'll just submit it to
boost separately.

A note about "portability": When designing a peice of software, if there
are two alternative designs, one that is portable and one that is
non-portable, then obviously the choice is to go with the portable design.
However, if you are designing a peice of software (like spin lock) where
all the alternatives are non-portable, then "portability" is not an issue.
You just write some non-portable software and tell people which OS's it
works on. Non-portable software is not inherently "evil". There's lots of
perfectly good software out there that is not portable, and was never
intended to be portable.


 Jeremy Siek www:
 Ph.D. Candidate, IU B'ton email: jsiek_at_[hidden]
 Summer Manager, AT&T Research phone: (973) 360-8185

Boost list run by bdawes at, gregod at, cpdaniel at, john at