[concurrency-interest] Reading a volatile vs uncontented lock

Nathan Reynolds nathan.reynolds at oracle.com
Wed Feb 13 14:15:35 EST 2013


I don't see why not.  JIT probably can't do as much optimization work 
though.  Remi should comment since he wrote the code.  He is on this list.

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:40 AM, Markus Krainz wrote:
> Am 13.02.2013 17:54, schrieb Nathan Reynolds:
>> 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%+).
>
> This might be a stupid question, but is this AlmostFinalValue hack 
> valid for non-static fields?
> I was under impression that the thread starter wants to use this not 
> just for static members.
>
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> Regards, Markus 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130213/1e0d6644/attachment.html>


More information about the Concurrency-interest mailing list