• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

ReentrantReadWriteLock's lock mechanism

 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I'm using the ReentrantReadWriteLock to synchronize my caching. I also read the API of the ReentrantReadWriteLock. So I run the following example code :



and expect the outputs shoud always look like:


t4 get the read lock
t4 get the read lock
t4 release read lock
t4 release read lock
t1 get the write lock
t1 get the read lock
t1 release read lock
t1 release write lock
or
t1 get the write lock
t1 get the read lock
t1 release read lock
t1 release write lock
t4 get the read lock
t4 get the read lock
t4 release read lock
t4 release read lock



However, i was surprised by some of the outputs:


case1 :
t1 get the write lock
t1 get the read lock
t1 release read lock
t4 get the read lock
t4 get the read lock
t4 release read lock
t4 release read lock
t1 release write lock


case2 :
t4 get the read lock
t4 get the read lock
t4 release read lock
t1 get the write lock
t1 get the read lock
t1 release read lock
t1 release write lock
t4 release read lock



From my unstanding about the the ReentrantReadWriteLock: multiple threads can own a read lock simultaneously as long as the write lock isn't owned by any thread. Only one thread can own a write lock at any given time, and no thread can own a write lock while any thread owns a read lock.

Why the thread is not synchorzed?


The reason I tried to run t1 & t4 is because some of the methods will use the same scenario. Firstly I will cach every contractor information into a Class call ContractorItem, and then save it in the HashMap<Long, ContractorItem>.

In my updateRecord method:







Assuming there are two threads, thread A is is trying to update record 1, and thread B is trying to read the infromation of record 1. According to my above code (the output result of t1 & t4), the thread B may read the information of record 1 after the thread A pass the getContractor method but not release the write lock. It may return the wrong result because the record 1 has been updated yet.

My question is : how can I avoid this situation? am I used the ReentrantReadWriteLock correctly?


Last but not least, this is not important, but i just want to know:
I tried to run the Thread t2, and it will cause dead lock. Why?


Thank you in advance.





 
It is no measure of health to be well adjusted to a profoundly sick society. -Krishnamurti Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic