[concurrency-interest] Reading a volatile vs uncontented lock

Nathan Reynolds nathan.reynolds at oracle.com
Wed Feb 13 11:54:09 EST 2013


Reading a volatile on x86 is translated to a simple "mov" instruction.  
Obtaining a lock is a bit more involved.  If the lock is biased, then 
the thread will simply have to check to make sure it is still the 
owner.  It won't have to execute any atomic instructions.  If the lock 
is not biased, then it will have to execute an atomic instruction.  In 
the latter case, the atomic instruction is going to cost a lot.  If the 
former case, the instructions building up to the check and the check 
itself will cost much more than a "mov" instruction.  So, I would 
recommend reading the volatile... unless your intended platforms have a 
significant overhead for reading a volatile.

An alternative might be AlmostFinalValue 
(http://weblogs.java.net/blog/forax/archive/2011/12/17/jsr-292-goodness-almost-static-final-field). 
I haven't played with this yet.  However, it seems to promise the 
ability to have a field optimized as if it were final yet allow for it 
to be safely mutated.  The penalty is that every time the field is 
updated, the code using the field is deoptimized (i.e. runs as bytecode) 
and then is optimized again later by JIT.  So, the overall performance 
might be better than reading a volatile depending upon how many 9s 
follow the decimal point when you say (99%+).

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 2/13/2013 9:36 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
> 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/9f1dbeff/attachment.html>


More information about the Concurrency-interest mailing list