From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: backlog1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!news.stack.nl!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Safety of unprotected concurrent operations on constant objects Date: Thu, 8 May 2014 14:52:05 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com> <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com> <83ha6vuynrzs.1jk08faxb8mnl.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1399578725 1027 69.95.181.76 (8 May 2014 19:52:05 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 8 May 2014 19:52:05 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: number.nntp.dca.giganews.com comp.lang.ada:186309 Date: 2014-05-08T14:52:05-05:00 List-Id: "Brad Moore" wrote in message news:xtDav.68151$7X2.15124@fx19.iad... ... >> The rules you propose actually are good only for lock-free concurrency. > > There's million's of simple functions and procedures that do not involve > any locking. Integer "+" for example, is completely task safe. I had proposed labeling such functions "super_pure" and making compile-time checks to ensure that is respected. That was in relation to other things (optimization of contract assertions), but it also applies to real-time. This categorization is really separate from task-safe, since it is much stronger than that (a super_pure function always will give the same answer for identical values of arguments, so one can have a version of 10.2.1(18/3) that applies to such functions; in additional, I'd advocate completely eliminating the effect of 1.1.4(18) for super_pure calls, such that parallel execution of them is always allowed. [Aside: We need such permissions, even if super_pure is statically checked, because of the possibility of interfacing or chapter 13-ish items lying about the super_pure-ness of a function. We don't want compilers considering such lying at all; they should be able to assume that super_pure means task-safe.] This idea didn't receive much traction (we ended up going with expression functions as a way of dealing with the contract issues), but the need really hasn't left. The "problem" is that a lot of things cannot be super_pure (a dereference, for instance, since it's effectively a reference to a global storage pool), so what you can do with super_pure functions is rather limited. Brad is looking at ways to provide another level of task safety for more arbitrary stuff. That can't be checked (at least with any level of completeness), but a declaration of intent would be a useful thing even if not completely checked. Randy.