Boost logo

Boost :

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
> > 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
> satisfies our need, and if there's native code for it, use that,
> use the emulated code. (So I don't think we need a
> 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.



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