[concurrency-interest] Locking on local variables

Vitaly Davidovich vitalyd at gmail.com
Fri Jan 15 10:58:10 EST 2016


Looks like `r` is entered into the table within that synchronized block,
meaning it's potentially visible to other threads.  Holding its monitor
precludes other threads from observing state (as other threads will attempt
to acquire the monitor on it) until the initial insertion is complete (I'm
sure Doug can give a more thorough explanation).

On Fri, Jan 15, 2016 at 10:21 AM, Sleiman Jneidi <jneidi.sleiman at gmail.com>
wrote:

> Hi everyone,
>
> From what I know, locking on local variables is useless, Brian Goetz in
> his book gave the following as an example of a bad lock
>
>  synchronized(new Object()){
>   ..
>  }
>
> So I assume, the code above is equivalent to the following
>
>   Object o = new Object();
>
>  synchronized(o){
>   ..
>  }
>
> However looking at ConcurrentHashMap#computeIfAbsent I see the following
>
> Node<K,V> r = new ReservationNode<K,V>();
>     synchronized (r) {
>     ...
>     }
>
> Just curious, why is that?
>
>
> Thanks
> Sleiman
>
>
> _______________________________________________
> 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/20160115/1876cc42/attachment.html>


More information about the Concurrency-interest mailing list