You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by JOAQUIN GUANTER GONZALBEZ <xi...@tid.es> on 2014/04/14 09:27:23 UTC

Locks and AMBARI-4930

Hi devs,

I am trying to fix https://issues.apache.org/jira/browse/AMBARI-4930 since it is becoming a blocking issue for us. I am taking a look at the code and I am seeing this locking pattern in ClusterImpl.java:

    clusterGlobalLock.writeLock().lock();
    try {
      writeLock.lock();
      try {
            […]
      } finally {
        writeLock.unlock();
      }
    } finally {
      clusterGlobalLock.writeLock().unlock();
    }

Both “clusterGlobalLock” and “writeLock” are declared as private instance variables and both have the same type (ReentrantReadWriteLock), but “clusterGlobalLock” is being exposed through the interface and other classes are using it (for example, ServiceImpl.java). The part I don’t understand is this pattern:

    clusterGlobalLock.readLock().lock();
    try {
      writeLock.lock();
      try {
        […]
      } finally {
        writeLock.unlock();
      }
    } finally {
      clusterGlobalLock.readLock().unlock();
    }

Why is the globalLock being locked on read but the internal writeLock being used (instead of readLock)? If the method is changing the clusters value (for example, “setClusterName”), why is it locking on read in “clusterGlobalLock”?

Thanks,
Ximo.

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Re: Locks and AMBARI-4930

Posted by Myroslav Papyrkovskyy <mp...@hortonworks.com>.
Hello Ximo.

Code you are talkong about is general pattern used in cluster structure
classes. General approach is following:
- clusterGlobalLock.writeLock and local write lock are aquired when method
modify dependencies between cluster objects (generally adds or removes
underlying objects like services or components),
- both read locks for read methods
- clusterGlobalLock.readLock and local write lock when method modifies only
current object, so other objects in cluster structure can be accessed for
read and local modification.

Regards,
Myroslav.


On Mon, Apr 14, 2014 at 10:27 AM, JOAQUIN GUANTER GONZALBEZ <xi...@tid.es>wrote:

> Hi devs,
>
> I am trying to fix https://issues.apache.org/jira/browse/AMBARI-4930since it is becoming a blocking issue for us. I am taking a look at the
> code and I am seeing this locking pattern in ClusterImpl.java:
>
>     clusterGlobalLock.writeLock().lock();
>     try {
>       writeLock.lock();
>       try {
>             [...]
>       } finally {
>         writeLock.unlock();
>       }
>     } finally {
>       clusterGlobalLock.writeLock().unlock();
>     }
>
> Both "clusterGlobalLock" and "writeLock" are declared as private instance
> variables and both have the same type (ReentrantReadWriteLock), but
> "clusterGlobalLock" is being exposed through the interface and other
> classes are using it (for example, ServiceImpl.java). The part I don't
> understand is this pattern:
>
>     clusterGlobalLock.readLock().lock();
>     try {
>       writeLock.lock();
>       try {
>         [...]
>       } finally {
>         writeLock.unlock();
>       }
>     } finally {
>       clusterGlobalLock.readLock().unlock();
>     }
>
> Why is the globalLock being locked on read but the internal writeLock
> being used (instead of readLock)? If the method is changing the clusters
> value (for example, "setClusterName"), why is it locking on read in
> "clusterGlobalLock"?
>
> Thanks,
> Ximo.
>
> ________________________________
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.