Question about concurrent package races and updates

[Jason Schroeder]

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 <david.holmes at oracle.com> 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.)