[concurrency-interest] ConcurrentMap consistencyrequirementsconfusion

Roland Kuhn rk at rkuhn.info
Sat Dec 10 18:08:51 EST 2011


Ah, sorry, I was confused by the possible absence of synchronizes-with edges: the actions alone are enough for 17.4.4 to mandate that volatile accesses of any kind may not be reordered. But the good thing is that I looked at the JVM spec again, which states this very clearly in section 8.7.

Sorry for the noise,

Roland

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

> By the way, the paragraph regarding synchronization actions and ordering was cobbled together from sentences in the JMM spec:
> 
> http://java.sun.com/docs/books/jls/third_edition/html/memory.html
> 
> If the JMM were purely sequentially consistent then every action could be viewed as a synchronization action.  And declaring all variables as volatile is one (horrible) way to ensure this.
> 
> On Sat, Dec 10, 2011 at 2:32 PM, Joe Bowbeer wrote:
> Volatile read/write is a synchronization action.  A synchronization order is a total order over all of the synchronization actions of an execution.  For each thread t, the synchronization order of the synchronization actions in t is consistent with the program order of t.
> 
> http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile
> 
> On Sat, Dec 10, 2011 at 2:11 PM, Roland Kuhn wrote:
> 
> 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/20111211/789ae1cd/attachment.html>


More information about the Concurrency-interest mailing list