Charles, Why bother even using CAS?
Thread A is monitoring Thread B. Thread B cooperatively checks to see if it should die. Therefore, you only need B to know when A has told it to shut down. Therefore, all you need is a volatile boolean. A volatile boolean is very much faster than a full CAS operation. http://nerds-central.blogspot.co.uk/2011/11/atomicinteger-volatile-synchronized-and.html Best wishes - AJ On 10 May 2013 17:03, 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
