> You are still thinking of memory barriers.
:-( I don't know how to think in terms of "happens before".
> >Maybe I'm missing something here but I thought that the semantics of
> >volatile were strengthened so that it was sufficient to make the "flag"
> >variables volatile without having to make every single data element
> >volatile. Reading the volatile flag (in this case the array reference)
> >should be sufficient to force reloading of subsequent data reads (in this
> >case the array element).
>
> No. It only forces the visibility of writes done before a previous
> write to the same volatile. For example, if no other thread writes to
> that volatile, no memory coherence action is required for the read.
Ah I see my mistake. If thread 1 sets some data and then sets a volatile
flag, then when thread 2 reads the volatile flag it is guaranteed to then
see all of the writes to the data that happened before the write to the
flag. So in my example I need to write to the array reference so that the
reader will see the writes to the array elements that happened before.
> The lock release only forces that the writes be visible to another
> thread that subsequently acquires a lock on the same object. For
> example, if no other thread acquires a lock on the array, then the
> compiler can remove the synchronization entirely.
Ok - so I can forget about any correlation between locks and volatiles. The
two mechanisms are totally independent.
Thanks for clarifying things. I'm trying to write a highly concurrent data
structure with lock-free reads (the data is "immutable" once written, but
the entire array might be copied when it grows - and there are other nice
properties) and I'm trying to do this by reasoning about the new memory
model - but I also have to see how it needs to be done in the current memory
model.
Cheers,
David
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:39 EDT