Good point, you're totally right: I have checked the CHM Javadoc and it won't say anything about "total" ordered operations. "By contract" we can't rely on such ordering: I would say that only if the map consumer is per-key we can assume that what I have written in the past answer is correct.
Il giorno lun 19 nov 2018 alle ore 16:57 Roman Leventov < [email protected]> ha scritto: > On the other hand, CHM didn't guarantee volatile store semantics of put(), > it only guaranteed HB between get() and put() with the same key. However, > it's the same for java.util.concurrent's Queue implementations, such as > ConcurrentLinkedQueue: Javadoc doesn't say that queue.offer() and poll() > are synchronization actions. > > On Mon, 19 Nov 2018 at 16:11, Francesco Nigro <[email protected]> wrote: > >> It would matter if you add some logic around it: >> >> //put of a value in the map with just a lazySet/putOrdered etc etc >> >> If (anyConsumerIsSleeping()) { >> wakeUpConsumers(); >> } >> >> If you won't have a full barrier the compile *could* reorder >> anyConsumerIsSleeping() ahead of the map.put, making possible to miss some >> consumer that is gone asleep :) >> The consumer example is more related to a queue case, but the idea is the >> same: you can't rely on any sequential consistent order on that operation >> (the volatile store), because without a volatile store that order doesn't >> exist. >> >> Il giorno lunedì 19 novembre 2018 14:04:15 UTC+1, Roman Leventov ha >> scritto: >>> >>> Does anybody understand what could go wrong if that CHM.Node.value >>> volatile write is relaxed to storeFence + normal write, and no fence at all >>> within the CHM.Node constructor (Hotspot JVM only)? >>> >>> On Mon, 19 Nov 2018, 10:28 Jean-Philippe BEMPEL <[email protected] >>> wrote: >>> >>>> Thanks Vladimir for your thoroughly explanation, I need to re read the >>>> Aleksey's JMM pragmatics 10 times more I guess 🙄 >>>> >>>> On Sun, Nov 18, 2018 at 7:35 PM Vladimir Sitnikov < >>>> [email protected]> wrote: >>>> >>>>> Jean-Philippe>is a write to value but no read of this va lue inside >>>>> the same thread, so the write is free to be reordered >>>>> >>>>> It ("reordering") does not really matter. >>>>> >>>>> For instance, >>>>> >>>>> 17.4.5. Happens-before Order> If the reordering produces results >>>>> consistent with a legal execution, it is not illegal. >>>>> >>>>> What matters is the set of possible "writes" that given "read" is >>>>> allowed to observe. >>>>> >>>>> >>>>> In this case, simple transitivity is enough to establish hb. >>>>> As Gil highlights, "negations" are a bit hard to deal with, and >>>>> Mr.Alexey converts the negations to a positive clauses: >>>>> https://shipilev.net/blog/2014/jmm-pragmatics/#_happens_before >>>>> >>>>> Shipilёv> Therefore, in the absence of races, we can only see the >>>>> latest write in HB. >>>>> >>>>> Note: we (as programmers) do not really care HOW the runtime and/or >>>>> CPU would make that possible. We have guarantees from JVM that "in the >>>>> absence of races, we can only see the latest write in HB". >>>>> CPU can reorder things and/or execute multiple instructions in >>>>> parallel. I don't really need to know the way it is implemented in order >>>>> to >>>>> prove that "CHM is fine to share objects across threads". >>>>> >>>>> Just in case: there are two writes for w.value field. >>>>> "write1" is "the write of default value" which "synchronizes-with the >>>>> first action in every thread" (see 17.4.4.) + "If an action x >>>>> synchronizes-with a following action y, then we also have hb(x, y)." (see >>>>> 17.4.5) >>>>> "write2" is "w.value=42" >>>>> >>>>> "value=0" (write1) happens-before "w.value=42" (write2) by definition >>>>> (17.4.4+17.4.5) >>>>> w.value=42 happens-before map.put (program order implies >>>>> happens-before) >>>>> read of u.value happens-before map.put (CHM guarantees that) >>>>> >>>>> In other words, "w.value=42" is the latest write in hb order for >>>>> u.value read, so u.value must observe 42. >>>>> JRE must ensure that the only possible outcome for the program in >>>>> question is 42. >>>>> >>>>> Vladimir >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "mechanical-sympathy" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "mechanical-sympathy" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "mechanical-sympathy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/mechanical-sympathy/lxlJBA49EoM/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
