[concurrency-interest] Reading a volatile vs uncontented lock
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.
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 2/13/2013 11:05 AM, Ariel Weisberg wrote:
> 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?
> 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
>> 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:
>>> 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?
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> <mailto:Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest