GeeCON Prague 2014*
The moose likes Threads and Synchronization and the fly likes Is read/writing from/in ConcurrentHashMap in ConcurrentHashMap thread safe? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Is read/writing from/in ConcurrentHashMap in ConcurrentHashMap thread safe?" Watch "Is read/writing from/in ConcurrentHashMap in ConcurrentHashMap thread safe?" New topic
Author

Is read/writing from/in ConcurrentHashMap in ConcurrentHashMap thread safe?

Cristian Vrabie
Ranch Hand

Joined: Jul 09, 2008
Posts: 71
Basically I have a ConcurrentHashMap nested in another ConcurrentHashMap.

Is and thread safe?
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Each map is synchronized separately, and the method calls you show are not different than handling the calls on different lines:

So getting the Map from a is thread safe in that a will not be modified while the get() occurs. Similarly getting the String from the second map is safe in that the second map can not be modified while the get() operation occurs. However, when the a.get() method returns, the lock on a is released, so a may be modified before/while the second map is being accessed.

Similarly the below code does not prevent the outer map from being modified or read while the inner map is modified.


This would be relatively safe, since the maps are independent, removing the inner map from the outer map while modifying the inner map would not leave either map in an inconsistent state - at least for general purposes. If you have a specific need to make sure that the outer map is not modified while the inner map is accessed then you would need to manually lock on the outer map.


Steve
Alan Mehio
Ranch Hand

Joined: Apr 04, 2005
Posts: 73


So getting the Map from a is thread safe in that a will not be modified while the get() occurs.



Just to clarify something here, the ConcurrentHashMap retrieval operations do NOT entail locking

it based on a volatile variable of the Value in the Map.Entry as below which make the changes visible to any other thread trying to read the value.



In general, I do not think the below is thread safe since the data may get corrutped and may result in something which is not requested

String value = a.get("key1").get("key2");

Imagine the scenario that a thread A tryies to obtain the Map based on the given Key2 while thread B changes the value for the key2


Cheers
Alan Mehio




Regards,
Alan Mehio
London, UK
Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192
A hash table supporting full concurrency of retrievals and adjustable expected concurrency for updates. This class obeys the same functional specification as Hashtable, and includes versions of methods corresponding to each method of Hashtable. However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access. This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details.


ConcurrentHashMap API
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18876
    
  40

Alan Mehio wrote:


So getting the Map from a is thread safe in that a will not be modified while the get() occurs.



Just to clarify something here, the ConcurrentHashMap retrieval operations do NOT entail locking

it based on a volatile variable of the Value in the Map.Entry as below which make the changes visible to any other thread trying to read the value.

In general, I do not think the below is thread safe since the data may get corrutped and may result in something which is not requested

String value = a.get("key1").get("key2");

Imagine the scenario that a thread A tryies to obtain the Map based on the given Key2 while thread B changes the value for the key2

Cheers
Alan Mehio




Okay, the statement is true -- the concurrent hashmap does not use synchronization. It is based on volatile variables.... But ... if the definition of thread safe, means that you will not get a corruption, when two threads try to use the concurrent hashmap at the same time, then it is thread safe.

The concurrent hashmap does use the atomic libraries. And as such, it uses optimistic locking.... but it does use locking. This means that many threads can put and get from the hashmap concurrently, and no corruption should result. In fact, it should behave just like a regular synchronized hashmap -- except that it is has higher performance.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
 
GeeCON Prague 2014
 
subject: Is read/writing from/in ConcurrentHashMap in ConcurrentHashMap thread safe?