Re: [boost] Re: Threads

From: Levente Farkas (lfarkas_at_[hidden])
Date: 2000-08-24 08:27:13

William Kempf wrote:
> The keyword "monitor" replaces the keyword "class" (or "struct") for
> monitor types.  The compiler would then automatically synchronize all
> calls to methods of the monitor.  Conditions are native types (so
> condition is a keyword) that can be declared only within a monitor at
> class scope.  The wait and signal are operators that can only be used
> on conditions and only within monitor method scope.  (Boy, isn't this
> complicated.)  Because of these constraints it follows that the
> hidden mutex must always be locked when a call to signal or wait is
> made (after all, they can only be made within the monitor by
> definition of the language).

I think it's obvious that we cant change the language (or it's another
ten years to get the result:-((()

 
> As a library, we can only use artificial constraints for these
> requirements.  This has two major consequences:  the programmer must
> lock the mutex on entry to all monitor functions explicitly which can
> be error prone, and all rules given for conditions can not be
> enforced by the library.  I don't think we can address the lock

I think there are two possibilities, we change tha language (and loose
some flexibility like in java) or there'll be some place which are error 
prone at least with threads (or loose some flexibility again).
there is no free lunch:-(

> interface require a lock object be passed in.  For the signal we can
> relax the requirement that the mutex be locked, provided that this
> doesn't result in a race condition.  I'm not sure that it will,
> especially considering that this is the recommended approach in
> pthreads, but I'd love to hear the arguments that explain why it is.

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

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

> The point of all of this?  I'm not sure that we should exactly
> conform to the classic monitor.  I think that notify_all() is safer
> and more expressive than notify_one().  By the same reasoning, it
> *might* be safer and more efficient to allow notifications outside of
> the mutex lock (this assumes there isn't truly a race condition by
> doing so).

I think it's the question when we design the monitor patter, but IMHO
both notify would be useful in that case too.

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