[concurrency-interest] Reading a volatile vs uncontented lock

Nathan Reynolds nathan.reynolds at oracle.com
Wed Feb 13 14:07:40 EST 2013


On x86, any write (volatile and non-volatile) invalidates all CPUs L1, 
L2 and L3 caches except for the physical core which did the write.  
Volatile writes have a memory fence added to ensure happens-before.  See 
http://g.oswego.edu/dl/jmm/cookbook.html .  The invalidation is required 
for cache coherency and forces the other cores to fetch the cache line 
to read it... hence get the most up to date version.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 2/13/2013 11:38 AM, thurston at nomagicsoftware.com wrote:
> Thanks for your responses.
> My understanding is that a volatile *write* does entail invalidating 
> all CPUs' L1,L2... caches that have cached the volatile reference.  
> But so does a lock/unlock cycle; is that more or less correct?
>
> On 2013-02-13 08:54, Stanimir Simeonoff wrote:
>> Obtaining the lock already requires reading a volatile and it
>> involves an atomic operation (volatile write at the least) + some
>> state store.
>> The lock release needs volatile store (or at least ordered write) +
>> queue checking if anyone has gone asleep waiting for the lock.
>>
>> Overall volatile reads are cheap and almost free on x86.
>>
>> Stanimir
>>
>> On Wed, Feb 13, 2013 at 6:36 PM, <thurston at nomagicsoftware.com> wrote:
>>
>>> Hello,
>>>
>>> I was wondering what requires more overhead: reading a volatile 
>>> reference or obtaining a lock when there is no contention.
>>>
>>> Essentially I have a single-reader scenario, where the common-path 
>>> (99%+) doesn't require either a volatile read or a lock; but if I 
>>> want to support a few very-rarely used cases, I can only make it 
>>> thread-safe by making the 99% case rely on a volatile read or obtain 
>>> a lock.
>>> Any guidelines?
>>>
>>> Thanks
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest [1]
>>
>>
>>
>> Links:
>> ------
>> [1] http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130213/1d48e9be/attachment.html>


More information about the Concurrency-interest mailing list