[concurrency-interest] DirectByteBuffers and reachabilityFence

David Holmes davidcholmes at aapt.net.au
Wed Dec 9 15:51:49 EST 2015


By having construction happen-before finalization, it ensures that if finalization happens after construction is complete then it will see all of the constructed values, even though they happened in a different thread. This is normal happens-before with regard to two synchronization actions – but a construction is not a synchronization action it was special-cased.

 

David

 

From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Vitaly Davidovich
Sent: Thursday, December 10, 2015 1:36 AM
To: dholmes at ieee.org
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] DirectByteBuffers and reachabilityFence

 

sent from my phone
On Dec 9, 2015 6:11 AM, "David Holmes" <davidcholmes at aapt.net.au> wrote:
>
> Andrew Haley writes:
> > On 09/12/15 09:21, David Holmes wrote:
> >
> > > The happens-before requirement was deliberately set the way it is to
> > > show that an object can not be finalized before its construction has
> > > completed (whether normally or abnormally). So I would agree with
> > > Justin that it should not be possible for an object to be finalized
> > > before construction has completed - regardless of potential compiler
> > > optimizations etc.
> >
> > Hmmm, okay.  It might be that I misremembered or perhaps it was a bug,
> > but I don't think so.  Is there really a happens-before relationship
> > between a constructor of an object with no volatile or final fields
> > and its finalizer?
>
> My recollection - and I've been trying to find this in the JavaMemoryModel
> archives - is that the happens-before between constructor and finalizer was
> introduced because the normal "trick" of using synchronization was very
> counter-intuitive in constructors given the object has not been published.
>
> That said, A happens-before B simply establishes visibility/ordering rules
> for the case when A occurs before B. It says nothing about B occurring
> before A, or B and A overlapping. Other mechanisms have to force the
> temporal order. So it may be I misspoke my support of Justin's position. :(

I have a different interpretation, akin to your previous answer.  There's very little point in stating that ctor happens-before finalization if that's not even the case always (i.e. they overlap or occur in reverse order) - how would that be meaningful?

>
> David
> -----
>
>
> > Andrew.
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151210/d1e4bb23/attachment.html>


More information about the Concurrency-interest mailing list