• 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

What to lock if I want to allow multi-thread access different keys in the LinkedHashMap

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Everyone

I was asked this question in an interview, to implement a Cache by using HashMap, but we want to allow different key's value to be updated by different thread at the same time. For example, thread 1 update key1 with value1, thread 2 is allowed to add new key2 with value2, thread3 has to wait to update key1 until thread1 has done.

I am not allowed to use concurrentHashMap or collections.synchronizedmap.

My answer was to create another map contains the same key and an object, using synchronized to lock on this object before update the value. However, interviewer didn't like it and he think there is another way to do it. After a few minus of struggling, I gave up and he told me the answer is to synchronized hashcode method. I can't think this through. I thought hashcode returns int, it doesn't make much sense to lock a int, right? Maybe I misunderstood him. Any ideas from you?


Many thanks,

 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kai Shen wrote:After a few minus of struggling, I gave up and he told me the answer is to synchronized hashcode method. I can't think this through. I thought hashcode returns int, it doesn't make much sense to lock a int, right?


Well, you wouldn't be locking an int, you'd be locking the instance that's being used as the key. But the interviewer's answer really doesn't make sense. For one thing, this would offer no protection against two instances that were equal, but were still different instances. Also the time to update an element in a HashMap is greater than the time required to call hashCode(), so even if hashCode() were an exclusive operation, there would still be a possibility of the HashMap being updated by two different threads, for the same key, at the same time, outside of the call to hashCode().

I would say the correct answer to that question was to use ConcurrentHashMap, and the interviewer deserves a slap on the head for thinking his "clever" solution would be better than the standard library solution. Do not trust this interviewer; he doesn't know what he's doing.
 
Kai Shen
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your reply. It kept me thinking for a while. I think the concurrentHashMap would be good to use.

He has also asked second question about how to getting rid of the old items in the existing cache. The answer was to use LinkedHashMap as you can implement LinkedHashMap as least-recently accessed. How would you say to make the LinkedHashMap thread-safe? Apart from using collections.synchronizedmap.

Many thanks,
 
Mike Simmons
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kai Shen wrote:He has also asked second question about how to getting rid of the old items in the existing cache. The answer was to use LinkedHashMap as you can implement LinkedHashMap as least-recently accessed. How would you say to make the LinkedHashMap thread-safe? Apart from using collections.synchronizedmap.


I would probably make a Cache class that contained a LinkedHashMap as a private instance variable. Synchronize the methods or blocks of the Cache class when they access the LinkedHashMap. No other code will be able to access the LHM without going through your synchronized code.
 
Sheriff
Posts: 3837
66
Netbeans IDE Oracle Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kai Shen wrote:He has also asked second question about how to getting rid of the old items in the existing cache. The answer was to use LinkedHashMap as you can implement LinkedHashMap as least-recently accessed. How would you say to make the LinkedHashMap thread-safe? Apart from using collections.synchronizedmap.


I'd say WeakHashMap generally serves this purpose. However, if the interviewer didn't like the ConcurrentHashMap, he probably won't like another well written, thoroughly tested standard library class either.

Though such questions are generally without merit, in this case it at least has shown you how little does the interviewer know of Java. Good to know if he ought to become your new boss...
 
Mike Simmons
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Martin Vajsar wrote:I'd say WeakHashMap generally serves this purpose. However, if the interviewer didn't like the ConcurrentHashMap, he probably won't like another well written, thoroughly tested standard library class either.


Well, WeakHashMap does something similar, but doesn't allow as much control over things like the size of the cache, or which specific elements get dumped. Whether that's necessary or desirable is debatable, but at least the LHM has some benefits.

Martin Vajsar wrote:Though such questions are generally without merit, in this case it at least has shown you how little does the interviewer know of Java. Good to know if he ought to become your new boss...


At least the second question was about something that's possible. It's much less objectionable than the first, in my opinion.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic