[concurrency-interest] Seeking Interruption Rule Clarification

Joe Bowbeer joe.bowbeer at gmail.com
Fri Dec 4 14:56:22 EST 2009


I think you can reason effectively about this by replacing the interrupted
flag with a volatile boolean flag.

T3: T3.flag = false
T1: T3.flag = true
T2: T3.flag = true
T3: if T3.flag then ...

The right answer, I think, is that the write to the volatile will always
"happen" (unless the compiler can deduce that a concurrent read will never
happen).  However, I'm not sure how or if the JMM specifies this.

--Joe

On Fri, Dec 4, 2009 at 11:22 AM, Will McQueen wrote:

> Hi,
>
> On p341 of JCIP, the Interruption Rule states:
> "A thread calling interrupt on another thread happens-before the
> interrupted thread detects the interrupt (either by having InterruptedException
> thrown, or invoking isInterrupted or interrupted)"
>
> I'm a little unclear on the specifics. Suppose that we have:
>      Threads T1, T2, and T3 are alive and the interrupt flag is clear. T3
> is executing in a loop, where it does Thread.sleep(10000) and then calls
> T3.interrupted() to check+clear the flag status.
>
> And suppose that we have the following global execution sequence:
> 1) T3 has just called Thread.sleep(10000)
> 2) 2 secs later, T1 calls T3.interrupt().
> 3) Another 2 secs later, T2 calls T3.interrupt().
> 4) Now T3's Thread.sleep(10000) call (from step #1) returns, and T3 calls
> T3.interrupted() and detects the interrupt.
>
> In this case which of the following statements can we claim as true?
> 1) There's a HB edge from T1's T3.interrupt() call to T3's T3.interrupt()
> call.
> 2) There's a HB edge from T2's T3.interrupt() call to T3's T3.interrupt()
> call.
>
> I would guess that we can only claim #1, because T1 is the thread that
> caused T3's interrupt flag state to change state from false to true. T2's
> call to T3.interrupt() did not cause a state change to T3's interrupt flag
> because it was already true before T2 called T3.interrupt(). My assumption
> can be summed-up as:
>
> "The Interruption Rule results in a HB edge from T1's T3.interrupt() call
> to T3's T3.interrupted() call, only if T1 was the thread responsible for the
> state change to T3's interrupt flag".
>
> 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?
>
> Thank you. I appreciate your help in clarifying.
>
> Cheers,
> Will
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20091204/d0bd560e/attachment.html>


More information about the Concurrency-interest mailing list