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!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:35:51 -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 1399577752 517 69.95.181.76 (8 May 2014 19:35:52 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 8 May 2014 19:35:52 +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:19755 Date: 2014-05-08T14:35:51-05:00 List-Id: "Natasha Kerensikova" wrote in message news:slrnlmmiav.i0l.lithiumcat@nat.rebma.instinctive.eu... > On 2014-05-08, Randy Brukardt wrote: ... >> The language only allows specific things to *not* be task-safe. You can >> read >> 9.10 and Annex A to find out what they are. (And then tell the rest of >> us, >> 9.10 is impentrable. :-) In particular, if 9.10 doesn't include something >> in >> the possible erroneous execution, then it has to be task safe. (For the >> obvious reason that the language spells out what *doesn't* have to >> work -- >> everything else has to work in all conditions.) > > Actually that was not all obvious to me, so I was looking something > explicit saying that whatever isn't covered by 9.10 is fine, and got > worried for not finding one. Unless the language specifically allows "erroneous execution" or "bounded errors", it has to work as specified. In all ways. That's spelled out in 1.1.3. The Standard wouldn't mean much if ignoring what it says was fine. (But beware of 1.1.3(6), the "impossible or impractical" exception. As a rule, implementors lean on that only when all else fails. But it's obviously a squishy construct. The basic idea of "impractical" is that implementations shouldn't spend excessive resources being perfect if that doesn't make sense on the underlying target system. An example that recently came up involves ATC on Windows. Windows doesn't support external interruption of threads in most circumstances, so ATC isn't really going to work right on Windows (there will be a delay on unknown length before it actually aborts). One could make heroic efforts to make ATC work right (avoiding Windows threads, for instance), but that would have costs all over the rest of tasking and I/O -- and those features are all a lot more common than ATC. >>> By the way, are implicit subprograms calls, like the storage pool thing >>> on dereference, also covered by the non-guarantee of concurrent read >>> safety? >> >> Yes. There's nothing special about calls to Allocate or Finalize or >> similar >> routines. > > When I asked this, I had in mind the Dereference abstract procedure from > GNAT's System.Checked_Pools, because then I incorrectly believed it to > be part of standard custom storage pool. > > That case is still interesting, because now there *is* something special > about that call: it replaces a feature that is "intrinsic" according to > the standard. If I understand correctly the first part of your reply, > it means that the Dereference procedure must be thread-safe, despite > taking an in out storage pool object. Typically, once you use something implementation-defined, it's the implementation that gets to define the rules. So if you override Dereference, what effect that has is solely defined by the implementation. The language rules are out the window. If one truly wants portable code, one has to stay within what the Standard provides. > So to sum it up, I can put an access-to-array in a protected object, > replace it using a protected procedure, and safely use it concurrently > as a map using a binary search in a protected function. > I can then hide the protected object in the private part, wrap it in a > thread-safe reference type to avoid limited mess, and ensure the array > is sorted before handing it to the protected object. > And then everything would be fine, right? Or am I missing something? I think this should work; it sounds roughly like what I did in my spam filter. Without seeing the details, I wouldn't want to make any proclamations of certainty, though. Randy.