[concurrency-interest] enable / disable interrupt

David Holmes dcholmes at optusnet.com.au
Sat Mar 29 21:21:25 EDT 2008


I think Bil's proposal is fairly unique, I've never seen it arise since
then - I was one of the four main reviewers of the book (as was Doug Lea).
Bil came at this from a POSIX threads background where there is an ability
to enable and defer asynchronous cancellation (which is very important). Bil
extended that to Java thread interruption through his simple subclass
implementation.

And that was that, it has never really been raised as an issue since. With
so few methods actively supporting interruption, and given that interruption
is synchronous anyway, then deferring interruption is rarely needed and
fairly easily accommodated - taking wait() as an example, you are waiting in
a loop - if you receive InterruptedException and want to keep waiting then
you flag the fact the interrupt occurred, and re-wait. You can then chose to
re-assert the interrupt, or rethrow the IE later.

Now if interruptible I/O had become common-place then perhaps the ability to
defer interrupts would have been more critical. But interruptible I/O was a
flawed idea that was only ever (partially) implemented on one platform (and
caused a lot of grief).

The main problem with third-party code is where they consume interrupts -
and Bil's proposal doesn't help much in that regard. Or perhaps it does. If
you assumed third-party code could not be trusted and you always deferred
interrupts while executing it, then upon return the interrupt would still be
pending and so would not be lost. But that would also deny the ability for
third-party code to respond to interrupts, so what gain in one place you
lose in another. And custom thread classes could track interrupts in other
ways.

Cheers,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Hontvari
> Jozsef
> Sent: Saturday, 29 March 2008 7:37 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] enable / disable interrupt
>
>
> I have read an elegant solution to the problem of interrupting a thread
> running third party code. The third party code may not respond in the
> expected way to the interrupt. One solution can be to run the third
> party code in a different thread, but this may make the code ugly and
> may double the count of threads. The proposed solution is to use a
> Thread subclass which overrides the interrupt method and adds functions
> to enable and disable interrupts.
>
> It is in the book "Multithreaded Programming with JAVA Technology" by
> Bil Lewis; Daniel J. Berg:
>
> public class InterruptibleThread extends Thread {
> private boolean interruptsEnabled = false;
> private boolean interruptPending = false;
>
>
> public static void enableInterrupts() {
>   InterruptibleThread self = InterruptibleThread.currentThread();
>
>   synchronized (self) {
>     self.interruptsEnabled = true;
>     if (self.interruptPending) self.interrupt();
>     self.interruptPending = false;
>   }
> }
>
> public static void disableInterrupts() {
>   InterruptibleThread self = InterruptibleThread.currentThread();
>
>   synchronized (self) {
>     if (interrupted()) self.interruptPending = true;
>     self.interruptsEnabled = false;
>   }
> }
>
> public synchronized void interrupt() {
>   if (interruptsEnabled)
>     super.interrupt();
>   else
>     interruptPending = true;
> }
>
>
> This book is relatively old, from 1999, but I don't find the idea
> implemented anywhere else. It seems to be so useful that if it does work
> then I would expect these functions to be included in the Java API
> already. But they aren't there of course. Is there something
> fundamentally wrong with this idea?
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list