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.