Boost logo

Boost :

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")
> > monitor types. The compiler would then automatically synchronize
> > 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
> > on conditions and only within monitor method scope. (Boy, isn't
> > complicated.) Because of these constraints it follows that the
> > hidden mutex must always be locked when a call to signal or wait
> > 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
> 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

> > As a library, we can only use artificial constraints for these
> > requirements. This has two major consequences: the programmer
> > lock the mutex on entry to all monitor functions explicitly which
> > 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
> some flexibility like in java) or there'll be some place which are
> 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
> > 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
> 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
> and os-thread library independent so IMHO this have to be a

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
> all platform so the implementation of all without using the
> 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
> we can implement all higher level abstraction and pattern without
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at