At 2:46 PM +1000 5/1/02, David Holmes wrote:
> > 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. ??? ;-)
Correct. They are weaker than memory barriers.
>
>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.
You are still thinking of memory barriers.
>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).
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.
> 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.
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.
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:39 EDT