Re: JavaMemoryModel: No decision on lost notifications

From: Doug Lea (dl@cs.oswego.edu)
Date: Wed Aug 06 2003 - 09:05:59 EDT


Part of the problem here is that we still have trouble saying exactly
where the contoversy lies. Here's a stab at it, but I suspect that
even this folmulation itself may be controversial.

I see this as two distinct issues.

A. When one thread, t, does a wait -- for completeness, assume a timed wait,
  mon.wait(msecs)
there is in intrinsic race among the following ways for the wait to return:

  1. Some thread invokes mon.notify, and thread t was chosen
  2. Some thread invokes mon.notifyAll
  3. Some thread invokes t.interrupt
  4. The wait times out
  5. The wait spuriously returns

The choices for governing this are:
  A1. Must an implementation ensure that if causes (3), (4), or (5) have
      already occurred (at some hypothetical instant), that cause (1) does
      NOT also occur? Or,
  A2. Are multiple/indeterminate causes allowed?

The main question here is whether choice A1 is actually implementable
(without exorbitant cost/overhead) on all the platforms Java runs on.

B. When the above wait returns,
  B1. Must wait() throw InterruptedException ONLY if the "cause" of the
      return was case (3) above, or
  B2. May wait also throw IE if unblocking occurred under the other
      causes but the thread is known to be interrupted upon return from wait.

This question arises because some programmers would like, in general,
IE to be thrown as soon as interruption status is detected, while
others prefer to use the information about IE to help disentangle
which cases in (A) arose and act accordingly.

-Doug
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:50 EDT