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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.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: Wed, 7 May 2014 22:12:36 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com> <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1399518756 5508 69.95.181.76 (8 May 2014 03:12:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 8 May 2014 03:12:36 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:19741 Date: 2014-05-07T22:12:36-05:00 List-Id: "Simon Wright" wrote in message news:lyzjiw7h6c.fsf@pushface.org... > Shark8 writes: > >> On 05-May-14 15:23, Brad Moore wrote: >>> In GNAT any read or write operations on a container that set tamper >>> flags are ironically not task safe >> >> That seems very... odd. > > Rationale 05 8.1 [1] says (last para) > > "The general rule is given in paragraph 3 of Annex A which says "The > implementation shall ensure that each language defined subprogram is > reentrant in the sense that concurrent calls on the same subprogram > perform as specified, so long as all parameters that could be passed > by reference denote nonoverlapping objects." So in other words we > have to protect ourselves by using the normal techniques such as > protected objects when container operations are invoked concurrently > on the same object from multiple tasks even if the operations are > only reading from the container." > > AARM12 A.18 (5.m) [2] says > > "If containers with similar functionality (but different performance > characteristics) are provided (by the implementation or by a > secondary standard), we suggest that a prefix be used to identify the > class of the functionality: [...] "Ada.Containers.Protected_Maps" > (for a map which can be accessed by multiple tasks at one time); > [...]" > > Personally I'd like to see the implication (that a standard-compliant > implementation of Containers need not be task-safe unless the Standard > specifies that it must be) made more visible. Of course this is true of all Ada language-defined packages -- the basic rule is found in Annex A (the introductory text). You have similar issues with Text_IO and all other I/O, and most other packages that aren't Pure. We decided not to expose the implicit sharing of some things (specifically the Environment_Variables and the Current_Directory), so those have to be task-safe (mainly because they already are on many target systems, and they're rarely performance-critical anyway). The real problem is that very little in Ada outside of the built-in stuff is required to be task-safe. One of the goals of the parallel stuff is to make this sort of thing more explicit; but this all dates back to Ada 83. Ada 95 made it more explicit to avoid the worst problems (there is a story about an Ada 83 compiler for which very basic stuff wasn't task safe). Indeed, there was a bug in Janus/Ada back in the day that made integer divide not task-safe (on early processors, divide was a software routine, and I had used a library-level temporary object. Bzzzzt!). But that explicitness didn't go very far, because no one wanted locking overhead to turn most Ada programs into dogs (especially those that don't use any tasks). Randy.