[concurrency-interest] Stricter read ordering
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.
> On 23 Apr 2014, at 16:16 , Roman Elizarov <elizarov at devexperts.com>
>> It will not scale, though, if there are many concurrent readers,
>> because of the CAS in read path.
More information about the Concurrency-interest