• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

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

 
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?
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • 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.
 
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



 
Ranch Hand
Posts: 194
  • 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
 
author
Posts: 23883
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux 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
 
    Bookmark Topic Watch Topic
  • New Topic