Improving the speed of Thread interrupt checking

[Vitaly Davidovich]

How would you handle the following with just CAS:
1) thread A reads the status and notices that it's set, and then gets
preemepted
2) thread B resets the interrupt and then sets it again
3) thread A resumes and does a CAS expecting the current state to be
interrupted, which it is - CAS succeeds and resets interrupt

The problem is that it just reset someone else's interrupt and not the one
it thought it was resetting - classic ABA problem.

You'd probably need some ticketing/versioning built in there to detect
this; perhaps use a uint with 1 bit indicating status and the rest is
version number - then can do CAS against that encoded value.

However, I'm not sure if this case (checking interrupt and clearing) is all
that common - typically you just check interruption only - and so unclear
if this is worthwhile.

Sent from my phone
On May 10, 2013 12:05 PM, "Charles Oliver Nutter" <headius at headius.com>
wrote:

> This isn't strictly language-related, but I thought I'd post here before I
> start pinging hotspot folks directly...
>
> We are looking at adding interrupt checking to our regex engine, Joni, so
> that long-running (or never-terminating) expressions could be terminated
> early. To do this we're using Thread.interrupt.
>
> Unfortunately our first experiments with it have shown that interrupt
> checking is rather expensive; having it in the main instruction loop slowed
> down a 16s benchmark to 68s. We're reducing that checking by only doing it
> every N instructions now, but I figured I'd look into why it's so slow.
>
> Thread.isInterrupted does currentThread().interrupted(), both of which are
> native calls. They end up as intrinsics and/or calling JVM_CurrentThread
> and JVM_IsInterrupted. The former is not a problem...accesses threadObj off
> the current thread (presumably from env) and twiddles handle lifetime a
> bit. The latter, however, has to acquire a lock to ensure retrieval and
> clearing are atomic.
>
> So then it occurred to me...why does it have to acquire a lock at all? It
> seems like a get + CAS to clear would prevent accidentally clearing another
> thread's re-interrupt. Some combination of CAS operations could avoid the
> case where two threads both check interrupt status at the same time.
>
> I would expect the CAS version would have lower overhead than the hard
> mutex acquisition.
>
> Does this seem reasonable?
>
> - Charlie
>
> _______________________________________________
> 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/20130510/c08b2c50/attachment-0001.html