How to solve the Reader and Writer problem using wait() and notify()?

[Lion Z. Li]

Hi everyone,
Suppose there is shared HashMap and several reader and writer threads, how can we solve this concurrency problem using wait() and nofity() instead of synchronized method, if possible?

[Jim Yingst]

You can't use wait() or notify() without also synchronizing - you'd get an IllegalMonitorStateException. Plus, it's not at all clear what you're trying to do here. What do the different threads need to wait for? What' wrong with using synchronization to protect a shared resource?

[Lion Z. Li]

Jim Yingst,
Yes, you are right. There is nothing wrong with protecting shared data (that may bring about race condition) by using synchronization. We can utilize synchronizing in this reader/writer example.

class Reader implements Runable{
 private HashMap map;
 Reader(HashMap myMap) {
   map = myMap;
 }
 private Object reads(){
 //... say, lookup
 }
    
 public void run(){
  synchronized( map){
   reads();
  }
 }
}
class Writer implements Runable{
 private HashMap map;
 Writer(HashMap myMap) {
   map = myMap;
 }
 private void writes(){
 //...say , add pairs
 }
    
 public void run(){
  synchronized( map){
   writes();
  }
}
}
class Example{
  public static void main(String[] args){
    HashMap map = new HashMap();
    Reader r = new Reader(map);
    Writer w = new Writer(map);
    // initialize threads here.
    //.. 
  }
}

in above codes, both reads() and writes() are synchronized on the same HashMap object and thus shared data can be safely protected. However, in pratice when it comes to the case of reads()/reads() invocations in differrent threads we dont have to wait on synchronization. i.e. above may result in performance hit when there are many Readers involved. My question is IS there any solution better than this synchronizing-all one?(and i guess in this better solution wait()/notify() might show up).
THANKS FOR YOUR HELP!
[ November 14, 2003: Message edited by: LION Z. LI ]

[Jim Yingst]

There may be faster solutions, though I would usually advocate just using normal synchronizatin first, and see how good your performance is. Alternate solutions will probably be more complex, and may not be worth the extra effort.
Are reads more common than writes? Then you could use two maps - one, an unsynchronized map that you never make changes to, which you use for most of your accesses. Then you have another copy that you do make changes to, with sync. This is the master copy, with all data - but since it requires sync, you try no to use it too often. Periodically you can refresh the unsynchronized read-only copy by making a clone() of the master copy, then replacing the read-only copy with the new clone. This means that when lookups are performed on the read-only copy, then may not get the most recent information, unless a refrresh was performed recently. But this may be perfectly acceptable for some applications.
Note - some people may suggest that you don't need to make copies here, that you can syncronize for writes but not for reads using a single HashMap. This is usually a bad idea. In particular, if a put() ever causes the HashMap to resize while a read() is in effect, that read() may get completely erroneous data, or throw a ConcurrentModificationException or maybe even NullPointerException or IndexOutOfBoundsException. (It's hard to guarantee jsut what will happen.) It's one thing to retrieve data that's slightly old; it's another to throw an exception. (Even for data that's really in the HashMap; it was just being moved.) So be very careful if you try something like this.
I can't really think of any solutions involving wait/notify here. There might be one, but it's not coming to mind. Wait/notify is often a good efficient protocol, but I can't imagine how it would apply here.

[David Weitzman]

Doug Lea's util.concurrent package may have what you're looking for: a Map implementation synchronized on a read-write lock.