Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Cristian Vrabie
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Basically I have a ConcurrentHashMap nested in another ConcurrentHashMap.

Is and thread safe?
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Alan Mehio
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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



 
Ryan Beckett
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 21514
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic