aspose file tools*
The moose likes Threads and Synchronization and the fly likes What to lock if I want to allow multi-thread access different keys in the LinkedHashMap Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "What to lock if I want to allow multi-thread access different keys in the LinkedHashMap" Watch "What to lock if I want to allow multi-thread access different keys in the LinkedHashMap" New topic
Author

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

Kai Shen
Greenhorn

Joined: Nov 24, 2008
Posts: 5
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,

Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3015
    
  10
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

Joined: Nov 24, 2008
Posts: 5
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
Ranch Hand

Joined: Mar 05, 2008
Posts: 3015
    
  10
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.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3610
    
  60

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
Ranch Hand

Joined: Mar 05, 2008
Posts: 3015
    
  10
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What to lock if I want to allow multi-thread access different keys in the LinkedHashMap