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."