Taking the content of your two postings about this subject together, I
would be reasonably content with a statement along the lines of
Decisions about reachability for the purposes of the Reference subclasses
follow the rules specified for finalization, with transitions between
levels of reachability being decided on the same basis and at the same
The reference classes shall behave as if the referent were held in a
volatile field. This field is deemed to have been read by the thread that
obtains the Reference by calling a method of the ReferenceQueue class, and
to have been written by the Reference.enque() method.
These statements, or equivalent wording, probably belong in the API rather
than the memory model spec, but I do think they are still part of JSR133.
At 08:11 AM 20/05/2004 -0400, Bill Pugh wrote:
>If people are defining their own subclasses of a Reference class, they
>are responsible for proper synchronization, not the VM.
>At any rate, so long as people aren't passing pointers to References
>around via a data race, we shouldn't have to worry about imposing
>a hb-edge from Reference construction to Reference use.
>The only cases that we really need to worry about are:
> thread 1 calls clear, thread 2 calls get
> GC clears reference, thread 2 calls get
>which are handled by making the referent field volatile.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:07 EDT