[
https://issues.apache.org/jira/browse/HDFS-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651787#comment-16651787
]
BELUGA BEHR edited comment on HDFS-13990 at 10/16/18 2:17 PM:
--------------------------------------------------------------
We'd have to performance test it, but:
{quote}Whether or not a read-write lock will improve performance over the use
of a mutual exclusion lock depends on the frequency that the data is read
compared to being modified, the duration of the read and write operations, and
the contention for the data - that is, the number of threads that will try to
read or write the data at the same time. For example, a collection that is
initially populated with data and thereafter infrequently modified, while being
frequently searched (such as a directory of some kind) is an ideal candidate
for the use of a read-write lock. However, if updates become frequent then the
data spends most of its time being exclusively locked and there is little, if
any increase in concurrency. *Further, if the read operations are too short the
overhead of the read-write lock implementation (which is inherently more
complex than a mutual exclusion lock) can dominate the execution cost,*
particularly as many read-write lock implementations still serialize all
threads through a small section of code. Ultimately, only profiling and
measurement will establish whether the use of a read-write lock is suitable for
your application.
{quote}
[https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReadWriteLock.html]
I think if falls back to the KISS principal.
was (Author: belugabehr):
We'd have to performance test it, but:
{quote}
Whether or not a read-write lock will improve performance over the use of a
mutual exclusion lock depends on the frequency that the data is read compared
to being modified, the duration of the read and write operations, and the
contention for the data - that is, the number of threads that will try to read
or write the data at the same time. For example, a collection that is initially
populated with data and thereafter infrequently modified, while being
frequently searched (such as a directory of some kind) is an ideal candidate
for the use of a read-write lock. However, if updates become frequent then the
data spends most of its time being exclusively locked and there is little, if
any increase in concurrency. *Further, if the read operations are too short the
overhead of the read-write lock implementation (which is inherently more
complex than a mutual exclusion lock) can dominate the execution cost,*
particularly as many read-write lock implementations still serialize all
threads through a small section of code. Ultimately, only profiling and
measurement will establish whether the use of a read-write lock is suitable for
your application.
{quote}
> Synchronization Issue With HashResolver.java
> --------------------------------------------
>
> Key: HDFS-13990
> URL: https://issues.apache.org/jira/browse/HDFS-13990
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: federation
> Affects Versions: 3.2.0
> Reporter: BELUGA BEHR
> Assignee: BELUGA BEHR
> Priority: Minor
> Attachments: HDFS-13990.1.patch
>
>
> {code:java|title=HashResolver.java}
> private ConsistentHashRing getHashResolver(final Set<String> namespaces) {
> int hash = namespaces.hashCode();
> ConsistentHashRing resolver = this.hashResolverMap.get(hash);
> if (resolver == null) {
> resolver = new ConsistentHashRing(namespaces);
> this.hashResolverMap.put(hash, resolver);
> }
> return resolver;
> }
> {code}
> The {{hashResolverMap}} is a {{ConcurrentHashMap}} so presumably there is
> concern here for concurrency issues. However, there is no synchronization
> around this method, so two threads could call {{get(hash)}} both see a 'null'
> value and then both add two entries into the {{Map}}. Add synchronization
> here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
