Re: Threads

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-24 09:33:15

--- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> 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:-((()

I wasn't suggesting a language change, though if it were possible 
that would by far be the ideal solution.  The reason I posted the 
language change example was to illustrate the differences between a 
language supported monitor and a monitor pattern followed by a 
library.

> > 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:-(

I'm not sure that I agree with the statement that we must lose 
flexibility with a language change.  Java made some mistakes in it's 
implementation of a monitor (allowing synchronization outside of the 
monitor and access to a class outside of a monitor lock, and not 
defining locks/waits to be FIFO in operation are the mistakes I'm 
aware of).  Clean those mistakes up and I see no barriers to 
flexibility.  In fact, every primitive we've defined so far could be 
very easily modeled using a language supported monitor.

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

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

(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.)
 
Bill Kempf