aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes ReentrantReadWriteLock understanding Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "ReentrantReadWriteLock understanding" Watch "ReentrantReadWriteLock understanding" New topic
Author

ReentrantReadWriteLock understanding

Bob Stone
Greenhorn

Joined: Mar 28, 2007
Posts: 12
Hi,
I am studying the mechanism of readLock() and writeLock() but is still hazy on them even read through the java.util.concurrent.locks API doc many times. I have encountered the following questions:

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 :-



would it be simpler if using sychronized() block ?

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 would be appreciated if I can have your input; if possible, could you suggest any material for my further reading?

Thanks in advance


Bob
Gabriel Vargas
Ranch Hand

Joined: May 16, 2007
Posts: 145
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.


Gabriel Vargas
SCJP, SCJD, now studying for SCWCD and working to be a better person
Bob Stone
Greenhorn

Joined: Mar 28, 2007
Posts: 12
Thanks Gabriel,

I am getting clear about the ReentrantLock / ReentrantReadriteLock but another question has arised in my brain.
Is it necessary to acquire a read-lock for reading in the content of a shared object? Assume that a shared object is visible to some reader threads and one writer thread, the writer thread can update the shared object if it successfully acquires a write-lock, and reader thread is allowed to access the object without having to acquire a read-lock; if so, can the reader threads retrieve up-to-date content?

Thanks for you help.
Bob Stone
Greenhorn

Joined: Mar 28, 2007
Posts: 12
Hi all,

I got the answer, how silly I am!

If the readers does not need to acquire a read lock before reading up, they can access the object while another thread is updating the object that will not maintain data integrity. Oh, I eventually understand why the concurrent API doc said read-lock can improve performance.
Gabriel Vargas
Ranch Hand

Joined: May 16, 2007
Posts: 145
Originally posted by Bob Stone:
Hi all,

I got the answer, how silly I am!

If the readers does not need to acquire a read lock before reading up, they can access the object while another thread is updating the object that will not maintain data integrity. Oh, I eventually understand why the concurrent API doc said read-lock can improve performance.


Hi Bob,

Yeap, this make me a bit confused at the beggining but later i learn how it works, and i learn step by step how new concurrent classes works, and its are wonderful (a bit confusing but wonderful), .
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: ReentrantReadWriteLock understanding