[concurrency-interest] ConcurrentMap consistencyrequirementsconfusion

Joe Bowbeer joe.bowbeer at gmail.com
Sat Dec 10 17:32:22 EST 2011

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.


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/a9769eae/attachment.html>

More information about the Concurrency-interest mailing list