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" <head...@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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
