Does ReadWriteLock Allow Keyword Sync?

Question

As suggested in several answers to this question:

What is this blocking technology called?

I implemented ReentrantReadWriteLock and saw great speed (I knew there was some lock in one class, and using the reentrant lock helped speed up the process).

But now I'm wondering: if inside the class all access (both read and write) is done by first locking the read lock or write lock, does this mean that the synchronized keyword should not be used anymore in this class?

For example, here is one official Java 1.6 example found at http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html

class RWDictionary { private final Map<String, Data> m = new TreeMap<String, Data>(); private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); private final Lock r = rwl.readLock(); private final Lock w = rwl.writeLock(); public Data get(String key) { r.lock(); try { return m.get(key); } finally { r.unlock(); } } public String[] allKeys() { r.lock(); try { return m.keySet().toArray(); } finally { r.unlock(); } } public Data put(String key, Data value) { w.lock(); try { return m.put(key, value); } finally { w.unlock(); } } public void clear() { w.lock(); try { m.clear(); } finally { w.unlock(); } } } 

There is no synchronize keyword.

Now I understand that one of the points of such locks should be faster than other methods (in this case, faster than synchronization), but what is the technical explanation for this?

Does the read / write lock in the class in each get / update method "replace" the synchronization keyword for these methods?

Answer 1

If you read javadocs on ReadWriteLock and Lock, they say in particular that Locks should provide the same memory semantics as the synchronized :

All lock implementations should provide the same semantics of memory synchronization as the built-in monitor lock, as described in the Java Language Specification, third edition (memory model 17.4):

(This is from a javadoc lock; ReadWriteLock refers to Lock to describe its semantics.)

So yes, it replaces the synchronized . In fact, you can replace every synchronized block in your Lock code and have the same semantics (and, depending on jvm, maybe even a slight performance improvement). But you would often trade a little faster for more words, and if you ever forget to unlock one of these locks, you can block your program.

What powers many of them are non-blocking algorithms ( compare-and-swap , which are their heart) in combination with the memory semantics of volatile fields, which indicate that if you write in a volatile field, any stream that subsequently reads this field should see at least the same state of the world that you saw when you wrote it. (They could also see some or all of what happened after they write.) These tools can make some pretty fast code, but they are also subtle and easily mistaken - it is almost always better to stay at a higher level (for example, ReadWriteLock that you are using).