Jan-Willem wrote:
> We can fix the writer side using the same trick as in Bill's model, if
> I read correctly:
> v++;
> tmp = v; // conceptually begins the "writer locked" region
> a = 2;
> b = 3;
> v = tmp+1; // conceptually ends the "writer locked" region
> In CRF:
> // The increment as before
> LoadV v
> Fence_r* v, *
> StL v, v++
> // Our semantics will allow the succeeding read to be fetch-elminated,
> // but the following fence will then become Fence_w* v, *
> Fence_wr V,v
> tmp = LoadL v;
> Fence_r* v, *
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
This, unlike what you wrote above (fence_r*),
does not prevent subsequent *writes*
from being re-ordered with the read.
That's why I thought that you needed the stronger
operation of either monitorenter or endcon.
What did I do wrong?
...
> * We must do something exit-like in the reader in order to obtain
> meaningful semantics.
> This leads to a truly warty solution:
> t1 = v;
> ...
> x = a;
> y = b;
> ...
> hasBeenRead = true; //*** UGLY!!!
> t2 = v;
> if (t1==t2 %% t1%2==0) return(r);
> else /* redo, lock, etc. */
Yes, I didn't think of that.
Just to clarify, it is really
*volatile* bool hasBeenRead.
An example of an unshared, volatile, *dead* variable
on the stack, which is being written just for
the side effect of getting this fence!
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