Re: RFC: Multithreading design constraints

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-06-05 10:23:45

--- In boost_at_[hidden], scleary_at_j... wrote:
> > Issue 7:
> > Emulation slowdown:
> > There are many different kinds of locks, only some of which will 
be
> > natively available on a given platform.
>
> Although I do not think that we will have situations where we will 
want to
> choose at compile-time whether to use a RWLock or just a Mutex, 
based on
> what's available.  I think our code should choose the sync
primitive 
that
> satisfies our need, and if there's native code for it, use that, 
otherwise
> use the emulated code.  (So I don't think we need a 
synchronization_traits
> class).

I also have to agree with Steve here. is_specialised() is directly 
breaking encapsulation rules. The application should *not* know how a 
class is implemented. Avoiding performance hit must be dealt with in
a different way.

> There's another dimension of considerations.  Can the lock be used 
> as a "signal"?  For example, if thread A owns a mutex, can it wait 
> on that mutex until thread B "releases" it?  It's been a few years 
> since I've worked on UNIX, but I don't think that was an issue.  
> But under Win32, if you do that a few times, you BSOD.  That's why
> I made a distinction above between a "Mutex", which I define as 
> only releasable if you own it, and a "Binary Semaphore", which can
> be used as a "signal".

Why don't we have have 'signal'? Win32 has 'events' which do almost 
exactly that. Or maybe you think that 'binary semaphore' is a better 
name for it? I personally prefer signal, because that is exactly what 
we need, a signal from one thread to another. With signal in place, 
semaphores of any magnitude can be implemented in terms of signal.

Cheers,

Miki.