>Though there's still this tremendous leap from an object-oriented viewpoint
>in the first part of the spec to a variable-oriented viewpoint in chapter
>17. We should make it clear (spell it out) that synchronization w.r.t. a
>reference field is unrelated to synchronization w.r.t. the fields of the
>referenced object.
I agree. Explaining the memory model for a programmer is a different
task that writing up a formal specification, and at the moment I'm
working on the later.
>
> > Another possibility is to use interrupts.
> >
> > Basically, we could say that whenever thread T1 interrupts T2, that it is
> > treated as a release by T1 on the interrupt, when is acquired by T2 when
>it
> > detects the interrupt (e.g., by throwing an InterruptedException).
> >
>
>thread.interrupt() isn't synchronized. Is this a problem?
>
I'm suggesting a change for the semantics of interrupt(). The idea is
that if thread T1 wants to interrupt thread T2, then T1 probably
wants to communicate with thread T2. So we put in a special rule that
says, informally, if thread T1 interrupts thread T2, then when thread
T2 sees the interrupt, it sees all of the writes of T1 (as of the
time the interrupt was sent).
This isn't an important issue, and is orthogonal to the rest of the
issues in the memory model. But I think the performance impact would
be minimal or none, and that it would make some useful idioms valid.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:20 EDT