<br>Obtaining the lock already requires reading a volatile and it involves an atomic operation (volatile write at the least) + some state store.<br>The lock release needs volatile store (or at least ordered write) + queue checking if anyone has gone asleep waiting for the lock.<br>
<br>Overall volatile reads are cheap and almost free on x86.<br><br>Stanimir<br><br><div class="gmail_quote">On Wed, Feb 13, 2013 at 6:36 PM,  <span dir="ltr"><<a href="mailto:thurston@nomagicsoftware.com" target="_blank">thurston@nomagicsoftware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I was wondering what requires more overhead: reading a volatile reference or obtaining a lock when there is no contention.<br>
<br>
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.<br>

Any guidelines?<br>
<br>
Thanks<br>
<br>
______________________________<u></u>_________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.<u></u>oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/<u></u>listinfo/concurrency-interest</a><br>
</blockquote></div><br>