Race explanation: 1. When FutureTask.run() is not used, and only FutureTask.set() is used, FutureTask.set() will race with FutureTask.get(). The race is evidenced by the initial call to FutureTask.get() returning the unassigned null value just before it should have seen the assigned value. A second call to FutureTask.get() will see the proper value.
2. Because FutureTask.run() is not used, Sync.runner is always null, and therefore Sync.acquireSharedInterruptibly(), the guard in Sync.innerGet(), could take the fast path when it calls Sync.innerIsDone(). 3. Over in Sync.innerSet(), the call to Sync.releaseShared(), sets Sync.runner to null, which in the case of never setting runner to begin with, is too late to make Sync.acquireSharedInterruptibly() cause Sync.innerGet() take a slower path. 4. Hence, Sync.innerGet() returns after RAN state is set, but it can return just before Sync.innerSet() sets the value. To repeat, if a client uses FutureTask as an implementation of Future instead of Runnable, this race will happen. If the client uses it as an implementation of Runnable, all seems to be well. I have an example if the textual description is insufficient. Not until I could see it fail on multiple platforms and in -Xint mode was I satisfied that I should be critical of the class text. I want to make sure you know there is a race in a central concurrency class, but at the same time, I am trying to learn how things work with participation on the jdk. A bug in an important contract that also overlaps with a JSR, etc. On Sat, Jan 21, 2012 at 5:07 AM, David Holmes <[email protected]> wrote: > On 21/01/2012 7:31 AM, Jason Schroeder wrote: >> >> I have witnessed and can read a race condition in FutureTask (jdk7, jdk6). >> >> However, there is a new version of FutureTask at oswego, >> >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/FutureTask.java?view=co >> which purposely fixes the race condition. > > > Can you be more specific about what race condition you are referring to? > > >> Are new versions of the concurrency classes coming to jdk 7/8? > > > Bug fixes, and enhancements to the concurrency classes are always in the > works for the next Java release ie 8. If there are bug fixes that are > significant enough then they can be backported to 7. > > >> Or is >> it better to add a race condition bug to database? (I live under the >> newbie impression that races are different bugs.)
