RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"

[David Holmes]

On 31/07/2015 5:54 AM, Kim Barrett wrote:
> On Jul 30, 2015, at 8:09 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 30/07/2015 9:57 PM, Peter Levart wrote:
>>> 'r' has been enqueued.
>>>
>>> Thread-1:
>>>
>>> r.isEnqueued() &&
>>> q.poll() == null &&
>>> r.isEnqueued()
>>>
>>> Thread-2:
>>>
>>> q.poll();
>>>
>>>
>>> Sequence of actions:
>>>
>>> T1: r.isEnqueued() ==> true
>>>
>>> T2: q.poll() executed to the following point (see HERE) and 'r' was the
>>> last element in the queue ('head' has been assigned to null):
>>
>> Yeah thanks - just realized it is that darned unsynchronized "fast-path" again. What a mess.
>>
>> It a kind of inverse of the original problem.
>>
>> Original: don't update reference state to enqueued before the queue is updated
>> This one: don't update the queue state to empty before the reference state shows it is de-queued.
>>
>> So yes the fix here is to move "r.queue = null" to before the assignment to head.
>>
>> Bring on the next race ;-)
>
> I agree with everything David said above.  Bleh!
>
> So I think I can either:
>
> 1. Go ahead with my change + Peter's change.
>
> 2. Give this back to core-libs while I step carefully away :-)
>
> I *think* option (1) is at least an improvement.  But I completely
> missed Peter's race, despite having specifically looked for problems
> there, so take my opinion with an appropriate quantity of salt.

I vote for 1 as well. I think we have now given good coverage to the two 
sources of problems (the two lock-free regions):
- reference queue state can be seen while queue state is in transition
- queue empty state can be seen while reference state is in transition

Oh for a tool that would do this analysis for us :(

Thanks,
David

>