• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

ReentrantReadWriteLock understanding

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bob Stone
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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), .
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic