Boost.Threads - 'lock' name (was Re: Boost.Thread

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

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

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