[concurrency-interest] Double Checked Locking in OpenJDK

Gregg Wonderly gergg at cox.net
Wed Aug 15 22:38:00 EDT 2012


I think that there could be some confusion happening here different than what the experts are confronting with their explanations.  I think that the terminology "happens before", could be misleading without being defined relative to "is ordered before" and "is ordered after" in program execution.

Order of execution between two threads can only happen when they purposely negotiate the order through shared state.

The "happens before" terminology relates to visibility of change, not which value you see when, across threads.  The subtlety of this example looks at the shared state of shared == null vs shared == new Vector().  But, its necessary to also understand program execution order is not guaranteed by any action of these two blocks of code, and that's why David says below, 

"Of course it is not guaranteed that the reader thread will see a non-null value of shared."

It's only guaranteed that the initialization of the Vector value is completed before it is assigned to the shared variable by the "happens before" created by the synchronized(local){} code segment.

A semaphore or other shared state and a "wait for state change" would have to occur, for the reader thread to be guaranteed to see a non-null value.

Is there away to talk about the visibility created by "happens before", with better terminology that would make developers more able to not slide into thoughts about "order of execution"?

Gregg Wonderly

On Aug 15, 2012, at 9:13 PM, "David Holmes" <davidcholmes at aapt.net.au> wrote:

> Chris,
> 
> Until the writer thread has entered its sync block it can not write to shared. So if the reader thread sees shared as non-null then the write must have happened and the sync block must have (at least) been entered.
> 
> Of course it is not guaranteed that the reader thread will see a non-null value of shared.
> 
> David
> 
>> -----Original Message-----
>> From: Chris Povirk [mailto:cpovirk at google.com]
>> Sent: Thursday, 16 August 2012 12:03 PM
>> To: dholmes at ieee.org
>> Cc: concurrency-interest at cs.oswego.edu
>> Subject: Re: [concurrency-interest] Double Checked Locking in OpenJDK
>> 
>> 
>>>>> local = new Vector();
>>>>> synchronized (local) {}
>>>>> shared = local;
>>>> 
>>>> construction happens before synchronized block
>>>> synchronized block happens before write
>>>> (=> construction happens before write)
>>> 
>>> Nope. construction happens-before end of synchronized block. 
>> write also happens-before end of synchronized block. roach-motel 
>> rules allow everything to be moved into the sync block.
>> 
>> True, I am being imprecise in treating the synchronized block as a
>> single action.
>>> Again use of object could be moved inside the sync-block. But 
>> sync-block here can not be entered until after other thread 
>> releases the lock. So that establishes the happens-before ordering:
>>> 
>>> everything in writer thread happens-before release of lock
>>> release of lock happens-before acquire of lock in second thread
>>> acquire of lock happens-before use of object
>>> => everything in writer thread happens-before use of object
>> 
>> I'm on board with this except for one part, which is apparently the
>> part where my thinking is too confusing for you to help me :)
>> 
>> "But sync-block here can not be entered until after other thread
>> releases the lock."
>> 
>> I agree that the threads can't be in the synchronized block at the
>> same time.  What I don't understand is what prevents the reader thread
>> from entering its block before the writer thread enters its block.
>> You give an explanation here:
>> 
>>> The above paragraph is confusing to me. The reader thread won't 
>> attempt to execute its sync block unless it sees the write to 
>> shared. The write to shared happens after the writer thread 
>> acquires the lock (and maybe after it releases it). So the reader 
>> will only attempt to acquire the lock once the writes have 
>> progressed to the point where shared was written, but it can't 
>> actually acquire the lock until all the writes are completed.
>> 
>> But does the mere fact that the reader thread sees the write to shared
>> establish a happens-before relationship between the read and the
>> write?  Surely it can't, or else it would be safe to publish the
>> object with no synchronized blocks at all... I think...?
>> 
> 
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest




More information about the Concurrency-interest mailing list