Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #269 > unrolled thread
| Started by | Masakuni Oishi <yamasa@bsdhouse.org> |
|---|---|
| First post | 2011-06-13 09:40 -0700 |
| Last post | 2011-06-15 02:06 -0700 |
| Articles | 4 on this page of 84 — 6 participants |
Back to article view | Back to comp.programming.threads
questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-13 09:40 -0700
Re: questions about memory_order_seq_cst fence Edek <edek.pienkowski@gmail.com> - 2011-06-13 22:39 +0200
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-14 08:27 -0700
Re: questions about memory_order_seq_cst fence Edek <edek.pienkowski@gmail.com> - 2011-06-16 00:21 +0200
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-15 15:48 -0700
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-16 05:03 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 08:35 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-16 12:05 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 11:19 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-16 13:57 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 13:51 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-16 16:53 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 16:17 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-16 17:37 +0200
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 08:47 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 16:54 +0100
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 09:01 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 17:07 +0100
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 13:59 -0700
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-16 14:32 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-17 08:03 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-17 16:19 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-17 15:40 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-30 14:26 +0200
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-17 15:24 -0700
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-18 03:49 -0700
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-18 14:40 -0700
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-18 15:46 -0700
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-18 20:27 -0700
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-18 21:31 -0700
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-18 21:37 -0700
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-20 15:45 -0700
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-20 20:05 -0700
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-18 14:06 +0200
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-16 18:32 +0200
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 15:42 -0700
Re: questions about memory_order_seq_cst fence Edek <edek.pienkowski@gmail.com> - 2011-07-10 19:47 +0200
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 08:51 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 17:23 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-16 18:49 +0200
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-16 08:51 -0700
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-16 17:25 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 16:56 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-18 14:28 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-20 09:54 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-20 15:39 +0200
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-22 13:24 +0200
Re: questions about memory_order_seq_cst fence Edek <edek.pienkowski@gmail.com> - 2011-06-16 14:39 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 13:55 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-16 12:03 +0200
Re: questions about memory_order_seq_cst fence Edek <edek.pienkowski@gmail.com> - 2011-07-10 19:10 +0200
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-13 16:00 -0700
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-13 23:31 -0700
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-14 08:32 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-14 23:05 +0100
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-14 16:44 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-15 08:34 +0100
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-15 02:11 -0700
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-15 15:58 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 08:26 +0100
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-16 05:05 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-16 13:11 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-18 15:42 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-20 09:27 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-20 15:30 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-20 15:00 +0100
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-21 14:54 +0200
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-21 18:37 +0200
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-21 15:59 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-22 09:01 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-20 15:41 +0100
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-20 23:24 -0700
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-22 10:46 -0700
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-22 11:19 -0700
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-22 11:57 -0700
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-27 14:05 +0200
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-29 16:14 -0700
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-06-24 01:42 -0700
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-06-27 13:24 +0200
Re: questions about memory_order_seq_cst fence Anthony Williams <anthony.ajw@gmail.com> - 2011-07-01 02:25 -0700
Re: questions about memory_order_seq_cst fence Alexander Terekhov <terekhov@web.de> - 2011-07-01 12:48 +0200
Re: questions about memory_order_seq_cst fence Masakuni Oishi <yamasa@bsdhouse.org> - 2011-06-15 01:53 -0700
Re: questions about memory_order_seq_cst fence Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-15 02:57 -0700
Re: questions about memory_order_seq_cst fence "Chris M. Thomasson" <cristom@charter.net> - 2011-06-15 02:06 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Alexander Terekhov <terekhov@web.de> |
|---|---|
| Date | 2011-07-01 12:48 +0200 |
| Message-ID | <4E0DA5ED.35BA4570@web.de> |
| In reply to | #373 |
Anthony Williams wrote: [...] > Right, so it appears that on Itanium we cannot use plain LD and ST for > memory_order_relaxed operations --- at least one of them must be > stronger. For now, I'm not sure whether we can get away with making > only one stronger, or whether we need to go for making both loads and > stores stronger. It turns out that Itanium doesn't respect read-after-read dependence (two loads from the same location without a store to the same location in-between in program order) for plain ld. As long as C++11 requires such coherence (makes sense, PowerPC does respect RAR dependence), ld.acq must be used instead of plain ld. Plain st can not be used for memory_order_relaxed stores as well because in some cases C++11 requires remote write atomicity for memory_order_relaxed stores (Joshua Maurice posted here examples) and hence st.rel (it provides remote write atomicity) must be used instead of plain st. On PowerPC, the situation is better (plain LD and ST can be used for memory_order_relaxed loads/stores) because PowerPC respects RAR and provides cumulativity for lwsync/hwsync fences, see: http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/pldi105-sarkar.pdf Note that under 'modes' model, remote write atomicity is a separate mode and hence plain st can be used for 'very relaxed' (the default) stores even on Itanium (I think that Itanium's incoherence for plain ld sucks; ld.acq must be used for 'very relaxed' (the default) loads under 'modes' model just like under C++11). regards, alexander.
[toc] | [prev] | [next] | [standalone]
| From | Masakuni Oishi <yamasa@bsdhouse.org> |
|---|---|
| Date | 2011-06-15 01:53 -0700 |
| Message-ID | <e6c4859d-8ebd-4ed7-9c29-29fef1b2501d@d26g2000prn.googlegroups.com> |
| In reply to | #278 |
On Jun 14, Joshua Maurice <joshuamaur...@gmail.com> wrote: > On Jun 14, 3:05 pm, Anthony Williams <anthony....@gmail.com> wrote: > > > Masakuni Oishi <yam...@bsdhouse.org> writes: > > > /*** code 1 ***/ > > > // Initially > > > atomic<int> x(0), y(0); > > > > // Thread 1: > > > y.store(1, memory_order_release); > > > atomic_thread_fence(memory_order_seq_cst); > > > r1 = x.load(memory_order_acquire); > > > > // Thread 2: > > > x.store(1, memory_order_release); > > > > // Thread 3: > > > r2 = x.load(memory_order_acquire); > > > atomic_thread_fence(memory_order_seq_cst); > > > r3 = y.load(memory_order_acquire); > > > /***************/ > > > > In the above code, is r1 == 0 && r2 == 1 && r3 == 0 possible? > > > I think it should be prohibited, but I couldn't make sure that > > > from the C++0x FDIS. > > > Premise 1: r3 == 0. > > > Since the only store to y is the store of 1 by thread 1, r3 == 0 implies > > that the load from y on thread 3 is reading the initial value of y. > > > 29.3p6 of N3290 says: > > > "For atomic operations A and B on an atomic object M, where A modifies M > > and B takes its value, if there are memory_order_seq_cst fences X and Y > > such that A is sequenced before X, Y is sequenced before B, and X > > precedes Y in S, then B observes either the effects of A or a later > > modification of M in its modification order." > > > If the fence in thread 1 precedes the fence in thread 3 in S, then the > > read at r3 must therefore see the value written by the store in thread > > 1. Consequently, the fence in thread 3 must precede the fence in thread > > 1 in S. > > > Premise 2: r2 == 1. > > > The load of x in thread 3 reading 1 implies it has read the value of the > > store to x from thread 2. > > I agree with your proof up to this point. Me, too. > > We already know that the fence in thread 3 precedes the fence in thread > > 1 in S. > > > 29.3p7 of N3290 says: > > > "For atomic operations A and B on an atomic object M, if there are > > memory_order_seq_cst fences X and Y such that A is sequenced before X, Y > > is sequenced before B, and X precedes Y in S, then B occurs later than A > > in the modification order of M." > > > In our case, the fence in thread 3 occurs before the fence in thread 1 > > in S. The fence in thread 3 is thus X, the fence in thread 1 Y, the read > > from x in thread 3 is A and the read from x in thread 1 is B. > > > Thus the read of x in thread 1 must occur later in the modification > > order of x than the read in thread 3. Since the read in thread 3 is of > > the last store to x (1), the read in thread 1 must also read that value, > > and r1 == 1. > > I disagree with this. I think you made the same mistake which I made > in my first post of this thread. Only /modifications/ appear in a > modification order. Reads do not appear in the modification order. At > least, this is the simple reading of 1.10 / 7, and its name is > "modification order", not "access order". Also note that the > definition of a "release sequence" in 1.10 / 8 does not make sense if > reads may appear in modification orders. Also note that the definition > of "visible sequence of side effects" in 1.10 / 14 does not make sense > if reads may appear in modification orders. (Note that there's some > ambiguity w.r.t. volatile atomic objects, as volatile reads do count > as side effects, but non-volatile reads AFAIK are not side effects.) > > As I'm beginning to understand this, there is a typo in 29.3 / 7. The > exact text is: > [] > For atomic operations A and B on an atomic object M, if there are > memory_order_seq_cst fences X and Y such that A is sequenced before X, > Y is sequenced before B, and X precedes Y in S, then B occurs later > than A in the modification order of M. > [/] > I think it's meant to read: > [] > For atomic **write (and atomic read-modify-write operations)** A and B > on an atomic object M, if there are memory_order_seq_cst fences X and > Y such that A is sequenced before X, Y is sequenced before B, and X > precedes Y in S, then B occurs later than A in the modification order > of M. > [/] > > When you said "the read from x in thread 3 is A and the read from x in > thread 1 is B.", that is where you went wrong. You cannot apply > "29.3 / 7" to atomic reads A and B on an atomic object M, only atomic > writes (and atomic read-modify-write operations). I agree. > I'm still dealing with the implication that A precedes B in the total > order S of seq_cst operations does not imply that A happens-before B > nor A inter-thread happens before B nor A synchronizes-with B - and > that's irritating and slightly surprising. At least, I haven't yet > found a rule which states that, and I've looked decently hard, and > I've even found a note saying as much in 29.3 / 8. Even though the total order S does not imply happens-before relationship, S gives constraints of visibility which is mentioned in n3290, 29.3p3-p7. But, I think it is not enough. In particular, the following constraint should be added to n3290, 29.3: /*****/ // Thread 1: r1 = x.load(memory_order_relaxed); atomic_thread_fence(memory_order_seq_cst); // Thread 2: atomic_thread_fence(memory_order_seq_cst); r2 = x.load(memory_order_relaxed); /*****/ in this code, if the fence in thread 1 precedes the fence in thread 2 in S, and the value of r1 comes from a modification A on x, then the load operation in thread 2 should not take the value of the modification which precedes A in the modification order of x. If there was a constraint like this, then we could prove that r1 == 0 && r2 == 1 && r3 == 0 is not allowed in the first code. -- masakuni
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-06-15 02:57 -0700 |
| Message-ID | <fd22add7-428c-4de3-ad75-23fa912a2e9e@d19g2000prh.googlegroups.com> |
| In reply to | #280 |
On Jun 15, 1:53 am, Masakuni Oishi <yam...@bsdhouse.org> wrote: > On Jun 14, Joshua Maurice <joshuamaur...@gmail.com> wrote: > > > I'm still dealing with the implication that A precedes B in the total > > order S of seq_cst operations does not imply that A happens-before B > > nor A inter-thread happens before B nor A synchronizes-with B - and > > that's irritating and slightly surprising. At least, I haven't yet > > found a rule which states that, and I've looked decently hard, and > > I've even found a note saying as much in 29.3 / 8. > > Even though the total order S does not imply happens-before > relationship, S gives constraints of visibility which is > mentioned in n3290, 29.3p3-p7. Indeed. I've been reviewing this today, after your good correction. Thank you again. > But, I think it is not enough. > In particular, the following constraint should be added > to n3290, 29.3: > /*****/ > // Thread 1: > r1 = x.load(memory_order_relaxed); > atomic_thread_fence(memory_order_seq_cst); > > // Thread 2: > atomic_thread_fence(memory_order_seq_cst); > r2 = x.load(memory_order_relaxed); > /*****/ > in this code, if the fence in thread 1 precedes the fence > in thread 2 in S, and the value of r1 comes from a > modification A on x, then the load operation in thread 2 > should not take the value of the modification which precedes A > in the modification order of x. > > If there was a constraint like this, then we could prove that > r1 == 0 && r2 == 1 && r3 == 0 is not allowed in the first code. I think so as well. I'm just wondering if this is an oversight, or a purposeful decision because requiring this would negatively impact real hardware. I don't even begin to claim to know enough to comment on that.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <cristom@charter.net> |
|---|---|
| Date | 2011-06-15 02:06 -0700 |
| Message-ID | <TB_Jp.6482$lW4.3545@newsfe07.iad> |
| In reply to | #277 |
"Anthony Williams" <anthony.ajw@gmail.com> wrote in message news:87tybsm5kq.fsf@justsoftwaresolutions.co.uk... [...] > Masakuni Oishi <yamasa@bsdhouse.org> writes: [...] FWIW, I think I have an "example" of why `memory_order_seq_cst' can be important...: http://groups.google.com/group/comp.programming.threads/browse_frm/thread/6cf4655c4e0b7c95 http://groups.google.com/group/comp.programming.threads/msg/50ced5527a964ca4 Any thoughts?
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.programming.threads
csiph-web