[jbossws-dev] [Design of JBoss Web Services] - Re: Why is the UMDM using ConcurrentHashMap?

[jason.greene@jboss.com]

ConcurrentHashMap usually does not lock on reads with a successful ConcurrentHashMap usually does not lock on reads with a successful result. However, if the entry does not exist, a lock is always held on the corresponding stripe. Along with the extra locking, it also adds more processing and memory overhead. All of this is of course needed to handle multiple concurrent writers (or the possibility of multiple concurrent writers).

However, since the UMD is written to only at the start, and only from one thread, no synchronization is needed, even in that single thread. So, since no locking is needed, there is no need for ConcurrentHashMap.

It could be argued though that ConcurrentHashMap would improve safety, since improper use of the UMD (a writer happens after eager initialization for example) would be slightly protected. However the problem is that this would only be protecting one of the many internal types within the UMD, so the overall access to it still can not allow for multiple writers, unless of course, it was redesigned to allow for the multiple writer scenario.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014598#4014598

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4014598