[concurrency-interest] Reading a volatile vs uncontented lock

Ariel Weisberg ariel at weisberg.ws
Wed Feb 13 13:05:06 EST 2013


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
([1]http://weblogs.java.net/blog/forax/archive/2011/12/17/jsr-292-goodn
ess-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%+).

[2]Nathan Reynolds | Architect | 602.333.9091
Oracle[3]PSR Engineering | Server Technology
On 2/13/2013 9:36 AM, [4]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
  [5]Concurrency-interest at cs.oswego.edu
  [6]http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________

Concurrency-interest mailing list

[7]Concurrency-interest at cs.oswego.edu

[8]http://cs.oswego.edu/mailman/listinfo/concurrency-interest

References

1. http://weblogs.java.net/blog/forax/archive/2011/12/17/jsr-292-goodness-almost-static-final-field
2. http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds
3. http://psr.us.oracle.com/
4. mailto:thurston at nomagicsoftware.com
5. mailto:Concurrency-interest at cs.oswego.edu
6. http://cs.oswego.edu/mailman/listinfo/concurrency-interest
7. mailto:Concurrency-interest at cs.oswego.edu
8. 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/78543309/attachment.html>


More information about the Concurrency-interest mailing list