At 6:56 AM +1000 7/22/02, David Holmes wrote:
>I've been pouring over the document and agree that, as it now appears, it
>seems easier to understand than the old approach. However, given the
>incomplete treatment of volatiles and the absence of final, I'll reserve
>judgement on that. :)
>
>You state that volatiles are dealt with as sequentially consistent at
>present. I am still waiting to hear exactly how we plan to deviate from SC
>for volatiles. Further, the document makes volatiles SC in isolation (as far
>as I can tell) and doesn't cover orderings across volatiles, nor (more
>importantly) orderings between volatile accesses and normal accesses - I had
>expected to see some entries in the table in Figure 3 covering actions on
>volatiles.
Perhaps we'll add them to Table 3; it isn't exhaustive. However,
there is a heppens-before edge from a volatile read to all previous
writes of that volatile. That gives us the ordering we need between
volatile and normal memory accesses.
But we probably need a little more treatment of volatiles.
>
>It may be that unsynchronized reads are accounted for in the
>definition of unithread semantics when it states "behaviour of the thread
>based on the values seen by read actions within the thread" - if so then I
>wouldn't call this "standard semantics for single threaded programs". Either
>way a clarification is needed.
This is what we mean. The values seen by reads are defined by the
memory model, everything else is defined by the unithread semantics
of each thread. We do not use the unithread semantics to define the
values seen by reads.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:40 EDT