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