ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From JOAQUIN GUANTER GONZALBEZ <x...@tid.es>
Subject Locks and AMBARI-4930
Date Mon, 14 Apr 2014 07:27:23 GMT
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message