[concurrency-interest] InterruptedException-free wrappers for calls that "will never be interrupted"

Doug Lea dl at cs.oswego.edu
Fri Apr 9 09:43:32 EDT 2010

On 04/08/10 12:46, Chris Povirk wrote:
> My goal is a family of operations like these:
> // Neither of these throws InterruptedException.

I don't have any concrete suggestions at the moment, but
here are a few observations:

* The story about how interrupt and InterruptedException
work is another one of those things that only make sense in
historical context. InterruptedException was first introduced
(around 1994) as Java moved from alpha to 1.0 (before that,
Object.wait etc did not throw IE). Then Checked exceptions
were introduced. While I wasn't a part of any of this,
my guess is that IE was classified as checked so as to
force people to fix their wait() constructions to accommodate
this change. It has always been odd that built-in locks
cannot throw IE yet built-in waits must throw IE. This is
one reason to use ReentrantLock etc, which support all the
possible forms. Perhaps this distinction should have been more
uniformly propagated to other blocking methods. Perhaps it still could.

* While there are a few others cases, the main situation in
which you want to continue even if interrupted is if you are
part of a computation that can only cancel/terminate cooperatively
or globally. This is why ForkJoinTask.join and other FJ methods
(and similarly, Phaser) do not throw IE -- interruption of any
subtask wait doesn't imply anything about cancelling the aggregate
computation; instead you need explicit cancel(). As more
and more code is written involving cooperative parallel
computations, this mode becomes more common. FJ includes
an extensibility hook ForkJoinPool.ManagedBlocker than allows
this mode to be used for any blocking operation. It might be
a good idea to build in support for a few common ones (like
basic FIFO queues). Note though that Phaser generalizes
CountDownLatch so there is no real need for modified form
of CountDownLatch. Similarly ForkJoinTask for Future.

* The implementations of most blocking constructions
in j.u,c. components include a fair amount of overhead to ensure
responsiveness to interruption. Adding looping catch-and-retry
overhead on top of this just to suppress IE is a sad way to cope,
It would be a lot faster if the underlying methods did this themselves.


More information about the Concurrency-interest mailing list