[concurrency-interest] Reading a volatile vs uncontented lock
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.
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.
>> On Wed, Feb 13, 2013 at 6:36 PM, <thurston at nomagicsoftware.com> wrote:
>>> 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?
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest 
>>  http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest