Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-07-18 14:22:26


> 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.

atomic_t is a different story.. correct usage of spinlocks
is very limited, indeed. however, they are PORTABLE and are
already defined in IEEE Std 1003.1j-2000 standard and they
will become part of the coming IEEE POSIX 1003.1-2001? standard.

http://groups.google.com/groups?as_umsgid=vnU47.809%24rc5.60740%40news.cpqcorp.net

"A spinlock is a machine-specific "optimized" form of mutex ("MUTual
 EXclusion" device). However, you should never use a spinlock unless you
 know that you have multiple threads and that you're running on a
 multiprocessor. Otherwise, at best you're wasting a lot of time. A
spinlock
 is great for "highly parallel" algorithms like matrix decompositions,
where
 the application (or runtime) "knows" (or at least goes to lengths to
 ensure) that the threads participating are all running at the same time.
 Unless you know that, (and, if your code doesn't create threads, you CAN'T
 know that), don't even think of using a spinlock."

regards,
alexander.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk