[concurrency-interest] Reading a volatile vs uncontented lock

Nathan Reynolds nathan.reynolds at oracle.com
Wed Feb 13 13:36:08 EST 2013

Correct.  Biased locking is only for "synchronized" locks and none of 
the java.util.concurrent locks.

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 11:05 AM, Ariel Weisberg wrote:
> Hi,
> Biased locking only comes into play for intrinsic locks right? If you 
> are using ReentrantLock or a class that uses ReentrantLock you won't 
> get the benefit of biased locking?
> Thanks,
> Ariel
> On Wed, Feb 13, 2013, at 11:54 AM, Nathan Reynolds wrote:
>> 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
>> OraclePSR 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
>> _________________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu 
>> <mailto: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/5c5fae53/attachment.html>

More information about the Concurrency-interest mailing list