[gclist] Mars Rover info from comp.risks

Hans Boehm boehm@hoh.mti.sgi.com
Thu, 8 Jan 1998 10:02:31 -0800


On Jan 8, 12:14pm, Jerry Leichter wrote:
> Consider, however, that what is called a "condition variable" today is not
the
> same as what was called a "condition variable" when Hoare introduced them for
> use in monitors.  In a Hoare monitor, a condition variable is scoped to be
> accessible only inside of one monitor, and further the monitor's semantics is
> such that only one thread can be "in the monitor" at a time.  Hence, you know
> whose priority to raise:  When any process enters the monitor, its priority
is
> raised to match the highest priority of any process waiting to enter the same
> monitor.  The relevant "resource" is the monitor itself, and the compiler/run
> time system always knows

This isn't usually possible for either Hoare monitors or Java wait().  There is
no requirement when I call wait() that there be any other thread in the
monitor. Usually there won't be.  A producer thread may wait for a slot in a
buffer to become available.  The monitor protects the buffer.  There may be
multiple consumer threads running the following in a loop:

  acquire lock on the buffer
  remove buffer entry or entries
  signal availability of buffer slot
  release buffer lock
  process buffer entry

Typically most of the time will be spent in the last step.  (If I expect any
concurrency, most of the time better be spent in the last step.)  Thus a
producer thread encountering a full buffer is likely to not see anybody in the
monitor, and it has no way of telling which thread will remove a buffer entry
next.  Even if it could tell, it might not help because there might be multiple
high priority producers, and it would be unclear how many of the consumers
would need their priority raised.

Remember that I am not arguing that real-time code should be written this way.
 I am arguing that non-real-time Java and pthreads code is and should be
written this way, and that this style doesn't mix with strict priorities.  It
works just fine in the absence of priorities or in an environment in which
priorities are only hints about relative rates of progress.  (The latter is
consistent with Java semantics.)

Hans


-- 
Hans-Juergen Boehm
boehm@mti.sgi.com