[concurrency-interest] Seeking Interruption Rule Clarification

Boehm, Hans hans.boehm at hp.com
Fri Dec 4 15:53:31 EST 2009


If you believe that the volatile case is equivalent, then the second bullet under 17.4.4 (JLS 3rd edition, http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4.4) makes it clear that any prior (in a total synchronization order) write of a volatile flag synchronizes with any later read of  the synchronization variable.

In that case, both happens before  edges inthe original question exist.

I'm inclined to read the last bullet in that list as confirming this interpretation.

Hans

________________________________
From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Joe Bowbeer
Sent: Friday, December 04, 2009 11:56 AM
To: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Seeking Interruption Rule Clarification

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/97d3946b/attachment-0001.html>


More information about the Concurrency-interest mailing list