Re: is HB consistent with SO for not otherwise related synchronization actions?
Valentin Kovalenko via Concurrency-interest <[email protected]> Wed, 3 Feb 2021 22:35:48 -0700
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <CAO-wXwKaL834rEcgt22i-xR+9e5k68ZHVBbEuhQfr-6BJG8inA@mail.gmail.com> |
Hi Peter, > The question is if wx,wy are synchronization actions. > Your example is open for multiple interpretations. Yes, wx and wy are synchronization actions. I did not specify what they are exactly on purpose, to make the statement as general as possible. Thank you, Valentin www.kovalenko.link On Wed, Feb 3, 2021 at 12:39 AM Peter Veentjer <[email protected]> wrote: > > > On Wed, Feb 3, 2021 at 3:40 AM Valentin Kovalenko via Concurrency-interest > <[email protected]> wrote: > >> I believe, I found how to formally prove this. >> >> Same thread. >> If hb(wx, wy) and the actions wx, wy are performed by the same thread, >> then we have so(wx, wy) trivially due to both so and hb being consistent >> with the program order (po). >> > > Correct. > > If wx,wy are synchronization actions, then they are part of both so and po. > >> >> >> Different threads. >> A more interesting situation is when wx and wy are performed by different >> threads, let us label them X and Y respectively. The only way to have a >> happens-before relation between actions performed by different threads X >> and Y is to have a synchronizes-with relation between a pair of >> synchronization actions in these threads. >> > > Correct > >> >> In other words, given hb(wx, wy), the execution must have actions >> releaseX performed by X and acquireY performed by Y, such that >> synchronizes-with(releaseX, acquireY) and po(wx, releaseX), po(acquireY, >> wy). >> > > Your example is open for multiple interpretations. So I'll make it > concrete and hope it reflects what you have in mind. > > int a; > volatile int b; > > thread1(){ > a=1; > b=1; > } > > thread(){ > int rb=b; > int ra=a; > if(rb==1 && ra==0) println("violation"); > } > > And let's assume we see rb==1; what can we tell about a. > > So we have the following: > po(a=1,b=1) > so(b=1,rb=b) > po(rb=b, ra=a) > > So we have a hb(a=1,ra=a)=po(a=1,b=1), so(b=1,rb=b),po(rb=b, ra=a) > > So we are good because the read of a should see the write of a and hence > "violation" can't be printed. > > >> Now we can see that hb(wx, wy) necessary leads to so(wx, releaseX), >> sw(releaseX, acquireY), so(acquireY, wy); and sw(releaseX, acquireY) >> necessary means so(releaseX, acquireY). >> > > I'm not sure what wx,wy for actions are. If they are regular loads/stores > then they are not part of the so because they are not synchronization > actions. > > > >> Therefore, hb(wx, wy) necessary leads to so(wx, releaseX), so(releaseX, >> acquireY), so(acquireY, wy), which gives so(wx, wy). >> > > The question is if wx,wy are synchronization actions. If they are not, > then they are not part of so. So in my example the so doesn't order > (a=1,b=1) and it doesn't order (rb=b, ra=a) > > If a and b would both be volatile and hence become synchronization > actions, then the so would contain > > (a=1,b=1),(b=1,rb=b),(rb=b,ra=a) > > >> >> I would highly appreciate it if someone could confirm this reasoning. >> > > The definition of the so is that it is a total order over all > synchronization actions that is consistent with the po of each of the > threads. > > So in case of the universes; it would filter out any universes that > - doesn't have a total order over all synchronization actions > - the total order of the synchronization actions isn't consistent with the > po of each of the threads. > > Based on the so you can determine the sw order since it is a sub order of > so. > > And based on the po and the sw, you can determine the hb order, i.e. the > transitive closure of the union of the po and the sw. > > >> >> Regards, >> Valentin www.kovalenko.link >> >> >> On Tue, Feb 2, 2021 at 5:53 PM Valentin Kovalenko < >> [email protected]> wrote: >> >>> Hi all, >>> >>> Imagine that we have only partial information about an execution (as is >>> almost always true in practice): >>> there are synchronization actions wx and wy such that happens-before(wx, >>> wy). These actions are not otherwise explicitly related, we may think of >>> them as being volatile writes to two different variables x and y. >>> >>> According to JMM, they are also ordered with the total synchronization >>> order. The order so(wx, wy) is a possibility that clearly does not violate >>> any JMM constraints. Interestingly, so(wy, wx) also does not seem to >>> violate anything, and, thus, should also be allowed. >>> >>> However, if I try to imagine a program that produces executions with >>> hb(wx, wy) and so(wy, wx) - I fail miserably. Whatever I imagine is needed >>> to have hb(wx, wy) in an execution, causes this execution to have so(wx, >>> wy). >>> >>> So maybe happens-before order is always consistent with the >>> synchronization order (if this is not the case, could someone come up with >>> a counterexample)? If this is the case, is there a way to formally deduce >>> it from JMM without resorting to the argument "I can't imagine a program >>> that produces executions with hb not being consistent with so"? >>> >>> Thank you, >>> Valentin www.kovalenko.link >>> >> _______________________________________________ >> Concurrency-interest mailing list >> [email protected] >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> > _______________________________________________ Concurrency-interest mailing list [email protected] http://cs.oswego.edu/mailman/listinfo/concurrency-interest