[concurrency-interest] Stricter read ordering

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Apr 23 10:58:54 EDT 2014

+1. Dragging us back to StampedLock example, the rationale for doing
ordered reads is to avoid writes on the read path.

Barring the locks (scalability hit), volatile writes / releasing stores
(still a potential scalability hit), or putting (x, y) into a wrapper
instance (cache misses, yay!), the only thing you are left with is
ordering the reads with fences.

If reads greatly out-weight writes, plus the data is encapsulateable
into the single instance, plus one possible cache miss is not an issue,
I would prefer to have the actual wrapper instance, though. I think
that's Peter Kaiser's point, although OP's example is greatly
simplified, and OP's non-simplified case may invalidate any of these


On 04/23/2014 06:29 PM, Tobias Lindaaker wrote:
> That is one of the approaches we have in our benchmark suite for 
> this, and we also concluded that the CAS in read() would have a too 
> substantial impact on the scalability of the algorithm.
> -tobias
> On 23 Apr 2014, at 16:16 , Roman Elizarov <elizarov at devexperts.com> 
> wrote:
>> It will not scale, though, if there are many concurrent readers, 
>> because of the CAS in read path.
>> -Roman

More information about the Concurrency-interest mailing list