Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Therefore writing an element within that Object (if it is e.g. a standard HashMap, performing a put() operation on it) will not establish such a relationship. Is that correct?</p> </blockquote> <p>Yes and no. There is always a happens-before relationship when you read or write a <code>volatile</code> field. The issue in your case is that even though there is a happens-before when you access the <code>HashMap</code> field, there is no memory synchronization or mutex locking when you are actually operating on the <code>HashMap</code>. So multiple threads can see different versions of the same <code>HashMap</code> and can create a corrupted data structure depending on race conditions.</p> <blockquote> <p>Now, with using a volatile ConcurrentHashMap, will writing an element to it establish the happens-before relationship, i.e. will the above still work?</p> </blockquote> <p>Typically you do <em>not</em> need to mark a <code>ConcurrentHashMap</code> as being <code>volatile</code>. There are memory barriers that are crossed internal to the <code>ConcurrentHashMap</code> code itself. The only time I'd use this is if the <code>ConcurrentHashMap</code> field is being changed often -- i.e. is non-final. </p> <p>Your code really seems like premature optimization. Has a profiler shown you that it is a performance problem? I would suggest that you just synchronize on the map and me done with it. Having two <code>ConcurrentHashMap</code> to solve this problem seems like overkill to me.</p>
    singulars
    1. This table or related slice is empty.
    1. POWith double-checked locking, does a put to a volatile ConcurrentHashMap have happens-before guarantee?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USGray
    1. USGray
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for your answer! I just wrote a very long comment, explaining why I think I need double-checked locking to begin with, just to realise I wasn't allowed to post anything long here. I'll get back to you in a few hours. For the time being, let me just throw the question back into the discussion: ***Is there a way to get that `ConcurrentHashMap` to use "`volatile` behaviour" when performing a `put()` on it?*** ;)
      singulars
      1. PO
      1. USChristian
    2. CO`ConcurrentHashMap` is fully concurrent. If you are asking if there is a happens-before relationship just by calling `setupsDone.put(...)` then the answer is yes but you don't know when the memory barrier is crossed. You do know that one has been crossed when the put finishes.
      singulars
      1. PO
      1. USGray
    3. COWill that happens-before relationship/memory barrier affect just the `ConcurrentHashMap` or - as it usually does - all variables that were visible to the writing Thread before it happened? (That is, will the write to `setupsDone` affect the visibility of `o` in other threads?)
      singulars
      1. PO
      1. USChristian
 

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