RE: JavaMemoryModel: Minor issue on hb edges and interrupts

From: Sylvia Else (sylviae@optushome.com.au)
Date: Wed Mar 17 2004 - 22:55:47 EST


At 12:42 PM 18/03/2004 +1000, David Holmes wrote:
> > Yes. The idea is that someone might do something like
> >
> > * Interrupter thread
> > - store some data as to why the thread is being interrupted
> > - interrupt the thread
> >
> > * Interupted thread
> > - receive interrupt
> > - look at data explaining why it was interrupted.
> >
> > In general, I think any way of reliably communicating between threads
> > should induce a happens-before edge. Certainly, I think programmers may
>expect
> > that something like the above is reasonable.
>
>I disagree - the shared data should be properly synchronized just like any
>other shared data. Building this into the interrupt mechanics just seem
>unnecessary and the implicit synchronization can make code more obscure
>(consider a tool that watches for unsynchronized access - now they have to
>take into account use of the interrupt calls - yuck!).

I share David's concern. Taking the volatile analogy a bit further, the
proposal looks a bit like this:

     int reason;
     volatile boolean flag;

     interrupter() {
         reason = some reason;
         flag = true;
     }

     target() {
         while(flag == false) { }

         // look at reason.
     }

which is superficially reasonable. But change the reason field to be a
reference to an object, and have multiple interrupters, and it becomes easy
for the target method to end up with a data race on the reason object.

Introducing the hb edge only solves part of the problem. Things are clearer
if the edge is not there at all.

Sylvia.

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



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