> You are still thinking in terms of memory barriers:
> Don't.
:-) Old habits die hard
> There are no memory barriers. Just "happens-before"
> (conversely "happens-after") relations.
But to me "happens before" is weaker than memory barriers, unless the fact
that it happened implied memory barriers. ??? ;-)
> The read of the volatile field named array "happens-after" other
> writes to the volatile field named array. If you want the read of the
> field named array to be the memory coherence action performed by the
> reader, then the writer would need to perform:
>
> Thread 1:
> array[0] = 10;
> array = array;
In my case the writes to the array are already protected by a lock. I'm
hoping that the lock acquisition and release provides the necessary memory
coherence actions on the writer side. On the reader side the read of the
volatile array reference provides the necessary memory coherence actions.
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). And on the writer side either a write to a
avlatile, or the release of a lock would perform the coherence actions.
Maybe its the relationship between locks and volatiles that I'm confused
about.
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