220 30986 <3f1014c6-9ea0-4253-b1bb-72b4e5fd1284@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: Sat, 18 Feb 2017 18:01:23 -0800 (PST) Lines: 246 Approved: news@gmane.org Message-ID: <3f1014c6-9ea0-4253-b1bb-72b4e5fd1284@isocpp.org> References: <20170216004134.4902991.82070.24891@gmail.com> <8575c41d-1c8e-4e6f-9f12-a07bb70a7703@isocpp.org> <9f578372-9d47-4f5b-800d-93e08e7d2314@isocpp.org> <2eab187f-e1cd-4c7d-ad30-ac7981963749@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_555_246537066.1487469683153" X-Trace: blaine.gmane.org 1487469686 19462 195.159.176.226 (19 Feb 2017 02:01:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Feb 2017 02:01:26 +0000 (UTC) Cc: inkwizytoryankes@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDFLZXWOVYIBB5HYUPCQKGQENA2PD4Y@isocpp.org Sun Feb 19 03:01:21 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cfGoS-0004M1-LT for gclcip-std-proposals@m.gmane.org; Sun, 19 Feb 2017 03:01:21 +0100 Original-Received: by mail-pg0-f71.google.com with SMTP id 1sf21782660pgz.5 for ; Sat, 18 Feb 2017 18:01:26 -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=bfKdmzwNiZMtiGRTsoUmGldXHlUW62bJdvz03Xjzh7Q=; b=rvBDzdHaAK7HcaROXL44/t42xRdSPoOQnJKoZqPhXjGHE9AcO9ADRpE4Jq0qXxGDnV htdGb6mZqUaVAiF0ecIs5J1bduCpafSZnTimPZtI5vdBOoWQ7Tsl4tvKyeNerr+QZqMb jwIQ1zztCzYsiA63Z3Nn6YurdjWrERsA2mUhKtFYJ7jBsM94cLSjVy21yiMgMTEhOrx5 p+pIKzTcAqNlSyJpuARb0HjfVDxrxrbcvnfsQS7cgcoqeWjvQsYDXYjsSjoGskrMxrFO T9tLhERgHPCeaj2r1dp14eCoAhUIOPMYPRbgzmB3aEJovsklAhuiZ+nTHoWM9sbe4zCs rKqw== 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=bfKdmzwNiZMtiGRTsoUmGldXHlUW62bJdvz03Xjzh7Q=; b=HbLCr1mGk2Bp4F+8caY6ly+Ia0F6qtzpxCbuF2AXKmBiaS61LoitjdGHkNgqR3c0/s TvJCnaGRvX6hhfat2RxX3EAif1KuZq3mr2IuHs/VDK27nKy+V6WZcw3bZu0xhFE58Shv O8Lcr1ji/Y0S9liFyXbHbffcPER6HT5lJC/wUP48w+U/h8qtnfjUzf9OfOdoDQPqczI6 bFETYTsHTQKwSV4/kWWI7MbouFtZKmYJU+72/GQlXHNUbVvfaBhL8G8wjJFQsQJ6vA+2 oionHXb2z53+UDtO51mC3zuseZIU0LtHJUNJD/et52iWqS2ZJra6SvKlUESb3V/Cr7sr 8mRQ== X-Gm-Message-State: AMke39k14nkF476gqjuR2OpzDeNJg9LgkimThk3oW3Z1bKTQnNHT3L1W5BVTAd/+dbBCfA== X-Received: by 10.98.70.138 with SMTP id o10mr3859024pfi.22.1487469685779; Sat, 18 Feb 2017 18:01:25 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.18.240 with SMTP id g103ls7249629otg.39.gmail; Sat, 18 Feb 2017 18:01:23 -0800 (PST) X-Received: by 10.157.39.202 with SMTP id c68mr1198695otb.8.1487469683906; Sat, 18 Feb 2017 18:01:23 -0800 (PST) In-Reply-To: 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:30986 Archived-At: ------=_Part_555_246537066.1487469683153 Content-Type: multipart/alternative; boundary="----=_Part_556_1921074933.1487469683154" ------=_Part_556_1921074933.1487469683154 Content-Type: text/plain; charset=UTF-8 On Saturday, February 18, 2017 at 7:44:57 PM UTC-5, inkwizyt...@gmail.com wrote: > > > > On Saturday, February 18, 2017 at 9:32:45 PM UTC+1, Walt Karas wrote: >> >> >> >>> >>>>>> Here is some code that illustrates some points of confusion I have >>>>>> with the memory model: >>>>>> >>>>>> (...) >>>>>> >>>>>> while (*Twins_number < equals_mine) >>>>>> ; >>>>>> >>>>> >>>>> I'm not expert or even experienced in atomics but I think that is race >>>>> condition because you access this variable without synchronization. You >>>>> would need probably fence or acquire in `while` otherwise compiler can >>>>> amuse that value will not change there. >>>>> >>>> >> ... >> >>> >>>> >>> Maybe using Cardinal = unsigned would work with optimization enabled if >>>> I put an acquire fence in the loop. But that seems a cheat. >>>> >>> >>> Why is that a cheat? You need to tell the compiler that operations from >>> another thread may affect the execution with this one. That's *exactly* >>> what a fence does. >>> >>> >> Consider this sequence: >> >> spam, spam, spam, spam, spam, spam, spam >> >> If I claimed that it was important to maintain the order of this >> sequence, I would be rightly considered an idiot. Likewise, it makes no >> sense to put a fence in the while loop to maintain the order of >> *identical* memory loads. It would be some side effect of the fence >> that would be of any benefit. That is the sense in which I think it would >> be a cheat. >> >> Maybe it's correct that atomic operations are about more than atomicity, >> and fences are about more than creating rules about the partial ordering of >> actual memory operations (on a single nominal memory for all threads). But >> if so, I don't think the Standard memory model is very clear about this. >> >> ... >> > > Consider this trivial program: > > > int i = 0; > int main() > { > i = 1; > while (i) > ; > } > > What behavior you expect from this code? GCC will made infinite loop > there. Why? because this is single thread program and nobody can change > value of `i` after assignment. > Your loop is exactly the same, without atomics compiler assume your code > is locally "single thread" and nobody can change this values outside this > threads. > Remember atomic operation are very costly, if every line use atomic > implicitly then you would pay this cost even if you not need or even didn't > want. > Consider fact that some people do not want use `shared_ptr` because it use > internally atomic operations and this cost them too much. > Yes, but the issue is, what is a good memory model for representing that and other issues with multi-threading. The reality is threads do "unsniffed" partial caching of the nominal memory that is seen consistently by all threads. And compiler and instruction pipeline optimization cause the actual order of memory accesses by threads to be different from the nominal order (that the programmer determines with the code). The Standard's approach is to model all of this as fairly unlimited reordering of actual memory accesses versus nominal ones, and then provides mechanisms to limit the reordering. It's not clear to me whether the Standard specifies a partial or full ordering of accesses. If it's partial, then all the loads caused by while (i); can be in the same equivalence class, or, if it's full, all the loads caused by while (i) can be successive on the location of i with no intervening stores to i. I think it's probably better a better model where each thread nominally caches all of memory. The order of accesses on the cache can nominally be considers the nominal one for the thread. But then there is per-memory-location read/write throughs of the thread cache, that can happen unpredictably and with unpredictable order from the global perspective. So mechanisms are needed to limit the unpredictability in order to avoid race conditions. In the case of while (i); you'd want to cache-invalidate i for each iteration of the loop. But, from the global perspective, all the resulting read-throughs to common memory of i would be identical loads, so any idea of imposing order on them would make no sense. -- 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 email 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/3f1014c6-9ea0-4253-b1bb-72b4e5fd1284%40isocpp.org. ------=_Part_556_1921074933.1487469683154 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Saturday, February 18, 2017 at 7:44:57 PM UTC-5= , inkwizyt...@gmail.com wrote:
=


On Saturday, February 18, 2017 at 9:32:45 PM UTC+1= , Walt Karas wrote:
=C2=A0

Here is some code that illustrates some points = of confusion I have with the memory model:

(...)

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 while (*Twins_number < equals_mine)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ;
=C2=A0
I'm no= t expert or even experienced in atomics but I think that is race condition = because you access this variable without synchronization. You would need pr= obably fence or acquire in `while` otherwise compiler can amuse that value = will not change there.

...=C2=A0
=C2=A0
Maybe using Cardinal =3D= unsigned would work with optimization enabled if I put an acquire fence in= the loop.=C2=A0 But that seems a cheat.

W= hy is that a cheat? You need to tell the compiler that operations from anot= her thread may affect the execution with this one. That's exactly what a fence does.

=C2=A0
= Consider this sequence:

spam, spam, spam, spam, sp= am, spam, spam

If I claimed that it was important = to maintain the order of this sequence, I would be rightly considered an id= iot. =C2=A0Likewise, it makes no sense to put a fence in the while loop to = maintain the order of identical=C2=A0memory loads. =C2=A0It would be= some side effect of the fence that would be of any benefit. =C2=A0That is = the sense in which I think it would be a cheat.

Ma= ybe it's correct that atomic operations are about more than atomicity, = and fences are about more than creating rules about the partial ordering of= actual memory operations (on a single nominal memory for all threads). =C2= =A0But if so, I don't think the Standard memory model is very clear abo= ut this.

...

Consider t= his trivial program:

=C2=A0
<= code>
int = i =3D <= /span>0;
int main()
{<= span style=3D"color:#000">
=C2=A0 =C2=A0 i =3D 1;=C2=A0 =C2=A0 while (i)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;
}=

What behavior = you expect from this code? GCC will made infinite loop there. Why? because = this is single thread program and nobody can change value of `i` after assi= gnment.
Your loop is exactly the same, without atomics compiler assume y= our code is locally "single thread" and nobody can change this va= lues outside this threads.
Remember atomic operation are very costly, if= every line use atomic implicitly then you would pay this cost even if you = not need or even didn't want.
Consider fact that some people do not = want use `shared_ptr` because it use internally atomic operations and this = cost them too much.

Yes, bu= t the issue is, what is a good memory model for representing that and other= issues with multi-threading. =C2=A0The reality is threads do "unsniff= ed" partial caching of the nominal =C2=A0memory that is seen consisten= tly by all threads. =C2=A0And compiler and instruction pipeline optimizatio= n cause the actual order of memory accesses by threads to be different from= the nominal order (that the programmer determines with the code). =C2=A0Th= e Standard's approach is to model all of this as fairly unlimited reord= ering of actual memory accesses versus nominal ones, and then provides mech= anisms to limit the reordering. =C2=A0It's not clear to me whether the = Standard specifies a partial or full ordering of accesses. =C2=A0If it'= s partial, then all the loads caused by while (i); can be in the same equiv= alence class, or, if it's full, all the loads caused by while (i) can b= e successive on the location of i with no intervening stores to i. =C2=A0I = think it's probably better a better model where each thread nominally c= aches all of memory. =C2=A0The order of accesses on the cache can nominally= be considers the nominal one for the thread. =C2=A0But then there is per-m= emory-location read/write throughs of the thread cache, that can happen unp= redictably and with unpredictable order from the global perspective. =C2=A0= So mechanisms are needed to limit the unpredictability in order to avoid ra= ce conditions. =C2=A0In the case of while (i); you'd want to cache-inva= lidate i for each iteration of the loop. =C2=A0But, from the global perspec= tive, all the resulting read-throughs to common memory of i would be identi= cal loads, so any idea of imposing order on them would make no sense.=C2=A0=

--
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/3f1014c6-9ea0-4253-b1bb-72b4e5fd1284= %40isocpp.org.
------=_Part_556_1921074933.1487469683154-- ------=_Part_555_246537066.1487469683153-- .