[concurrency-interest] Seeking Interruption Rule Clarification

David Holmes davidcholmes at aapt.net.au
Sun Dec 6 22:23:35 EST 2009


Will,

> But it gets even more complicated, because we could also have the
> following actual execution sequence (ie, assume that this is the
> "real" global execution sequence, after any reorderings) between
> just 2 threads, T1 and T3:
>
> 1) T3 has just called Thread.sleep(10000)
> 2) 2 secs later, T1 calls T3.interrupt().
> 3) 2 secs later, T1 executes the statement "x = 5" (stores a
> value into a mutable shared var)
> 4) 2 secs later, T1 again calls T3.interrupt()
> 5) Now T3's Thread.sleep(10000) call (from step #1) returns, and
> T3 calls T3.interrupted() and detects the interrupt.
> 6) T3 performs a read on var x
>
> In this case, the same thread T1 made 2 calls to T3.interrupt()
> (in steps #2 & #4), but only the call from step #2 is the one
> that caused the actual state change to T3's interrupt flag, so
> supposedly this is the only state change that T3 "detected". Does
> that mean that there's only a HB left edge from the execution of
> T1's first T3.interrupt() call rather than from T1's second
> T3.interrupt() call? If that's true, then it seems that there can
> be no (transitive) HB edge between the write of var x in T1 and
> the read of var x in T3, in which case the value "5" might not be
> visible to T3's read, right?

Maybe. The problem is that JMM rule is really only considering the case
where the actual interrupt state changes. In the scenario given the second
interrupt call might be implemented as a no-op if the system can see that
the target is already in the interrupted state. In practice on Hotspot it
isn't a complete no-op so you're in fact likely to get the necessary memory
synchronization to see the value "5".

The JMM would have to specify the interaction here in a lot more detail to
be able to reason in the abstract about what is guaranteed in this case.
Even treating the interrupted state as a volatile does not specify it
precisely enough as you need to know if interrupt() is required to always
write to the volatile or can elide it if it sees the thread is already
interrupted.

Cheers,
David Holmes

> Thank you. I appreciate your help in clarifying.
>
> Cheers,
> Will



More information about the Concurrency-interest mailing list