Re: using ConcurrentHashMaps
On Apr 20, 11:00 am, Robert Klemme <shortcut...@googlemail.com> wrote:
On 20.04.2007 17:40, Vaibhav wrote:
On Apr 20, 10:30 am, Robert Klemme <shortcut...@googlemail.com> wrote:
On 20.04.2007 17:17, Vaibhav wrote:
I have following code in my program. Is it possible to use a
ConcurrentHashMap in this scenario?
private Map mymap = Collections.synchronizedMap(new HashMap());
If you access your map only in synchronized blocks like below you do not
need a synchronizedMap.
I do have to access my map in other parts of the code, where I do not
need to synchronize.
Ah, ok. Just wanted to make sure.
It is not clear to me how the code should look if I use a
concurrentHashMap..
You can just replace your map with the CHM and remove the synchronized
blocks. Additionally you do need to change the code that modifies the
map (check the interface) in order to remedy the effects of an update
that occurs in another thread between your testing of a key and
inserting it.
thats sounds good. I have another question along the same line.. under
which scenario we should not remove synchronize block while migrating
to CHM? If there is such a block.. is it still ok to use
synchronize(m) or just stay with SHM in that case..
My question is that can I avoid synchronize block in this case if I
were using a concurrentHashMap.
public MyHandle getHandle(String id) {
MyHandle handle = null;
MyHandle tmpHandle;
synchronized(mymap) {
Iterator it = this.mymap.values().iterator();
while(it.hasNext()) {
tmpHandle = (MyHandle)it.next();
if(id.equals(MyHandle.getId())) {
handle = tmpHandle;
break;
}
}
//}
return handle;
}
Certainly you can use a ConcurrentHashMap but it would be more efficient
if you used the id as map key.
I unerstand the efficiency part when using id as key. Can you explain
how that will be thread safe?
That ConcurrentHashMap is partitioned internally (you can see it in the
source code). Also, no synchronized primitives are used internally but
a ReadWriteLock which is faster than the former.
I guess my confusion is because I am not clear how the local variables
in the method are being effected by multiple threads..
will the threads be sharing tmpHandle.. I am thinking it could be a
problem if they did and we synchronized on id..
thanks again! :)