Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-24 10:38:18

--- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> William Kempf wrote:
> > > I'm sure that the requirement of lock the mutex during notify
is not
> > > expensive and has no any other disadvantage while we can be more
> > platform
> > > and os-thread library independent so IMHO this have to be a
> > requirement.
> >
> > The overhead can be significant in some corner cases. More
> > important, to me at least, a requirement such as this should be
> > enforced either at compile time or at run time. I've struggled
> > how you'd enforce it at compile time, and enforcing it at run time
> > adds even more overhead. So, unless there's a valid reason not
> > I'd prefer we remove this restriction.
> or just documnet it as "if you don't use signal in a locked
> than the behavior is undefined" like with delete [] <-> delete.

That doesn't allow for the optimization in the corner cases. Also, I
think it's important to define as much as is possible, leaving
undefined behavior only when absolutely necessary. Further, if you
can prevent undefined behavior from occuring, you should do so, as
we've done with wait() by passing in the lock.

> > > IHMO support both one and all would be useful, since it's
> > on
> > > all platform so the implementation of all without using the
> > underlying
> > > os would be more expensive.
> >
> > Sorry, I'm having problems deciphering this.
> one refered to notify_one and all refered to notify_all:-):
> IHMO support both notify_one and notify_all would be useful, since
> supported on all platform, so the implementation of notify_all
> using the underlying os would be more expensive.

I'm still not following. My interpretation of what you wrote leads
to a contradiction. First you say that all platforms support both
then say that it's more expensive to implement notify_all with out
the OS. First of all, it's not supported on all platforms. Neither
form is supported on Win32. On Win32 notify_one() is much easier to
implement fairly and correctly. So if we're to talk only about
what's supported on most/all platforms we'd wind up not including
notify_all(). So, I agree with you that we should include both, but
I don't follow the reasoning you gave here. I think we have a
language barrier here and I just need to comprehend what you're
trying to say.
> > > in my dream, if we have the thread, mutex, condition (and may be
> > semaphore)
> > > we can implement all higher level abstraction and pattern
> > using
> > > any platform dependent features (ie. os function calls).
> >
> > Actually, given either a mutex or a semaphore you can model all
> > types. So technically, we could simply provide a platform
> > independent semaphore and build all other types off of it.
> > some performance might be gained by using platform specific
> > primitives instead.
> ok. I refine my statement as given the above 3 thread, mutex,
> (or 4) primitive type, we can implement other patterns ina platform
> way without loosing performance (or just an acceptable).
> > (It might be beneficial to provide implementations of all types
> > solely on semaphore to simplify porting to platforms that don't
> > support any other primitives.)
> and another with mutex and condition..;-)

A condition can't be used, since it relies on a mutex/monitor. The
mutual exclusion mechanism is what's really required. Given any
method to provide for mutual exclusion (Mutex and Semaphore are the
models we've defined so far) you can build all of the other
synchronization concepts (conditions, message queues, thread local
storage, atomic counters, variations on Mutex/Semaphore, etc.).

I picked semaphore because it's the most flexible of the two models
we have that allow for mutual exclusion. In order to use a Mutex to
implement a ConditionVariable you'd first have to use it to model a
Semaphore, for instance.

Bill Kempf

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