ConcurrentHashMap needed with ReadWriteLock?

Question

I have a Map which is read by multiple threads but which is (from time to time) cleared and rebuilt by another thread.

I have surrounded all the access to this map with

readWriteLock.readLock().lock()
try {
  ... access myMap here...
} finally {
  readWriteLock.readLock().unlock()
}

... or the writeLock() equivalents, depending on the type of access.

My question is... will the ReadWriteLock ensure the updates to myMap are visible to the other threads (since they must wait until after the unlock() is called by the writing thread? Or, do I also need to make myMap a concurrent map, like ConcurrentHashMap?

I will probably do that, just to be safe, but I'd like to understand better.

@michalk a `map.clear()` followed by a bunch of `map.put()` calls. — Matthew McPeak, Aug 02 '19 at 19:53
`ConcurrentHashMap` is generally faster than `HashMap` even in non concurrent use - generally prefer `ConcurrentHashMap`. — Boris the Spider, Aug 02 '19 at 20:11
@BoristheSpider But is everything inside my `try` block guarantee to "happen-before" the `unlock()`? And, if so, I am right in understanding that that means that readers will see the all the updates, even without using a `ConcurrentHashMap`? — Matthew McPeak, Aug 02 '19 at 20:56
Yup - if you're inside a lock then you guanteed happens before ordering. As long as you take the appropriate lock, `HashMap` is perfectly safe. — Boris the Spider, Aug 02 '19 at 21:00
@BoristheSpider that's a very interesting claim that ConcurrentHashMap is faster than regular one even in sequential code. Do you have any evidence? — ciamej, Aug 02 '19 at 22:41
Your question is back to front. What you don't need here is the *lock.* — user207421, Aug 03 '19 at 03:40
@user207421 Explain please? I don't want my reading threads to be able to access the map while it is being refreshed. How can I do that without the lock? — Matthew McPeak, Aug 03 '19 at 05:01

score 3 · Accepted Answer · answered Aug 02 '19 at 22:37

Yes, this should be fine even without a thread-aware map. The Javadoc for ReadWriteLock explicitly says:

All ReadWriteLock implementations must guarantee that the memory synchronization effects of writeLock operations (as specified in the Lock interface) also hold with respect to the associated readLock. That is, a thread successfully acquiring the read lock will see all updates made upon previous release of the write lock.

(Of course, by using a reader/writer lock at all you depend on the map supporting concurrent lookups from different threads. One could imagine clever data structure that try to save time overall by mutating some internal cached state during a lookup. But the standard collections such as HashMap will not do that).

ConcurrentHashMap needed with ReadWriteLock?

1 Answers1