[concurrency-interest] Reading a volatile vs uncontented lock

Stanimir Simeonoff stanimir at riflexo.com
Wed Feb 13 11:54:06 EST 2013

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:

> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130213/95f899d1/attachment.html>

More information about the Concurrency-interest mailing list