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 <nigro....@gmail.com> 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 <jean-p...@bempel.fr
>> 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 <sitnikov...@gmail.com>
>>> 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 mechanical-sympathy+unsubscr...@googlegroups.com.
>>>> 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 mechanical-sympathy+unsubscr...@googlegroups.com.
>>> 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 mechanical-sympathy+unsubscr...@googlegroups.com.
> 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 mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
