[concurrency-interest] Re: synchronized vs ReentrantLock semantic

Dawid Kurzyniec dawidk at mathcs.emory.edu
Mon Jun 13 19:54:56 EDT 2005


Doug Lea wrote:

>
>> We all know that the AbstractQueuedSynchronizer provides atomicity.
>> But does it also ensure visibility?
>>
>>
>> In particular, is it safe to replace:
>>
>> synchronized (x) { ... }
>>
>> by:
>>
>> lock.lock(); try { ... } finally { lock.unlock(); }
>>
>>
>
> Yes! That's what the Lock spec says. Rely on it.
>
Great! So, what's the final answer on ReentrantReadWriteLock? Is it OK 
to use it to share non-volatiles then? Technically, RWLock is not a 
lock, so the spec does not explicitly apply, and RWLock doc does not say 
anything about memory synchronization. But since read and write locks 
share a synchronizer?...

BTW. Being too lazy to analyze the new JMM semantics just now, whilst 
still curious, let me ask: is it that the volatile read/write, performed 
by the AbstractQueuedSynchronizer, has implicit memory synchronization 
effects?

Thanks,
Dawid




More information about the Concurrency-interest mailing list