RFR(s): 8023541 Race condition in rmid initialization

Stuart Marks stuart.marks at oracle.com
Thu Jan 30 18:51:27 UTC 2014

On 1/30/14 2:35 AM, David Holmes wrote:
> On 30/01/2014 5:34 PM, Tristan Yan wrote:
>> Hi Stuart
>> I didn’t make my comment clear. You set interrupted as true when thread
>> gets interrupted. Here it's still going to wait until systemStub is not
>> null. Why do you still need interrupt current thread in this case.
> Because the golden rule of interrupt handling is you either throw
> InterruptedException or you re-assert the interrupted state. This allows code
> further up the stack to respond to interrupts.

Right, thanks David.

While it's often acceptable to let InterruptedException propagate, or to catch 
and rethrow it, IE is a checked exception so this isn't always allowed. That's 
the case with this code. The only alternative in this case is to re-assert the 
interrupted state before returning.

There's some discussion of this in Goetz, et. al. "Java Concurrency In 
Practice", section 5.4. There's an example here of catching IE and reasserting 
the thread's interrupted state. Get this book if you don't have it already.

The *worst* thing to do is something like,

     try {
         ... wait or sleep or something that throws IE ...
     } catch (InterruptedException ie) {
         // ignored

I write this all the time in toy programs, but product code and even test code 
should follow the golden rule.


More information about the core-libs-dev mailing list