RE: JavaMemoryModel: Volatile array references

From: Bill Pugh (
Date: Wed May 01 2002 - 10:28:08 EDT

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

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.

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:39 EDT