RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object"
peter.levart at gmail.com
Thu Jul 30 11:37:41 UTC 2015
On 07/30/2015 12:48 PM, Daniel Fuchs wrote:
> On 30/07/15 12:20, Peter Levart wrote:
>> On 07/30/2015 11:12 AM, Daniel Fuchs wrote:
>>> Hi Peter,
>>> I'm glad you're looking at this too! We can't have too many eyes :-)
>>> On 30/07/15 10:38, Peter Levart wrote:
>>>> Suppose we have a Reference 'r' and it's associated ReferenceQueue
>>>> Currently it can happen that the following evaluates to true, which is
>>>> q.poll() == null && r.isEnqueued()
>>> But on the other hand this can only happen if two different
>>> threads are polling the queue - in which case only one of them
>>> will get the reference. In such a situation, the symmetric condition
>>> would not be surprising (as the other thread would
>>> get q.poll() != null):
>>> r.isEnqueued() && q.poll() == null
>>> The original bug fixed by Kim is more surprising, because there's only
>>> one Thread doing the polling, and it does get:
>>> r.isEnqueud() && q.poll() == null
>>> although nobody else is polling the queue.
>>> This should no longer occur in this situation with Kim's fix.
>>> -- daniel
>> Yes, these are two different issues. The one Kim has fixed is the race
>> of above expressions with Queue.enqueue() (when the queue is changing
>> from the associated instance to ENQUEUED). The one I'm pointing at and
>> Kim has already identified as potential issue is the race of the
>> following expression:
>> r.isEnqueued() && q.poll() == null && r.isEnqueued() ==> true
>> ....with Queue.[realy]poll() (when the queue is changing from ENQUEUED
>> to NULL).
>> Which only happens if at least two threads are polling the queue, but is
>> equally surprising and prone to cause bugs, don't you think?
> Hi Peter,
> Yes - this is also surprising. Is it prone to cause bugs?
> possibly - but how serious I'm not sure.
> Is it 'equally' surprising - well - that was the point of my argument:
> there are two threads polling the same queue - so one of them should
> get null... Though I agree that in this case - 'r' should be seen
> has having changed state...
poll() returning null by itself is not surprising, but if 'r' appears to
be "enqueued" before and after the fact, this is surprising.
> The question for me is whether this should be fixed in the same
> changeset - or whether we should make it in another changeset...
It's a different issue, though very similar.
> cheers, and thanks for pointing it out!
> -- daniel
>> Regards, Peter
More information about the core-libs-dev