Improving the speed of Thread interrupt checking

[Alexander Turner]

Jeroen,

Yes - I get what you are saying. Volatile is OK for one way communication;
the interrupting thread does not need to know the state of the interrupted
thread.

Thanks - AJ


On 11 May 2013 08:49, Jeroen Frijters <jeroen at sumatra.nl> wrote:

> Charles Oliver Nutter wrote:
> > You need CAS because one form of the interrupt check clears it and
> > another does not. So the get + check + set of interrupt status needs to
> > be atomic, or another thread could jump in and change it during that
> > process.
>
> I believe Thread.interrupted() and Thread.isInterrupted() can both be
> implemented without a lock or CAS.
>
> Here are correct implementations:
>
>     private volatile boolean interruptPending;
>
>     public boolean isInterrupted() {
>         return interruptPending;
>     }
>
>     public static boolean interrupted() {
>         Thread current = currentThread();
>         if (!current.interruptPending) {
>             return false;
>         }
>         current.interruptPending = false;
>         return true;
>     }
>
> Any interrupts that happen before we clear the flag are duplicates that we
> can ignore and any that happen after are new ones that will be returned by
> a subsequent call. The key insight is that the interruptPending flag can be
> set by any thread, but it can only be cleared by the thread it applies to.
>
> Regards,
> Jeroen
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130511/253f937e/attachment.html