From 7632746564442186887 X-Google-Thread: f78e5,4c3ccbaec057287f X-Google-NewGroupId: yes X-Google-Attributes: gid7894ca11fe,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 09 Mar 2011 08:10:05 -0600 Return-Path: Sender: std-cpp-request@vandevoorde.com Approved: james.dennett@gmail.com Message-ID: Newsgroups: comp.std.c++ From: Masakuni Oishi Subject: Re: proposal for memory_order_seq_cst constraints Organization: http://groups.google.com References: <87zkpcjzim.fsf@justsoftwaresolutions.co.uk> Content-Type: text/plain; charset=ISO-8859-1 X-Original-Date: Tue, 8 Mar 2011 08:16:56 -0800 (PST) X-Submission-Address: std-c++-submit@vandevoorde.com To: undisclosed-recipients:; Date: Wed, 9 Mar 2011 08:02:16 CST Lines: 125 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-HoZGLZENrBSdEAQiuVGPmKlQsVqJm5Q9kqkNP9d1fMyDm2lEcdK8tT4cZtbU1kAiDb4K70ZhIf4r9gZ!CIyXwWGMOeDrvXpLjj5ZO3Ay2aiAf2f1K3MzwOCQpm43wm4GYl2yC7MfqCPWn9wijn8BgMQpdZut!e6bkciEgkFf6XFs+FmWgTazq2fo= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5409 Xref: g2news1.google.com comp.std.c++:3180 Hello, Anthony Williams wrote: > Masakuni Oishi writes: > > /*** Case 1 ***/ > > // Initially > > atomic x(0), y(0); > > > // Thread 1: > > x.store(2, memory_order_release); // (1) > > x.store(1, memory_order_seq_cst); // (2) > > r1 = y.load(memory_order_seq_cst); // (3) > > > // Thread 2: > > y.store(1, memory_order_seq_cst); // (4) > > r2 = x.load(memory_order_seq_cst); // (5) > > > r1 == 0 && r2 == 2 is possible, > > in case of (2) -> (3) -> (4) -> (5) in S. > > This is already disallowed. > > (1) is sequenced-before (2), so the value written by (2) must be later > in the modification order of x than that written by (1). If (3) reads > zero then (3) must be before (4) in S, so (2) precedes (5), and (5) must > read the value written by (2) or a later value in the modification order > of x. Hmm... N3242 29.3.3 doesn't restrict to "(2) or a later". It only says that: either the last preceding modification according to this order S, or the result of an operation that is not memory_order_seq_cst. > > /*** Case 2 ***/ > > // Initially > > atomic x(0), y(0); > > > // Thread 1: > > r1 = x.load(memory_order_seq_cst); // (1) > > r2 = y.load(memory_order_seq_cst); // (2) > > > // Thread 2: > > y.store(1, memory_order_seq_cst); // (3) > > x.store(1, memory_order_seq_cst); // (4) > > r3 = x.load(memory_order_seq_cst); // (5) > > > // Thread 3: > > x.store(2, memory_order_release); // (6) > > > r1 == 2 && r2 == 0 && r3 == 2 is possible, > > in case of (1) -> (2) -> (3) -> (4) -> (5) in S, > > and (4) -> (6) in modification order of x. > > This is already disallowed. > > if (5) reads 2, then (6) must follow (4) in the modification order of > x. If (1) reads 2, then (1) must follow (4) in S, otherwise the reads > are inconsistent with the modification order of x. Why is it "inconsistent"? Certainly, if (1) reads 2, then (6) happens before (1). But, in N3242, "(4) precedes (6) in the modification order" and "(6) happens before (1)" don't mean "(4) should precede (1) in S", AFAIK. > If (1) follows (4), > then S must have (3)->(4)->(1)->(2) => (2) must read 1. > > If S is (1) -> (2) -> (3) -> (4) -> (5) then (1) precedes (4), so (1) > can read 0 (the initial value) or 2 (from (6)), and (2) must read 0 (the > initial value of y). > > If (1) reads 2 then the write at (6) must precede the write at (4) in > the modification order of x, since (1) is before (4) in S. Same as above. Do "(6) happens before (1)" and "(1) precedes (4) in S" mean "(6) should precede (4) in the modification order"? > > /*** Case 3 ***/ > > // Initially > > atomic x(0), y(0); > > > // Thread 1: > > x.store(1, memory_order_seq_cst); // (1) > > x.store(2, memory_order_release); // (2) > > > // Thread 2: > > r1 = x.load(memory_order_seq_cst); // (3) > > r2 = y.load(memory_order_seq_cst); // (4) > > > // Thread 3: > > y.store(1, memory_order_seq_cst); // (5) > > r3 = x.load(memory_order_seq_cst); // (6) > > > r1 == 2 && r2 == 0 && r3 == 1 is possible, > > in case of (1) -> (3) -> (4) -> (5) -> (6) in S. > > This is already disallowed. > > If S has (1) -> (3) -> (4) -> (5) -> (6), then (6) must read 2, since > (2) follows (1) in the modification order of x, and (3) precedes (6) in > S. Why? > Even though non-memory_order_seq_cst operations are not included in S, > they must still respect the modification-order and happens-before > constraints. Yes, I agree. My proposal aims to clarify what is "S is consistent with the happens-before order and the modification orders". -- Masakuni -- [ comp.std.c++ is moderated. To submit articles, try posting with your ] [ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]