[concurrency-interest] Reading a volatile vs uncontented lock

Vitaly Davidovich vitalyd at gmail.com
Wed Feb 13 13:59:39 EST 2013


That's more or less correct :).  Volatile write will cause store buffer to
drain before CPU can proceed to next instruction.  Cache line
invalidation/request-for-ownership coherence traffic is part of normal
store operations as well (once the store makes its way to L1).

Sent from my phone
On Feb 13, 2013 1:46 PM, <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<Concurrency-interest at cs.oswego.edu>
>>> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>[1]
>>>
>>
>>
>>
>> Links:
>> ------
>> [1] 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 <Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/**listinfo/concurrency-interest<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/f14b0ff5/attachment-0001.html>


More information about the Concurrency-interest mailing list