[concurrency-interest] Reading a volatile vs uncontented lock

Markus Krainz ldm at gmx.at
Wed Feb 13 13:40:26 EST 2013


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/4f9881bf/attachment.html>


More information about the Concurrency-interest mailing list