Re: using ConcurrentHashMaps

From:

Robert Klemme <shortcutter@googlemail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 20 Apr 2007 18:00:33 +0200

Message-ID:

<58s6ciF2hgb0cU1@mid.individual.net>

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.

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.

robert