[concurrency-interest] ConcurrentMap consistencyrequirementsconfusion

Roland Kuhn rk at rkuhn.info
Sat Dec 10 17:11:52 EST 2011

Is the compiler not free to re-order the two statements in each thread? They do not depend on each other and volatile does not add anything that I can see: volatile writes may not be moved “earlier” across other writes and volatile reads may not be moved “later” across other reads. And of course a read of one variable may not be moved “earlier” across a write to that variable. But none of the forbidden things is necessary to break this, or am I missing something?

On Dec 10, 2011, at 23:01 , Joe Bowbeer wrote:

> Making all variables volatile should force sequentially consistent execution over all, and program-order execution in each thread.
> I think it's reasonable to model ConcurrentMap as having a separate lock or volatile per cell, even though in practice the locks are striped.  Is the CM spec even less constrained than this?
> On Sat, Dec 10, 2011 at 12:53 PM, Roland Kuhn wrote:
> I do not fully understand what you want to demonstrate here wrt. synchronization order; allow me to rephrase with volatile vars:
> Thread 1:
> A) a = 1;
> B) r1 = b;
> Thread 2:
> C) b = 1;
> D) r2 = a;
> If I read the spec correctly, the following synchronization order would be consistent:
> start -> r.b -> r.a -> w.a -> w.b -> stop
> There are no synchronizes-with relations in here, and the only happens-before relations are between start and each read and between each write and stop, respectively.
> There is no write where a following read sees a write which sw/hb the write. Intra-thread semantics do not add anything since the write and the read in each thread are not related.
> > Can I get r1 = r2 = "0"?  Presumably not.
> >
> Well, please correct my reasoning above, but I think it would be legal. And if it would be legal for volatile vars, why should it not be for CHMs?
> Regards,
> Roland
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[scala-debate on 2009/10/2]
Viktor Klang: When will the days of numerical overflow be gone?
Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111210/e1296ca3/attachment.html>

More information about the Concurrency-interest mailing list