[concurrency-interest] Reading a volatile vs uncontented lock

Vitaly Davidovich vitalyd at gmail.com
Wed Feb 13 11:44:48 EST 2013

Lock will have higher overhead.  Depending on CPU, volatile load can be as
cheap as a normal load + a compiler barrier.  If you hit L1 cache, then
perf is going to be almost like normal load that gets enregistered by JIT.

Sent from my phone
On Feb 13, 2013 11:39 AM, <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/bbe17e1a/attachment.html>

More information about the Concurrency-interest mailing list