Re: [boost] Re: Threads

From: Levente Farkas (lfarkas_at_[hidden])
Date: 2000-08-24 10:03:58

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.
 
> > > Another key point in this example:  the classic paper only
> defines a
> > > signal() which is analogous to notify_one().  There is nothing
> > > analogous to notify_all().  This simplifies the definition of a
> > > condition to a construct as simple as:
> > ...
> > > This is a *lot* less complex than the equivalent to a pthread
> > > condition which must allow a notify_all().  However, notify_one()
> > > isn't as safe or flexible as notify_all().  With notify_one() you
> > > must always use one predicate for one condition.
> >
> > 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.
 
> > 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..;-)

 -- Levente
 "The only thing worse than not knowing the truth is
  ruining the bliss of ignorance."