[concurrency-interest] ConcurrentMap consistencyrequirementsconfusion

Joe Bowbeer joe.bowbeer at gmail.com
Sat Dec 10 17:51:20 EST 2011

By the way, the paragraph regarding synchronization actions and ordering
was cobbled together from sentences in the JMM spec:


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111210/6957cba5/attachment-0001.html>

More information about the Concurrency-interest mailing list