Databases
StackOverflow2013
Postsdbo
POWith double-checked locking, does a put to a volatile ConcurrentHashMap have happens-before guarantee?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWith double-checked locking, does a put to a volatile ConcurrentHashMap have happens-before guarantee?
    primarykey
    data
    text
    <p>So far, I have used double-checked locking as follows:</p> <pre><code>class Example { static Object o; volatile static boolean setupDone; private Example() { /* private constructor */ } getInstance() { if(!setupDone) { synchronized(Example.class) { if(/*still*/ !setupDone) { o = new String("typically a more complicated operation"); setupDone = true; } } } return o; } }// end of class </code></pre> <p>Now, because we have groups of threads that all share this class, we changed the <code>boolean</code> to a <code>ConcurrentHashMap</code> as follows:</p> <pre><code>class Example { static ConcurrentHashMap&lt;String, Object&gt; o = new ConcurrentHashMap&lt;String, Object&gt;(); static volatile ConcurrentHashMap&lt;String, Boolean&gt; setupsDone = new ConcurrentHashMap&lt;String, Boolean&gt;(); private Example() { /* private constructor */ } getInstance(String groupId) { if (!setupsDone.containsKey(groupId)) { setupsDone.put(groupId, false); } if(!setupsDone.get(groupId)) { synchronized(Example.class) { if(/*still*/ !setupsDone.get(groupId)) { o.put(groupId, new String("typically a more complicated operation")); setupsDone.put(groupId, true); // will this still maintain happens-before? } } } return o.get(groupId); } }// end of class </code></pre> <p>My question now is: If I declare a standard <code>Object</code> as <code>volatile</code>, I will only get a happens-before relationship established when I read or write its reference. Therefore writing an element within that Object (if it is e.g. a standard <code>HashMap</code>, performing a <code>put()</code> operation on it) will <strong>not</strong> establish such a relationship. <strong><em>Is that correct?</em></strong> (What about reading an element; wouldn't that require to read the reference as well and thus establish the relationship?)</p> <p>Now, with using a volatile ConcurrentHashMap, <strong><em>will writing an element</em></strong> to it <strong><em>establish the happens-before relationship, i.e. will the above still work</em></strong>?</p> <p><sub><strong>Update: The reason for this question and why double-checked locking is important:</strong> What we actually set up (instead of an Object) is a <code>MultiThreadedHttpConnectionManager</code>, to which we pass some settings, and which we then pass into an <code>HttpClient</code>, that we set up, too, and that we return. We have up to 10 groups of up to 100 threads each, and we use double-checked locking as we don't want to block each of them whenever they need to acquire their group's <code>HttpClient</code>, as the whole setup will be used to help with performance testing. Because of an awkward design and an odd platform we run this on we cannot just pass objects in from outside, so we hope to somehow make this setup work. (I realise the reason for the question is a bit specific, but I hope the question itself is interesting enough: <strong><em>Is there a way to get that <code>ConcurrentHashMap</code> to use "volatile behaviour", i.e. establish a happens-before relationship, as the <code>volatile boolean</code> did, when performing a <code>put()</code> on the <code>ConcurrentHashMap</code>?</em></strong> ;)</sub></p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USChristian
    1. USChristian
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWith double-checked locking, does a put to a volatile ConcurrentHashMap have happens-before guarantee?
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload