• 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

Optimum synchronization model

 
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic