220 30974 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposed alternative approach to specifying required memory operation ordering Date: Fri, 17 Feb 2017 14:14:55 -0800 (PST) Lines: 276 Approved: news@gmane.org Message-ID: References: <20170216004134.4902991.82070.24891@gmail.com> <8575c41d-1c8e-4e6f-9f12-a07bb70a7703@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_434_218215407.1487369695462" X-Trace: blaine.gmane.org 1487369698 27371 195.159.176.226 (17 Feb 2017 22:14:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Feb 2017 22:14:58 +0000 (UTC) Cc: inkwizytoryankes@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBYHLTXCQKGQEZYWZILI@isocpp.org Fri Feb 17 23:14:54 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f199.google.com ([209.85.223.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceqnj-0006Iu-64 for gclcip-std-proposals@m.gmane.org; Fri, 17 Feb 2017 23:14:51 +0100 Original-Received: by mail-io0-f199.google.com with SMTP id q20sf6099157ioi.0 for ; Fri, 17 Feb 2017 14:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=xHkdB3c973X60zmJfnAzOt8eoxgaY8SyHNr8d/iQZ9o=; b=M425stiYyFXQq8ey4N4cW03zayHVFeAPCl3M6cEGcJiOLds6fNLIms3RsaJmzEsrzo 3Su4dM4iDLYILo+UsovzjFGKciZxfjbASwUEL2PdoNECPwxqmNwBKnkVoQJz4T+sy37P 2kKj0JpOz6W2KgwCRQHdYhXNHy9zT6KAysloXhHQ/hOeTshRrvzzokRWoOtTVFIaGJW9 sS5f02ElbmXMn/LkeVKOR4b6Yfz1zUnGTUDxpT4Ye5Ihw5JJ1X9/0nf8EGk8wkEmtcbG nEp8pW8e9pgk/1cMw5kZkaVpMPjftO2Ba0jz3+xdynw1tApOiyavIqREco9qyGZMDpPv uYRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=xHkdB3c973X60zmJfnAzOt8eoxgaY8SyHNr8d/iQZ9o=; b=VdggbkgotdSFUIe9jjvv54tB9GmfS4EOtjUul20dG1UB9gqw4yNFfNsl06gsQ836pQ +/bYbZNfdH42AF2ZcOHGtHb/6vDX2wFPI7ek8A+21hC6gXvRGaD3PL0meRTC6iTdzIUO AiX/9rhet4rSgQf3RNSAcXHupvAOC4wudptW9vuhywSwRAlWFgusnhCw9oQu/OtGAOkJ Y6nzR6MfPCc4iAonoHyKosucKZi4RtelzTboeeZ19qSYrmKVMxnyxyf0xuirgo4ij75R T+NvalHkQ8mQVH4d6iN9WRAymuc70rVrrcz2UevIwSexatbK/++ojc62GtnX1NcDgNhZ CdKg== 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:cc: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=xHkdB3c973X60zmJfnAzOt8eoxgaY8SyHNr8d/iQZ9o=; b=Hn+4XJYjRlS7zwDj4DXOritrVFmXQ/GD5MJM9PJBJOY+oydVDN4GQbniB8tXOK3uaq 7IO7ZuYhxHQHekMvZEodD3ssw4njMToVt3Q/mH/IVQ6CBYcxzq54nktIgO9DLK+N8cko SOQqVnWSbFJ4Y3oOpu4nKhhCLLtz295PCo/IjdSkK2g9hzergeTXvpa66ENa0BAwvFTn s0AXeqIMMXA9vmjPgapRlE81vwYH0FogW+o5lrwZkqliKt60UwFfuwCgSqFrWhedxokN 4ZxfHtul5xuILJRhkB8C/9bO7NVpp7SRc/f/oxGucbvsJYyNsQOU9IbxGQi5fYHbKtan BAJQ== X-Gm-Message-State: AMke39lXB8u9MqBjcNqq81/nXDs4r/Um9MPyKIUUZNwq78T/BV10CRv17gF2cyiadLTyTg== X-Received: by 10.107.164.216 with SMTP id d85mr3165555ioj.10.1487369696822; Fri, 17 Feb 2017 14:14:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.39.226 with SMTP id c89ls5539195otb.2.gmail; Fri, 17 Feb 2017 14:14:56 -0800 (PST) X-Received: by 10.157.62.29 with SMTP id a29mr900951otd.5.1487369696065; Fri, 17 Feb 2017 14:14:56 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@gmail.com 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:30974 Archived-At: ------=_Part_434_218215407.1487369695462 Content-Type: multipart/alternative; boundary="----=_Part_435_1761947262.1487369695463" ------=_Part_435_1761947262.1487369695463 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, February 17, 2017 at 5:06:14 PM UTC-5, inkwizyt...@gmail.com=20 wrote: > > > > On Friday, February 17, 2017 at 8:54:24 PM UTC+1, Walt Karas wrote: >> >> 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 asi= de, 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,= =20 >>> can thread T2 see them as Y before X while thread T3 sees them as =E2= =80=8EX before=20 >>> Y? >>> >>> 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 (threa= d=20 >>> local) memory and fence operations. >>> - For any operations X and Y in thread T, either X before Y, or Y befor= e=20 >>> 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 L= O=20 >>> is a local memory operation in thread T, and GO is a global operation. = If=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_ exis= t.) >>> - If LO1 and LO2 are operations in thread T, and LO1 before LO2 in T,= =20 >>> and f(T, LO1) and f(T, LO2) both exist, then f(T, LO2) before f(T, LO1)= in=20 >>> the 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)=20 >>> with an activated fence F, then f(T, X) must exist. >>> - For every global operation GO, there must exist a local operation LO= =20 >>> in some thread T where f(T, LO) -> GO. (Assuming no intense gamma=20 >>> radiation.) >>> - A sequentially consistent (thread local) atomic memory operation=20 >>> implies two sequentially consistent fences, one before and one after it= (as=20 >>> well as a preceding release for a store, and a succeeding acquire for a= =20 >>> load). >>> >>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "ISO C++ Standard - Future Proposals" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an 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-f= 04a-46e6-b93a-0b9ea85cb5bd%40isocpp.org=20 >>> >>> . >>> >>> >> Here is some code that illustrates some points of confusion I have with= =20 >> the memory model: >> >> (...) >> >> while (*Twins_number < equals_mine) >> ; >> > =20 > I'm not expert or even experienced in atomics but I think that is race=20 > condition because you access this variable without synchronization. You= =20 > would need probably fence or acquire in `while` otherwise compiler can=20 > amuse that value will not change there. > Actually, it does use synchronization. `operator*` executes a `load()` on= =20 the atomic object. That forces synchronization. --=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/e95d8da5-4d52-4582-be4c-1ed9c1c4c84e%40isocpp.or= g. ------=_Part_435_1761947262.1487369695463 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, February 17, 2017 at 5:06:14 PM UTC-5, = inkwizyt...@gmail.com wrote:


On Friday, February 17, 2017 at 8:54:24 PM UTC+1, Wa= lt Karas wrote:
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 as= ide, and focusing on understanding (which may just mean this could be a std= -discussion question instead of std-proposal),

In your model, if X and Y ar= e relaxed atomic operations in thread T1, can thread T2 see them as Y befor= e X while thread T3 sees them as =E2=80=8EX before Y?
= =
= = =
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0port= able=C2=A0Babbage=C2=A0Device
= = <= td colspan=3D"2" style=3D"font-size:initial;text-align:initial;background-c= olor:rgb(255,255,255)">
From: 'Walt Karas' via ISO C++ = Standard - Future Proposals
Sent: Wednesday, February 15, = 2017 2:17 PM
To: ISO C++ Standard - Future Proposals
= Subject: [std-proposals] Proposed alternative approach to specifyi= ng required memory operation ordering
=

- In a program exe= cution,=C2=A0each thread defines a nominal order of (thread local) memory a= nd fence operations.
- For any operations X and Y in thread T, ei= ther X before Y, or Y before X.
- A program execution defines a n= ominal global order of global memory operations.
- If X and Y are= atomic global operations, then either X before Y or Y before X in the glob= al order.
- If X is a global operation, and there exists a global= store S where neither X before S nor S before X in the global order, then = the result of X is undefined.
- A program execution defines a par= tial function f(T, LO) -> GO where LO is a local memory operation in thr= ead T, and GO is a global operation.=C2=A0 If LO is atomic, then GO must be= atomic. The result of LO is the result of GO.=C2=A0 If the result of GO is= undefined, the result of LO is undefined.=C2=A0 (Even if f(T, LO) is not r= equired to exist, it none the less _may_ exist.)
- If LO1 and LO2= are 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 n= ot allowed.
- If:
1.=C2=A0 In a thread T, X and Y are m= emory 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 consisten= t and both X and Y are atomic, or
4.=C2=A0 F is acquire and both = X and Y are loads, or
5.=C2=A0 F is release and both X and Y are = stores.
then F is activated for X and Y.
-=C2=A0In a th= read T, if X and Y are memory operations (where X before Y) with an activat= ed 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) = -> GO.=C2=A0 (Assuming no intense gamma radiation.)
- A sequen= tially consistent (thread local) atomic memory operation implies two sequen= tially consistent fences, one before and one after it (as well as a precedi= ng 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.o= rg.
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.


Here is some code that ill= ustrates some points of confusion I have with the memory model:
<= br>
(...)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 while (*Twins_number < equa= ls_mine)
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;
= =C2=A0
I'm not expert or even experienced in atomics but I think tha= t is race condition because you access this variable without synchronizatio= n. You would need probably fence or acquire in `while` otherwise compiler c= an amuse that value will not change there.

Actually, it does use synchronization. `operator*` executes a `load()`= on the atomic object. That forces synchronization.

--
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/e95d8da5-4d52-4582-be4c-1ed9c1c4c84e= %40isocpp.org.
------=_Part_435_1761947262.1487369695463-- ------=_Part_434_218215407.1487369695462-- .