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
> > 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
> performance critical but low contention situation that really
> use of spin locks. Should I be able to turn to Boost.Threads for
> lock, or do I have to write my own? I think the answer should be
> can go to Boost.Threads.
> If you don't put spinlock into Boost.Threads then I'll just submit
> 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
> works on. Non-portable software is not inherently "evil". There's
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk