I think this example is better:
class Foo{
int x;
}
Thread1:
Foo foo = new Foo();
foo.x = 10; (1)
concurrentMap.put("1", foo); (2)
Thread2:
Foo foo = concurrentMap.get("1"); (3)
if(foo!=null) print(foo.x); (4)
There is a happens-before edge between (1) and (2) due to program-order
rule. And also between (3) and (4) there is a happens-before edge due to
program-order rule.
And if thread2 sees the non null value, then there is a happens-before edge
between (2) and (3) due to either the volatile variable rule or monitor
lock rule (often this is called memory consistency effects on e.g. queues)
Since the happens-before relation is transitive, there is a happens-before
edge between (1) and (4).
On Mon, Sep 12, 2022 at 4:02 PM Alper Tekinalp <[email protected]>
wrote:
> From util.concurrent:
>
> > Actions in a thread prior to placing an object into any concurrent
> collection happen-before actions subsequent to the access or removal of
> that element from the collection in another thread.
>
> So ether one of threads will print (true, true) I guess.
>
> On Mon, Sep 12, 2022, 3:42 PM Peter Veentjer <[email protected]>
> wrote:
>
>> If T1 would run first, the content of the ConcurrentHashMap is (1,true),
>> and therefore there is only 1 value.
>>
>> So it will print 'true' and not 'true,true' because T2 has not run yet.
>>
>> On Mon, Sep 12, 2022 at 3:31 PM r r <[email protected]> wrote:
>>
>>> Hello,
>>> let's look for the following piece of code:
>>>
>>> c = new ConcurrentHashMap<Integer, Boolean>();
>>> T1:
>>> c.put(1, true);
>>> for (Boolean b : c.values()) {
>>> print(b);
>>> }
>>> T2:
>>> c.put(2, true);
>>> for (Boolean b : c.values()) {
>>> print(b);
>>> }
>>>
>>> Is it guaranteed by JMM that any thread (T1 or T2) prints true, true?
>>> To put it in another way, is it guaranteed that T1 or T2 observes both
>>> c.put?
>>>
>>> If yes / no, why?
>>> Thanks in advance for your time.
>>>
>>> --
>>> 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].
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msgid/mechanical-sympathy/0945e8e3-1070-4166-b269-1c4e6c49da3en%40googlegroups.com
>>> <https://groups.google.com/d/msgid/mechanical-sympathy/0945e8e3-1070-4166-b269-1c4e6c49da3en%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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].
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdAzirHPwyj%2B55%3D%2BSvkcLbKg80wzgspu8CDOGHOMD0Zchg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdAzirHPwyj%2B55%3D%2BSvkcLbKg80wzgspu8CDOGHOMD0Zchg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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].
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/CABKpSe5Z5ns%2BJ0O8cd-z0%2B%3DSgj75gr65LXbSur6W3BaELebN-A%40mail.gmail.com
> <https://groups.google.com/d/msgid/mechanical-sympathy/CABKpSe5Z5ns%2BJ0O8cd-z0%2B%3DSgj75gr65LXbSur6W3BaELebN-A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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].
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCPKSx5c0wj2mdXkg%3DHm1b4H65ZTx1K_vJ7d9P4KC2q4w%40mail.gmail.com.