RFR (S): 8165859: gcTaskThread is missing volatile qualifier and barriers for _time_stamps

[Erik Österlund]

Hi Carsten,

I believe Kim is referring precisely to the release in the fence before 
the compare-and-exchange in that comment you refer to, rather than the 
membar Store* after the fence.
I would prefer to have explicit memory ordering between the linked 
producer and consumer pair, as Kim suggests. This is how the JMM 
implements sequential consistency - cooperatively with 
release_store_fence and load_acquire pairs on the same data. It might 
very well be that specific architectures might work fine without the 
acquire for the consumer as the producer implementation itself is strong 
enough to guarantee sequential consistency, but I don't see why it would 
be wise to bet on that if we don't have to, and it does not cost us 
anything.

Thanks,
/Erik

On 2016-09-19 21:36, Carsten Varming wrote:
> Dear Kim,
>
> Reading a volatile field updated by cmpxchg does not need an acquire 
> operation.
>
> BTW. The specification in atomic.hpp says cmpxchg provides: "<fence> 
> compare-and-exchange <membar StoreLoad|StoreStore>". The release is 
> part of the fence. Are you suggesting that there is a release after 
> the exchange?
>
> Carsten
>
> On Mon, Sep 19, 2016 at 3:18 PM, Kim Barrett <kim.barrett at oracle.com 
> <mailto:kim.barrett at oracle.com>> wrote:
>
>     > On Sep 19, 2016, at 2:26 PM, Carsten Varming <varming at gmail.com
>     <mailto:varming at gmail.com>> wrote:
>     >
>     > Dear Erik,
>     >
>     > According to orderAccess.hpp an acquire is supposed to be paired
>     with a release. It doesn't look like there is any synchronization
>     on the data written to the time stamp array, so what exactly is
>     going on?
>     >
>     > Carsten
>
>     _time_stamps gets written with a cmpxchg_ptr (line 63 of
>     gcTaskThread.cpp), which includes release semantics for the write;
>     see atomic.hpp.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160920/5ffefa1d/attachment.htm>