Improving the speed of Thread interrupt checking

[Charles Oliver Nutter]

For your ABA case, I can think of a couple options:

* instead of get, do getAndSet when clearing. Whether it is true or false,
it will end up false, so clearing is not a big deal. However, we're always
doing the write then, so perhaps...
* CAS(true, false) instead of just reading. If set, it will be cleared. If
unset, CAS will fail and we know it was not set. Again, not sure about the
cost of this versus the simple read. It should usually fail, and I don't
know that cost either.

I am not sure at what point the lock becomes the cheaper option, but it
seems like it would still be more expensive than either of these.

And the clearing case is actually the common one; most users call
Thread.interrupted, which gets and clears all at once. Even if you use the
non-clearing Thread#isInterrupted, you probably still need to clear it
after you respond to the interruption...in our case, raising an appropriate
error to indicate the regex did not return in a reasonable amount of time.
We don't want interrupt flag to linger after that error is handled.

- Charlie (mobile)
On May 10, 2013 6:51 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> 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
>>
>>
> _______________________________________________
> 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/5f74e970/attachment.html