Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-07-18 14:38:02

--- In boost_at_y..., Jeremy Siek <jsiek_at_r...> wrote:
> On Wed, 18 Jul 2001 williamkempf_at_h... wrote:
> > Spin locks are inherantly non-portable (on some platforms I'd
> > 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
> > 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
> > served by a mutex.
> Suppose that I'm a programmer who only writes code for an operating
> 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.

Well, do note that I said that I doubted it would be a part of
Boost.Threads, not that it was a certainty.

That said, you've said nothing here to convince me that Boost.Threads
should provide a spinlock. If you want a spinlock in your situation
then I see nothing wrong with your rolling your own. After all, the
interface is clearly specified already, since this is just an
optimized form of a Mutex concept. So for your non-portable case
rolling your own is trivial, while creating a version for
Boost.Threads becomes a very daunting task as you try and provide an
implementation for as many platforms as possible.

In other words, I see a lot of very difficult work with little
benefit. If someone else feels strongly about this and wants to take
on the work, fine, but I highly doubt that you'll convince me to do
so. A spinlock is too low level and platform specific to be of use
in most situations.

> A note about "portability": When designing a peice of software, if
> are two alternative designs, one that is portable and one that is
> non-portable, then obviously the choice is to go with the portable
> However, if you are designing a peice of software (like spin lock)
> all the alternatives are non-portable, then "portability" is not an

Ah, but any where you use a spinlock you can use a semaphore or mutex
instead. The only benefit of a spinlock is in optimizing performance
of lock operations. However, you will often find the semaphore or
mutex to be faster than a spinlock any way, it's only for very
specific uses in which a spinlock can provide any benefit. So your
arguments here are weak when taken at face value.

> 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
> intended to be portable.

No, non-portable software isn't inherantly evil. But the goal of
Boost.Threads is to provide a portable library of concepts for multi-
threaded programming, so a non-portable concept isn't in keeping with
the library's goals.

Bill Kempf

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