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
'q'.
Currently it can happen that the following evaluates to true, which is
surprising:
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.
cheers,
-- 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.
Regards, Peter
cheers, and thanks for pointing it out!
-- daniel
Regards, Peter
