This week's book giveaway is in the Server-Side JavaScript and NodeJS forum.
We're giving away four copies of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques and have Mario Casciaro & Luciano Mammino on-line!
See this thread for details.
Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!
  • 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Publication via ConcurrentHashMap

 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Putting a key/value into a ConcurrentHashMap does constitute safe publication for a different thread reading the map, doesn't it?

Meaning, if I change the members of an object and then put it as a value in key, value pair and then lookup the key in a different thread, I will see the updated members.

I also believe that if I do a put into the ConcurrentHashMap and then change the members of the value that was just put, there is no guarantee that a thread that does a get on the key will see the updates to the members of the value.

Wrong on any count?
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you modify the fields of an object before you put it to an instance of ConcurrentHashMap then the updated fields of that object will be visible to any thread that performs a get operation on that same map instance. If thread A performs writes, including writes to non-volatile fields or fields not guarded by a lock (i.e. synchronization) before a write to a volatile or guarded field, those writes are are guaranteed to be visible to thread B after it performs a read of the volatile / guarded field. ConcurrentHashMap can offer this happens-before visibility guarentee partly because it uses volatile variables to achieve lock-free get operations. So, as per my (limited) undertstanding, you're right on both counts, unless the field you alter modify after putting the object to the ConcurrenHashMap is declared volatile or guarded by a lock itself, of course.
 
Evil is afoot. But this tiny ad is just an ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic