[concurrency-interest] DirectByteBuffers and reachabilityFence

David Holmes davidcholmes at aapt.net.au
Thu Dec 10 01:36:22 EST 2015

Justin Sampson writes:
> David Holmes wrote: "To me that is somewhat akin to inferring that
> monitors must enforce mutual exclusion by only knowing about the HB
> edges defined for monitor actions."
> And Vitaly Davidovich wrote: "This is trying to relate reads and
> writes that synchronize with each other, it says nothing about
> independent reads and independent writes."
> Interesting. You both seem to be associating happens-before with
> synchronization more strongly than is warranted by the JMM. The
> happens-before order is more fundamental than the synchronization
> order, right? Synchronization _implies_ happens-before, but not the
> other way around. So _of course_ you can't infer mutual exclusion
> from happens-before, because the implication is going in the other
> direction.

You've completely missed my point. So at this point I give up.

> Synchronization is _one_ of the things that determines
> happens-before, but not the only thing. Happens-before doesn't imply
> synchronization, but it _does_ imply visibility -- and the lack
> thereof. Indeed, that is its only purpose! The only way that the
> happens-before order relates to the definition of well-formed
> executions is the notion of happens-before consistency, which
> governs the visibility relationship between any reads and writes
> that are connected by the happens-before order -- _not_ only reads
> and writes that "synchronize with each other," but _all_ reads and
> writes that are transitively connected by _any_ happens-before
> edges, whether due to synchronization or due to other parts of the
> specification -- including (once again) the very explicit inclusion
> of a happens-before edge from the completion of a constructor to the
> execution of a finalizer.
> If the inclusion of such a rule right there in the bulleted list
> that defines happens-before in 17.4.5 isn't enough for JVM
> implementers to actually implement it, how can we possibly rely on
> the specification for anything else?

I still maintain that the requirement that an object does not become
finalizable until after its constructors complete, would not jump out of
that rule. Especially when the spec clearly states the object can be
finalizable after Object's constructor completes! Why would anyone read
deeper into the HB rule to see if it contradicts the other statement. If you
think you would then good for you.


> Cheers,
> Justin
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list