The focus for now is on interaction between data and synchronization. I
prefer synchronization operations to be SC among themselves as well, but I
don't think the model in the pdf document cares about this. The
simplification I am working with now will become a little more messy if we
have non-SC synch.
By the way, it seems like you are reading the pdf document. Other than the
definition of a data race, the formalism there isn't necessary any more -
see the "intuition is the model" message from last night.
Sarita
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu] On Behalf Of Yue Yang
> Sent: Tuesday, July 29, 2003 3:33 PM
> To: JavaMemoryModel@cs.umd.edu
> Subject: JavaMemoryModel: Volatiles in Sarita's model
>
>
> Sarita,
>
> Could you please clarify how volatiles are treated in your model?
>
> The definition of "Data race" talks about "data instruction
> instances",
> but volatile operations are not defined as data instructions in the
> definition of "Data, synchronization", this seems to suggest volatile
> operations are exempt from the P|Di rules. But there's no other total
> order requirement on volatiles.
>
> If the volatiles also follow the rules in the "Memory model"
> section, is
> the following case allowd?
>
> a and b are volatiles:
>
> t1 t2
> w(a)0 w(b)0
> w(a)1 w(b)1
> r(b)0 r(a)0
>
> This trace is not SC. Is this desired for volatile flags?
>
> - Jason
>
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:48 EDT