Hi Bob,
I also read Andrew's book, he some times show code more complicated than is required for the assigment(isn't neccesary write so complicated code), but in these parts he explains than it is only for learning purposes like ReentrantReadWriteLock, so
1. As I know the writeLock() is actually holding up a lock whereas readLock() doesn't; so why not simply using synchronized instead of readLock() if only implementing a thread-safe block? I brought Andrew's SCJD exam with J2SE 5 book in which the codes of DvdFileAccess.java :-
code:
public DVD getDvd(String upc) throws IOException {
...
recordNumbersLock.readLock().lock()
try {
...
} finally {
recordNumbersLock.readLock().unlock()
}
would it be simpler if using sychronized() block ?
yes, you can use a synchronized block or you can use ReentrantLock class and you exposes your reasons in your choices.txt.
2. Extend the above question, can a write thread place a lock on a share object while a reader thread has already held up a lock on the object and is processing some operations within the readLock block?
3. Can I say that the main purpose of readLock, other than polled, timed, and interruptible lock acquisition, is to guarantee memory visibility?
4. Is there any pre-defined preferences for readLock() or writeLock() acquisition?
I expose my thoughs about this class (my thoughs is i understand about that in Andrew's book
). I interpret write lock in the same way like a common reentrant lock (or a synchronized block), you have a monitor and you must acquire this to be excecuted, and a read lock is an improve than provides better performance when a class have a lot of reads and some writes. When you have read lock you can grant more read locks but none write lock, when you have a write lock you can't grant any read or write lock and the purpose is improve performace(i think this is the main idea of this class
). It is exposed with this paragraphs than i take from javadoc of ReentrantReadWriteLock:
This about of objective of performance:
ReentrantReadWriteLocks can be used to improve concurrency in some uses of some kinds of Collections. This is typically worthwhile only when the collections are expected to be large, accessed by more reader threads than writer threads, and entail operations with overhead that outweighs synchronization overhead..
And there about differences between read and write lock.
- Acquisition order
This class does not impose a reader or writer preference ordering for lock access. However, it does support an optional fairness policy. When constructed as fair, threads contend for entry using an approximately arrival-order policy. When the write lock is released either the longest-waiting single writer will be assigned the write lock, or if there is a reader waiting longer than any writer, the set of readers will be assigned the read lock. When constructed as non-fair, the order of entry to the lock need not be in arrival order. In either case, if readers are active and a writer enters the lock then no subsequent readers will be granted the read lock until after that writer has acquired and released the write lock.
- Reentrancy
This lock allows both readers and writers to reacquire read or write locks in the style of a ReentrantLock. Readers are not allowed until all write locks held by the writing thread have been released.
Additionally, a writer can acquire the read lock - but not vice-versa. Among other applications, reentrancy can be useful when write locks are held during calls or callbacks to methods that perform reads under read locks. If a reader tries to acquire the write lock it will never succeed.
- Lock downgrading
Reentrancy also allows downgrading from the write lock to a read lock, by acquiring the write lock, then the read lock and then releasing the write lock. However, upgrading from a read lock to the write lock is not possible.
You can see a complete view about this points here:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html I hope it helps you.