[concurrency-interest] Reading a volatile vs uncontented lock

Vitaly Davidovich vitalyd at gmail.com
Wed Feb 13 13:38:47 EST 2013


That's correct.

Sent from my phone
On Feb 13, 2013 1:26 PM, "Ariel Weisberg" <ariel at weisberg.ws> 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
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130213/d642a87b/attachment-0001.html>


More information about the Concurrency-interest mailing list