Re: JMM - is this program data race free?
Thanks a lot
pon., 24 paź 2022, 05:09 użytkownik Peter Veentjer
napisał:
> The program isn't clear to me. I guess you want something like this:
>
> int x;
> volatile int v;
>
> CPU1:
> write(x, 1) (1)
> write(v, 1)(2)
>
> CPU2
> read(v) (3)
> read(x)(4)
>
> Then there exists an execution where (4) sees value written by (1) it is
> in a data race with. E.g. (1)->(3)->(4).
>
> So since the program has at least 1 execution with a data race. So your
> observation that the program is not data race free, is correct.
>
> To resolve the data race, you want to do something like this:
>
> int x;
> volatile int v;
>
> CPU1:
> write(x, 1) (1)
> write(v, 1) (2)
>
> CPU2
> if(read(v)==1){ (3)
> print(read(x)); (4)
> }
>
> When (3) has observed the value written by (2) there is a happens-before
> edge between (2) and (3). And due to the program order between (1)/(2) and
> (3)/(4) and the transitive nature of happens-before, there is a
> happens-before edge between (1) and (4). So the value'1' should be printed.
>
> This program is data race free.
>
>
>
>
> On Sun, Oct 23, 2022 at 7:59 PM r r wrote:
>
>> int x;
>> volatile int v;
>>
>> write(x, 1) read(v)
>> write(v, 1) read(x)
>>
>> Is that program data race free? On my eye it is not not because there is
>> an execution that write(x, 1) and read(x) are not in happens-before
>> relationship.
>>
>> --
>> 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.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/9a25a145-5271-4f7a-ad3d-3633367becd4n%40googlegroups.com
>> <https://groups.google.com/d/msgid/mechanical-sympathy/9a25a145-5271-4f7a-ad3d-3633367becd4n%40googlegroups.com?utm_medium=email_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 mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCCq8bLneYkLR%3D4Ddbjfk1dsJ8RrGx%3DyPgssPvzYKuQiw%40mail.gmail.com
> <https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCCq8bLneYkLR%3D4Ddbjfk1dsJ8RrGx%3DyPgssPvzYKuQiw%40mail.gmail.com?utm_medium=email_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 mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/CAFKLJkwdYbY6PshKFd%3DHCv9OA2WA4gxXZxOv9N0GtUwutsKb%3DQ%40mail.gmail.com.
JMM - is this program data race free?
int x; volatile int v; write(x, 1) read(v) write(v, 1) read(x) Is that program data race free? On my eye it is not not because there is an execution that write(x, 1) and read(x) are not in happens-before relationship. -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/9a25a145-5271-4f7a-ad3d-3633367becd4n%40googlegroups.com.
Re: volatile reads does happen before volatile write in JMM?
Thanks!
czw., 15 wrz 2022 o 12:40 Peter Veentjer napisał(a):
>
>
> On Thu, Sep 15, 2022 at 11:43 AM r r wrote:
>
>> What about a such case:
>>
>> AtomicLong x;
>> volatile boolean v;
>>
>> T1:
>>v = true; (1)
>>long a = x.incrementAndGet(); // a == 1 (2)
>> T2:
>>long b = x.incrementAndGet(); // b == 2 (3)
>>
>> Do I understand correctly that if T2 observes that x == 2 it also means
>> that T2 observer v == true because of happens-before *(1) -hb-> (2)
>> -hb-> (3)*?
>>
>
> 'yes'.
>
> So imagine 'v' would be plain and you would have the following code:
>
> T1:
> v=true (1)
> x.incrementAndGet(); (2)
>
> T2:
> if(x.incrementAndGet()==2){ (3)
>print(v)(4)
> }
>
> If (3) observes (2), then there is a happens-before edge between (1) and
> (4) because:
>
> (1) happens-before (2) due to program order rule
> (2) happens-before (3) due to volatile variable rule
> (3) happens-before (4) due to program order rule
>
> Since happens-before is transitive, there is a happens-before edge between
> (1) and (4).
>
> So since we have a happens-before edge when v is plain, we certainly have
> a happens-before edge is v would be volatile.
>
>
>>
>> środa, 14 września 2022 o 14:04:16 UTC+2 r r napisał(a):
>>
>>> Thanks
>>>
>>> śr., 14 wrz 2022, 13:26 użytkownik Peter Veentjer
>>> napisał:
>>>
>>>>
>>>>
>>>> On Wed, Sep 14, 2022 at 1:51 PM r r wrote:
>>>>
>>>>> Hello,
>>>>> let's look for the following piece of code:
>>>>>
>>>>> int x;
>>>>> volatile boolean v; // v = false by default
>>>>> T1:
>>>>> x = 1; (1)
>>>>> v = true;(2)
>>>>> doSth(3)
>>>>>
>>>>> T2:
>>>>>doSth2(4)
>>>>>if (v) {} (5)
>>>>>
>>>>>
>>>>> When T2 observes that v == false in (5), does it mean that there is a
>>>>> happens-before relation (4) -> (5) -> (2) -> (3)?
>>>>>
>>>>
>>>> No.
>>>>
>>>> There can't be a happens-before edge between a read of v (5) and a
>>>> write of v (4).
>>>>
>>>> The volatile write/read will be ordered in the synchronization order,
>>>> but not in the synchronized-with order and therefore not ordered by
>>>> happens-before (since the happens-before order is the transitive closure
>>>> of the union of the synchronizes-with order and the program order).
>>>>
>>>> Only when a volatile read sees a particular volatile write, then there
>>>> is a happens-before edge from the write to the read, but never in the
>>>> opposite direction.
>>>>
>>>>
>>>>>
>>>>> What if v would be AtomicBolean?
>>>>>
>>>>
>>>> Doesn't change anything since an AtomicBoolean get/set has the same
>>>> semantics as a volatile read/write.
>>>>
>>>>
>>>>
>>>>> --
>>>>> 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-symp...@googlegroups.com.
>>>>> To view this discussion on the web, visit
>>>>> https://groups.google.com/d/msgid/mechanical-sympathy/faf3e288-f249-4d07-830b-7752bb41a472n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/mechanical-sympathy/faf3e288-f249-4d07-830b-7752bb41a472n%40googlegroups.com?utm_medium=email_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 mechanical-symp...@googlegroups.com.
>>>>
>>> To view this discussion on the web, visit
>>>> https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCqwmySqhNkHRKZcouwKf0F3oM%3DHb_byqLwY8D3Hyb-Gg%40mail.gmail.com
>>>> <https://groups.goog
Re: volatile reads does happen before volatile write in JMM?
What about a such case:
AtomicLong x;
volatile boolean v;
T1:
v = true; (1)
long a = x.incrementAndGet(); // a == 1 (2)
T2:
long b = x.incrementAndGet(); // b == 2 (3)
Do I understand correctly that if T2 observes that x == 2 it also means
that T2 observer v == true because of happens-before *(1) -hb-> (2) -hb->
(3)*?
środa, 14 września 2022 o 14:04:16 UTC+2 r r napisał(a):
> Thanks
>
> śr., 14 wrz 2022, 13:26 użytkownik Peter Veentjer
> napisał:
>
>>
>>
>> On Wed, Sep 14, 2022 at 1:51 PM r r wrote:
>>
>>> Hello,
>>> let's look for the following piece of code:
>>>
>>> int x;
>>> volatile boolean v; // v = false by default
>>> T1:
>>> x = 1; (1)
>>> v = true;(2)
>>> doSth(3)
>>>
>>> T2:
>>>doSth2(4)
>>>if (v) {} (5)
>>>
>>>
>>> When T2 observes that v == false in (5), does it mean that there is a
>>> happens-before relation (4) -> (5) -> (2) -> (3)?
>>>
>>
>> No.
>>
>> There can't be a happens-before edge between a read of v (5) and a write
>> of v (4).
>>
>> The volatile write/read will be ordered in the synchronization order, but
>> not in the synchronized-with order and therefore not ordered by
>> happens-before (since the happens-before order is the transitive closure
>> of the union of the synchronizes-with order and the program order).
>>
>> Only when a volatile read sees a particular volatile write, then there is
>> a happens-before edge from the write to the read, but never in the opposite
>> direction.
>>
>>
>>>
>>> What if v would be AtomicBolean?
>>>
>>
>> Doesn't change anything since an AtomicBoolean get/set has the same
>> semantics as a volatile read/write.
>>
>>
>>
>>> --
>>> 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-symp...@googlegroups.com.
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msgid/mechanical-sympathy/faf3e288-f249-4d07-830b-7752bb41a472n%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/mechanical-sympathy/faf3e288-f249-4d07-830b-7752bb41a472n%40googlegroups.com?utm_medium=email_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 mechanical-symp...@googlegroups.com.
>>
> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCqwmySqhNkHRKZcouwKf0F3oM%3DHb_byqLwY8D3Hyb-Gg%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCqwmySqhNkHRKZcouwKf0F3oM%3DHb_byqLwY8D3Hyb-Gg%40mail.gmail.com?utm_medium=email_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 mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/6d9273f2-986d-4e58-bfe1-f6a5a8e4fc71n%40googlegroups.com.
Re: volatile reads does happen before volatile write in JMM?
Thanks
śr., 14 wrz 2022, 13:26 użytkownik Peter Veentjer
napisał:
>
>
> On Wed, Sep 14, 2022 at 1:51 PM r r wrote:
>
>> Hello,
>> let's look for the following piece of code:
>>
>> int x;
>> volatile boolean v; // v = false by default
>> T1:
>> x = 1; (1)
>> v = true;(2)
>> doSth(3)
>>
>> T2:
>>doSth2(4)
>>if (v) {} (5)
>>
>>
>> When T2 observes that v == false in (5), does it mean that there is a
>> happens-before relation (4) -> (5) -> (2) -> (3)?
>>
>
> No.
>
> There can't be a happens-before edge between a read of v (5) and a write
> of v (4).
>
> The volatile write/read will be ordered in the synchronization order, but
> not in the synchronized-with order and therefore not ordered by
> happens-before (since the happens-before order is the transitive closure
> of the union of the synchronizes-with order and the program order).
>
> Only when a volatile read sees a particular volatile write, then there is
> a happens-before edge from the write to the read, but never in the opposite
> direction.
>
>
>>
>> What if v would be AtomicBolean?
>>
>
> Doesn't change anything since an AtomicBoolean get/set has the same
> semantics as a volatile read/write.
>
>
>
>> --
>> 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.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/faf3e288-f249-4d07-830b-7752bb41a472n%40googlegroups.com
>> <https://groups.google.com/d/msgid/mechanical-sympathy/faf3e288-f249-4d07-830b-7752bb41a472n%40googlegroups.com?utm_medium=email_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 mechanical-sympathy+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCqwmySqhNkHRKZcouwKf0F3oM%3DHb_byqLwY8D3Hyb-Gg%40mail.gmail.com
> <https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdCqwmySqhNkHRKZcouwKf0F3oM%3DHb_byqLwY8D3Hyb-Gg%40mail.gmail.com?utm_medium=email_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 mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/CAFKLJky5%2BaiTCYLgzv38fzyJ8%3DZ1FcOm56UCxdM1mcUJ-4naHA%40mail.gmail.com.
volatile reads does happen before volatile write in JMM?
Hello,
let's look for the following piece of code:
int x;
volatile boolean v; // v = false by default
T1:
x = 1; (1)
v = true;(2)
doSth(3)
T2:
doSth2(4)
if (v) {} (5)
When T2 observes that v == false in (5), does it mean that there is a
happens-before relation (4) -> (5) -> (2) -> (3)?
What if v would be AtomicBolean?
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/faf3e288-f249-4d07-830b-7752bb41a472n%40googlegroups.com.
Re: Java Memory Model, ConcurrencyHashMap and guarantee of iterator
@Vijayant Dhankhar, thanks.
How do you know it, I mean:
* that there is a happens-before between writes ()
* c.values is ensured to see two writes?
poniedziałek, 12 września 2022 o 21:26:01 UTC+2 Vijayant Dhankhar
napisał(a):
> For your original formulation for the problem..
>
> > 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?
>
> Yes, one of the thread will print true, true as there is a happens-before
> between the two writes to concurrent hash map (even if they are possibly on
> the keys that map to different bins)
>
> On Monday, September 12, 2022 at 2:46:38 PM UTC-4 gros...@gmail.com wrote:
>
>> > I think the issue here is more the ConcurrentHashMap that doesn't
>> promise you'll get both entries when calling c.values() in either one of
>> the threads.
>>
>> What do you mean?
>>
>> poniedziałek, 12 września 2022 o 17:44:31 UTC+2 aviz...@gmail.com
>> napisał(a):
>>
>>> I think the issue here is more the ConcurrentHashMap that doesn't
>>> promise you'll get both entries when calling c.values() in either one of
>>> the threads.
>>>
>>> On Monday, September 12, 2022 at 7:50:56 AM UTC-7 gros...@gmail.com
>>> wrote:
>>>
>>>> Thanks, for your response. I know that output "true" is possible. My
>>>> question is: Is it guaranteed by JMM that one of T1, T2 will print "true,
>>>> true"?
>>>>
>>>> pon., 12 wrz 2022, 15:11 użytkownik Peter Veentjer
>>>> napisał:
>>>>
>>>>> 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
>>>>> 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
>>>>>> 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 wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>> let's look for the following piece of code:
>>>>>>>>
>>>>>>>> c = new ConcurrentHashMap();
>>>>>>>> T1:
>>>>>>>> c.put(1, true);
>>>>>>>> for (Boolean b : c.values()) {
>>>>>>>> print(b);
>>>>>>>> }
>>>>>>>> T2:
>>>>>>>> c.put(2, true);
>>>>>>>> f
Re: Java Memory Model, ConcurrencyHashMap and guarantee of iterator
> I think the issue here is more the ConcurrentHashMap that doesn't promise
you'll get both entries when calling c.values() in either one of the
threads.
What do you mean?
poniedziałek, 12 września 2022 o 17:44:31 UTC+2 aviz...@gmail.com
napisał(a):
> I think the issue here is more the ConcurrentHashMap that doesn't promise
> you'll get both entries when calling c.values() in either one of the
> threads.
>
> On Monday, September 12, 2022 at 7:50:56 AM UTC-7 gros...@gmail.com wrote:
>
>> Thanks, for your response. I know that output "true" is possible. My
>> question is: Is it guaranteed by JMM that one of T1, T2 will print "true,
>> true"?
>>
>> pon., 12 wrz 2022, 15:11 użytkownik Peter Veentjer
>> napisał:
>>
>>> 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
>>> 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
>>>> 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 wrote:
>>>>>
>>>>>> Hello,
>>>>>> let's look for the following piece of code:
>>>>>>
>>>>>> c = new ConcurrentHashMap();
>>>>>> 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 mechanical-symp...@googlegroups.com.
>>>>>> 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_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "mechanical-sympathy" group.
>>>&g
Re: Java Memory Model, ConcurrencyHashMap and guarantee of iterator
Thanks, for your response. I know that output "true" is possible. My
question is: Is it guaranteed by JMM that one of T1, T2 will print "true,
true"?
pon., 12 wrz 2022, 15:11 użytkownik Peter Veentjer
napisał:
> 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
> 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
>> 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 wrote:
>>>
>>>> Hello,
>>>> let's look for the following piece of code:
>>>>
>>>> c = new ConcurrentHashMap();
>>>> 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 mechanical-sympathy+unsubscr...@googlegroups.com.
>>>> 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_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 mechanical-sympathy+unsubscr...@googlegroups.com.
>>> 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_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 mechanical-sympathy+unsubscr...@googlegroups.com.
>> 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_source=footer>
>> .
>>
> --
> You received this message because you are subscr
Java Memory Model, ConcurrencyHashMap and guarantee of iterator
Hello,
let's look for the following piece of code:
c = new ConcurrentHashMap();
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 mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/0945e8e3-1070-4166-b269-1c4e6c49da3en%40googlegroups.com.
Re: Resource to learn JIT compiler
Thanks, watched it :). It is a great video that makes an overview of JVM / JIT optimizations. Do you know any material that are more in-depth, especially for inlining / devirtualization / escape analysis? piątek, 29 kwietnia 2022 o 16:56:40 UTC+2 Gil Tene napisał(a): > There are some some recorded talks of mine under the title “Java at Speed” > that cover some JIT things common across. For example: > https://youtu.be/ot3PESmNXhE > > HTH, > > — Gil. > On Thursday, April 28, 2022 at 10:30:13 PM UTC-10 gros...@gmail.com wrote: > >> Hello, >> do you know good resources to learn a bit about JIT compiler in Java? >> (Beyond reading JDK sources ;) ) >> > -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/c728d371-907e-4452-b8f6-21e8fce21d78n%40googlegroups.com.
Resource to learn JIT compiler
Hello, do you know good resources to learn a bit about JIT compiler in Java? (Beyond reading JDK sources ;) ) -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/d713dd52-bc92-41d3-b5a3-49d8d6418c9cn%40googlegroups.com.
Re: Megamorphic virtual call optimization in Java
Thanks for your responses :)
sobota, 5 lutego 2022 o 18:38:11 UTC+1 Gil Tene napisał(a):
> You might want to give it a spin on Prime (Zing) 11 and see what you get,
> the Falcon JIT in Prime will do polymorphic guarded in-line caching for up
> to 6 implementers by default, I believe (as is configurable to higher if
> needed). This is exactly the sort of thing that capability is meant for.
>
> On Saturday, February 5, 2022 at 1:35:31 AM UTC-10 gros...@gmail.com
> wrote:
>
>> JVM 11+ (OpenJDK / Zulu)
>>
>> sobota, 5 lutego 2022 o 12:30:38 UTC+1 gregor...@gmail.com napisał(a):
>>
>>> which jvm?
>>>
>>> On Sat, Feb 5, 2022 at 6:26 AM r r wrote:
>>>
>>>> Hello,
>>>> we know that there are some techniques that make virtual calls not so
>>>> expensive in JVM like Inline Cache or Polymorphic Inline Cache.
>>>>
>>>> Let's consider the following situation:
>>>>
>>>> Base is an interface.
>>>>
>>>> public void f(Base[] b) {
>>>> for(int i = 0; i < b.length; i++) {
>>>> b[i].m();
>>>> }
>>>> }
>>>>
>>>> I see from my profiler that calling virtual (interface) method m is
>>>> relatively expensive.
>>>> f is on the hot path and it was compiled to machine code (C2) but I
>>>> see that call to m is a real virtual call. It means that it was not
>>>> optimised by JVM.
>>>>
>>>> The question is, how to deal with a such situation? Obviously, I cannot
>>>> make the method m not virtual here because it requires a serious
>>>> redesign.
>>>>
>>>> Can I do anything or I have to accept it? I was thinking how to "force"
>>>> or "convince" a JVM to
>>>>
>>>> 1. use polymorphic inline cache here - the number of different types in
>>>> b is quite low - between 4-5 types.
>>>> 2. to unroll this loop - length of b is also relatively small. After
>>>> an unroll it is possible that Inline Cache will be helpful here.
>>>>
>>>> Thanks in advance for any advices.
>>>> Regards,
>>>>
>>>> --
>>>> 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-symp...@googlegroups.com.
>>>> To view this discussion on the web, visit
>>>> https://groups.google.com/d/msgid/mechanical-sympathy/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/mechanical-sympathy/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>> Studying for the Turing test
>>>
>>
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/fc7141da-8b5a-4afc-8439-bd1a1fe0ca75n%40googlegroups.com.
Resizable array, the fastest known approach
Hello, 1. What is the fastest implementation of resizable array in Java? I know only one, that copies whole array to larger, new allocated array (offheap or noheap, do not care now). 2. I have one idea to implement (at least on Linux) no-copy, resizable array by using mremap syscall. Then, only internal page table structures are copied - no copying of content array. It seems to be really no-copy resizable array. However, I do not find a such implementation anywhere. It mean, that I am wrong. Why? -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/4b3f60ba-fc63-4998-bf6a-e8fd3fff5288n%40googlegroups.com.
Re: Megamorphic virtual call optimization in Java
JVM 11+ (OpenJDK / Zulu)
sobota, 5 lutego 2022 o 12:30:38 UTC+1 gregor...@gmail.com napisał(a):
> which jvm?
>
> On Sat, Feb 5, 2022 at 6:26 AM r r wrote:
>
>> Hello,
>> we know that there are some techniques that make virtual calls not so
>> expensive in JVM like Inline Cache or Polymorphic Inline Cache.
>>
>> Let's consider the following situation:
>>
>> Base is an interface.
>>
>> public void f(Base[] b) {
>> for(int i = 0; i < b.length; i++) {
>> b[i].m();
>> }
>> }
>>
>> I see from my profiler that calling virtual (interface) method m is
>> relatively expensive.
>> f is on the hot path and it was compiled to machine code (C2) but I see
>> that call to m is a real virtual call. It means that it was not
>> optimised by JVM.
>>
>> The question is, how to deal with a such situation? Obviously, I cannot
>> make the method m not virtual here because it requires a serious
>> redesign.
>>
>> Can I do anything or I have to accept it? I was thinking how to "force"
>> or "convince" a JVM to
>>
>> 1. use polymorphic inline cache here - the number of different types in b
>> is quite low - between 4-5 types.
>> 2. to unroll this loop - length of b is also relatively small. After an
>> unroll it is possible that Inline Cache will be helpful here.
>>
>> Thanks in advance for any advices.
>> Regards,
>>
>> --
>> 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-symp...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/mechanical-sympathy/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Studying for the Turing test
>
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/670d90ee-4b2d-4688-8987-f22646811d1dn%40googlegroups.com.
Megamorphic virtual call optimization in Java
Hello,
we know that there are some techniques that make virtual calls not so
expensive in JVM like Inline Cache or Polymorphic Inline Cache.
Let's consider the following situation:
Base is an interface.
public void f(Base[] b) {
for(int i = 0; i < b.length; i++) {
b[i].m();
}
}
I see from my profiler that calling virtual (interface) method m is
relatively expensive.
f is on the hot path and it was compiled to machine code (C2) but I see
that call to m is a real virtual call. It means that it was not optimised
by JVM.
The question is, how to deal with a such situation? Obviously, I cannot
make the method m not virtual here because it requires a serious redesign.
Can I do anything or I have to accept it? I was thinking how to "force" or
"convince" a JVM to
1. use polymorphic inline cache here - the number of different types in b
is quite low - between 4-5 types.
2. to unroll this loop - length of b is also relatively small. After an
unroll it is possible that Inline Cache will be helpful here.
Thanks in advance for any advices.
Regards,
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/9b52b34e-6388-4cba-b89e-ce7521109cban%40googlegroups.com.
Re: Thread safety of the shared piece of memory - Java Memory Model
Thanks
czwartek, 29 lipca 2021 o 20:30:46 UTC+2 alarm...@gmail.com napisał(a):
> There is a happens before edge between calling the start method of a
> thread and the thread running.
>
> On JMM level that is sufficient.
>
> On Thu, Jul 29, 2021, 18:47 r r wrote:
>
>> Hello,
>>
>> We have the simple pseudocode:
>>
>> void main(String[] args) {
>> MemoryBuffer b = new MemoryBuffer(); // it is a off-heap native piece
>> of memory allocated by malloc via JNI
>> b.init(); // it just write some data to the memory buffer by JNI
>> startThreadsThatReadsFromBuffer(b); // this functions starts threads
>> that read the b
>> // There is no locks / synchronization etc.
>> }
>>
>> It seems to be thread-safe in the sense of Java Memory Model. But, I
>> cannot convince myself why it is correct. Especially, how can I be sure
>> that worker threads see completely intizalized buffer b?
>>
>> --
>> 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-symp...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/mechanical-sympathy/84ab88bc-e0bf-4e19-8c39-eeea619bf0f0n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/mechanical-sympathy/84ab88bc-e0bf-4e19-8c39-eeea619bf0f0n%40googlegroups.com?utm_medium=email_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 mechanical-sympathy+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/28b5554f-c621-4b15-ae78-76f830684ddcn%40googlegroups.com.
Thread safety of the shared piece of memory - Java Memory Model
Hello,
We have the simple pseudocode:
void main(String[] args) {
MemoryBuffer b = new MemoryBuffer(); // it is a off-heap native piece
of memory allocated by malloc via JNI
b.init(); // it just write some data to the memory buffer by JNI
startThreadsThatReadsFromBuffer(b); // this functions starts threads
that read the b
// There is no locks / synchronization etc.
}
It seems to be thread-safe in the sense of Java Memory Model. But, I cannot
convince myself why it is correct. Especially, how can I be sure that
worker threads see completely intizalized buffer b?
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/mechanical-sympathy/84ab88bc-e0bf-4e19-8c39-eeea619bf0f0n%40googlegroups.com.
