[concurrency-interest] Thread safety of WeakReference .get() method?

Vitaly Davidovich vitalyd at gmail.com
Wed Aug 8 09:22:41 EDT 2012


Adding the list in case someone has further insight.

Sent from my phone
On Aug 8, 2012 9:20 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> I should mention though that if you loop on WR.get(), as demonstrated by
> Heinz, you can fall victim to compiler optimization where the referent
> field is enregistered.  Almost seems like a bug, but I'm guessing this is
> an unusual use case.
>
> Sent from my phone
> On Aug 8, 2012 9:14 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
>
>> As Aleksey mentioned, one can assume that the interaction between java
>> and gc threads already has sufficient barriers to make it work.  Otherwise,
>> WeakReference would not work at all even in single java thread case since
>> GC runs on its own VM threads.  Or did I miss your point?
>>
>> Sent from my phone
>> On Aug 8, 2012 9:10 AM, "Raph Frank" <raphfrk at gmail.com> wrote:
>>
>>> On Wed, Aug 8, 2012 at 2:00 PM, Vitaly Davidovich <vitalyd at gmail.com>
>>> wrote:
>>> > You will need to treat WeakReference as any other non-threadsafe class
>>> and
>>> > provide the necessary happens-before edges if you want to share the
>>> instance
>>> > amongst java threads.
>>>
>>> The issue here is the sync between the garbage collection thread(s)
>>> and the reference.
>>>
>>> The WeakReference is created in the constructor of another object and
>>> set to a final field.
>>>
>>> It sounds like setting the last reference to null from one thread and
>>> using .get() from another can cause a problem.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120808/5ae9a131/attachment.html>


More information about the Concurrency-interest mailing list