JavaMemoryModel: The Optimistic Read Idiom and the new Java Memory Model

From: Jan-Willem Maessen (jmaessen@MIT.EDU)
Date: Mon Oct 30 2000 - 15:38:47 EST

Rob Strom wrote:

> Did I misunderstand Figure 7 in the paper on page 10 of
> the OOPSLA proceedings?
> I understood that figure to say that a read of volatile v
> generates this after the loadL:
> fence_rr v, *VR
> fence_wr v, *R

Indeed. This translation doesn't really give any sort of meaningful
semantics... The correct translation transposes the sense of the last

fence_wr *V, v
reconcile v
loadl v
fence_rr v, *VR
fence_rw v, *R

This is a typo which appears correctly in our slides and in our online
memo version of the paper
( ).

I, too, would like to be able to assert that local barriers can be
eliminated with no observable effects. That requires a generalization
of CRF with multiple stores, in which Commit & Reconcile are enforced
separately for each store (and thus where we must observe the store to
see its effect on ordering). This is the G-CRF mentioned in the
paper. I've shied away from introducing it into discussion, though I
suspect we will need to do so once higher-level issues are ironed out.

The higher-level issue at hand, then: How *do* we create a reader lock
without relying on volatiles to create barriers (because I don't think
the final semantics should allow this trick)? In general, how many
ordering constraints do we think we need for volatile variables?

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:28 EDT