[concurrency-interest] Reading a volatile vs uncontented lock

thurston at nomagicsoftware.com thurston at nomagicsoftware.com
Wed Feb 13 13:38:19 EST 2013


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



More information about the Concurrency-interest mailing list