220 30936 <0c01122b-f725-4a97-ae28-e7ea6a4eb590@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: "'Walt Karas' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposed alternative approach to specifying required memory operation ordering Date: Wed, 15 Feb 2017 18:51:06 -0800 (PST) Lines: 252 Approved: news@gmane.org Message-ID: <0c01122b-f725-4a97-ae28-e7ea6a4eb590@isocpp.org> References: <20170216004134.4902991.82070.24891@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1155_1146937566.1487213466308" X-Trace: blaine.gmane.org 1487213469 26566 195.159.176.226 (16 Feb 2017 02:51:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2017 02:51:09 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDFLZXWOVYIBBGVHSTCQKGQETDPA4BY@isocpp.org Thu Feb 16 03:51:02 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceC9t-0006Xq-PG for gclcip-std-proposals@m.gmane.org; Thu, 16 Feb 2017 03:51:02 +0100 Original-Received: by mail-yw0-f200.google.com with SMTP id u68sf6475797ywg.4 for ; Wed, 15 Feb 2017 18:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=vDdC9kf6B4eYZOn5kylFSX4sIMyHMJ9CY1vd5XdjmYg=; b=wNHexI0zAtJCPWRXu7J+yuk1gg3mcpHwiLp3THIgiIlrLWk4WjNMJpmE8rx+3/uljV 5axthoHHKpfJeuEyprz5oEfkIKLtNFpYb5Q6fc4S0hpFjm4u2YDxyhR1FhMmWD8JunSZ dfzLwtOYEjDgwYWfGGH6RmTLvhixxzvk5xPcj9SqHglhF3V6HSaAY8QgUH0sx5B8LGzS 4xg5k/0nslQWWmEVlSOFE15bDX+Q3dn5sxQQhR35zjPDj/3usJipxDJ74HNaVoKDN/pI Deed6eMP/Du4A/Bny4ZPUuw3Ln2jrTuZuJ4opnTUDUfRYxEa72a9MCdkvXOBDK30kLZM 9VVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=vDdC9kf6B4eYZOn5kylFSX4sIMyHMJ9CY1vd5XdjmYg=; b=KNnaerbcDuD/lV9ctzzKo9gO+0iKzMIEuMy0In78anwptv/GKdjJuAoAyWFNuOzQk7 iuN6X3uLBZUfFcgY1ujU5rPBLxJ8TgprQXP3MEu/QztAuj1TYTpgNGq8w3aMmz8F+Mpy duTM1qZPMc3apRasYVDOgCwI7+WDt5k9mRIUPKj/zSlgJChLrHspCmg0hlI0NgOkYRB/ E6eYU37IQNP9eH0sJvklNOZlNw6zoj7xR/EofEGzoxPA6vG0LWsPH+XJD1CVtnQJyNfz Lr0O4YfK/01w1TmTCT1IiMEjzU/uct0R9OhzY64AZEta+pyehFWOXAhL8wEg8ctB2pRx VDZA== X-Gm-Message-State: AMke39mwOjtJgxI2sDpUXiF/bOXEZptz9NWRSgeNpv5SzfLNGeEbzIDnL5N/oYf/tAfzMg== X-Received: by 10.129.70.133 with SMTP id t127mr13686235ywa.146.1487213467388; Wed, 15 Feb 2017 18:51:07 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.16.34 with SMTP id h31ls421089ote.3.gmail; Wed, 15 Feb 2017 18:51:06 -0800 (PST) X-Received: by 10.157.6.166 with SMTP id 35mr1222720otx.3.1487213466778; Wed, 15 Feb 2017 18:51:06 -0800 (PST) In-Reply-To: <20170216004134.4902991.82070.24891@gmail.com> X-Original-Sender: wkaras@yahoo.com X-Original-From: Walt Karas Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:30936 Archived-At: ------=_Part_1155_1146937566.1487213466308 Content-Type: multipart/alternative; boundary="----=_Part_1156_535960125.1487213466308" ------=_Part_1156_535960125.1487213466308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, February 15, 2017 at 7:41:40 PM UTC-5, Tony V E wrote: > > Leaving the questions about =E2=80=8Eactually changing the standard aside= , and=20 > focusing on understanding (which may just mean this could be a=20 > std-discussion question instead of std-proposal), > > In your model, if X and Y are relaxed atomic operations in thread T1, can= =20 > thread T2 see them as Y before X while thread T3 sees them as =E2=80=8EX = before Y? > No. But f(T1, X) and f(T1, Y) may not exist, and T2 and T3 can only "see"= =20 stores in global memory. I think I see your point. My notion of a nominal global order would make= =20 good optimization too complex. =20 > > Sent from my BlackBerry portable Babbage Device > *From: *'Walt Karas' via ISO C++ Standard - Future Proposals > *Sent: *Wednesday, February 15, 2017 2:17 PM > *To: *ISO C++ Standard - Future Proposals > *Reply To: *std-pr...@isocpp.org > *Subject: *[std-proposals] Proposed alternative approach to specifying=20 > required memory operation ordering > > - In a program execution, each thread defines a nominal order of (thread= =20 > local) memory and fence operations. > - For any operations X and Y in thread T, either X before Y, or Y before = X. > - A program execution defines a nominal global order of global memory=20 > operations. > - If X and Y are atomic global operations, then either X before Y or Y=20 > before X in the global order. > - If X is a global operation, and there exists a global store S where=20 > neither X before S nor S before X in the global order, then the result of= X=20 > is undefined. > - A program execution defines a partial function f(T, LO) -> GO where LO= =20 > is a local memory operation in thread T, and GO is a global operation. I= f=20 > LO is atomic, then GO must be atomic. The result of LO is the result of= =20 > GO. If the result of GO is undefined, the result of LO is undefined. =20 > (Even if f(T, LO) is not required to exist, it none the less _may_ exist.= ) > - If LO1 and LO2 are operations in thread T, and LO1 before LO2 in T, and= =20 > f(T, LO1) and f(T, LO2) both exist, then f(T, LO2) before f(T, LO1) in th= e=20 > global order is not allowed. > - If: > 1. In a thread T, X and Y are memory operations, and F is a fence=20 > operation. > 2. X before F and F before Y. > 3. F is sequentially consistent and both X and Y are atomic, or > 4. F is acquire and both X and Y are loads, or > 5. F is release and both X and Y are stores. > then F is activated for X and Y. > - In a thread T, if X and Y are memory operations (where X before Y) with= =20 > an activated fence F, then f(T, X) must exist. > - For every global operation GO, there must exist a local operation LO in= =20 > some thread T where f(T, LO) -> GO. (Assuming no intense gamma radiation= ..) > - A sequentially consistent (thread local) atomic memory operation implie= s=20 > two sequentially consistent fences, one before and one after it (as well = as=20 > a preceding release for a store, and a succeeding acquire for a load). > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to std-proposal...@isocpp.org . > To post to this group, send email to std-pr...@isocpp.org . > To view this discussion on the web visit=20 > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d0fdabcd-f04= a-46e6-b93a-0b9ea85cb5bd%40isocpp.org=20 > > . > > --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/0c01122b-f725-4a97-ae28-e7ea6a4eb590%40isocpp.or= g. ------=_Part_1156_535960125.1487213466308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, February 15, 2017 at 7:41:40 PM UTC-= 5, Tony V E wrote:
= =
Leaving the questions about =E2=80=8E= actually changing the standard aside, and focusing on understanding (which = may just mean this could be a std-discussion question instead of std-propos= al),

In your model, if X and Y are relaxed atomic operations in thread T1, = can thread T2 see them as Y before X while thread T3 sees them as =E2=80=8E= X before Y?

No. =C2=A0But f(T1,= X) and f(T1, Y) may not exist, and T2 and T3 can only "see" stor= es in global memory.

I think I see your point. =C2= =A0My notion of a nominal global order would make good optimization too com= plex.
=C2=A0
=

= = =
Sent=C2=A0from=C2=A0my=C2=A0Bl= ackBerry=C2=A0portable=C2=A0Babbage=C2=A0Device
= = =
From: 'Walt = Karas' via ISO C++ Standard - Future Proposals
Sent: W= ednesday, February 15, 2017 2:17 PM
To: ISO C++ Standard -= Future Proposals
= Subject: [std-proposals] Proposed alternative approach to specifying= required memory operation ordering

- In a program execu= tion,=C2=A0each thread defines a nominal order of (thread local) memory and= fence operations.
- For any operations X and Y in thread T, eith= er X before Y, or Y before X.
- A program execution defines a nom= inal global order of global memory operations.
- If X and Y are a= tomic global operations, then either X before Y or Y before X in the global= order.
- If X is a global operation, and there exists a global s= tore S where neither X before S nor S before X in the global order, then th= e result of X is undefined.
- A program execution defines a parti= al function f(T, LO) -> GO where LO is a local memory operation in threa= d T, and GO is a global operation.=C2=A0 If LO is atomic, then GO must be a= tomic. The result of LO is the result of GO.=C2=A0 If the result of GO is u= ndefined, the result of LO is undefined.=C2=A0 (Even if f(T, LO) is not req= uired to exist, it none the less _may_ exist.)
- If LO1 and LO2 a= re operations in thread T, and LO1 before LO2 in T, and f(T, LO1) and f(T, = LO2) both exist, then f(T, LO2) before f(T, LO1) in the global order is not= allowed.
- If:
1.=C2=A0 In a thread T, X and Y are mem= ory operations, and F is a fence operation.
2.=C2=A0 X before=C2= =A0F and=C2=A0F before Y.
3.=C2=A0 F is sequentially consistent a= nd both X and Y are atomic, or
4.=C2=A0 F is acquire and both X a= nd Y are loads, or
5.=C2=A0 F is release and both X and Y are sto= res.
then F is activated for X and Y.
-=C2=A0In a threa= d T, if X and Y are memory operations (where X before Y) with an activated = fence F, then f(T, X) must exist.
- For every global operation GO= , there must exist a local operation LO in some thread T where f(T, LO) -&g= t; GO.=C2=A0 (Assuming no intense gamma radiation.)
- A sequentia= lly consistent (thread local) atomic memory operation implies two sequentia= lly consistent fences, one before and one after it (as well as a preceding = release for a store, and a succeeding acquire for a load).

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/d0fdabcd-f04a-46e6-b93a-= 0b9ea85cb5bd%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/0c01122b-f725-4a97-ae28-e7ea6a4eb590= %40isocpp.org.
------=_Part_1156_535960125.1487213466308-- ------=_Part_1155_1146937566.1487213466308-- .