Re: Threads

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 
with
> > 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 
to,
> > I'd prefer we remove this restriction.
> 
> or just documnet it as "if you don't use signal in a locked 
enviroment
> 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 
supported
> > 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 
it's 
> supported on all platform, so the implementation of notify_all 
without 
> 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 
without
> > using
> > > any platform dependent features (ie. os function calls).
> > 
> > Actually, given either a mutex or a semaphore you can model all 
other
> > types.  So technically, we could simply provide a platform
> > independent semaphore and build all other types off of it.  
However,
> > some performance might be gained by using platform specific
> > primitives instead.
> 
> ok. I refine my statement as given the above 3 thread, mutex, 
condition
> (or 4) primitive type, we can implement other patterns ina platform 
independet
> way without loosing performance (or just an acceptable).
>  
> > (It might be beneficial to provide implementations of all types 
based
> > 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