wood burning stoves 2.0*
The moose likes Threads and Synchronization and the fly likes Optimum synchronization model Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Optimum synchronization model" Watch "Optimum synchronization model" New topic
Author

Optimum synchronization model

Ranadhir Nag
Ranch Hand

Joined: Mar 09, 2006
Posts: 138
A nativeLRUCache(not using LinkedHashMap):

public class NativeLRUCache<E,V>{

HashMap<E,V> data=new HashMap<E,V>();
NativeLinkedQueue<E> iq=new NativeLinkedQueue<E>();
final Integer bound;
public NativeLRUCache(Integer bound){
this.bound=bound;
}

public void put(E e,V v){
if(iq.contains(e)!=null)//=>iteration
{
iq.displace(e);//=>iteration - bringing e to the head
data.put(e,v);
}
else{
if(data.size() < bound){
data.put(e,v);
iq.put(e);
}else{
E cull=iq.accomodate(e);//=>removing tail item to accomodate 'e' at the head
data.remove(cull);
data.put(e,v);
}
}

}

What will be the most optimum locking model here?
The idea is to inspect/update the hashmap and the linkedlist as a single atomic operation - and allowing concurrent readers/iterations.
Would appreciate and welcome any attempts - 'synchronized' and reader/writer(reentrantlock) seem too restrictive and complex respectively
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

It seems to me like the class should hold a ReadWriteLock (<- that is a link) to allow concurrent reads, while making writes block other things from interrupting. From the description it looks like you will probably need to put the entire put() method under a WriteLock (since it has to be done atomically). Is there a reason why the Keys (e) have to be stored in both the Queue and the Map? Can you make whatever the Queue is a view of the Map's keys (i.e. data.keySet())? It might simplify things.


Steve
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Optimum synchronization model