Jan-Willem wrote:
> The correct translation transposes the sense of the last
> barrier:
>
> 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
> ( ftp://csg-ftp.lcs.mit.edu/pub/papers/csgmemo/memo-428.ps.gz ).
OK. I've updated my copy of the proceedings.
> 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.
There are two separate issues here:
(1) the expressivity of CRF as a platform-independent intermediate language
(2) the appropriate mapping from Java to the p-i-IL
The optimistic reading example doesn't impact issue (1),
since there is a relatively straightforward semantics-preserving
transformation from a Guava program (or the corresponding
synchronized Java program) to CRF --- namely the one I
illustrated in my first post to this thread.
That is, if you wrote:
public class Foo {
private int a = 2;
private int b = 3;
synchronized void update() {
a = RobsMath.nextPrimeAfter(b);
b = RobsMath.nextPrimeAfter(a);
}
synchronized int get() {
return (a*b);
}
}
then I could mechanically translate the above to a CRF program implementing
the reader and writer threads optimistically, avoiding the locks
but producing only the results that the totally synchronized program
would produce.
The problem is when I try to write it (either by hand or mechanically)
in Java --- then I seem to have to write weird things, and I wind
up generating more fences than are needed.
> 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?
I don't know -- it almost makes sense to expose the fence operations
directly to the Java programmer, in some class called
ExpertImplementors, rather than try to find different permutations
of the meaning of volatile.
As readers of the Guava paper know, my viewpoint is that ordinary
programmers should use synchronized methods, and such programming
tricks as read locks or optimistic locks or double-checking should
be left to tools/compilers.
Rob Strom
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:28 EDT