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!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Safety of unprotected concurrent operations on constant objects Date: Thu, 8 May 2014 09:07:44 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com> <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com> Injection-Date: Thu, 8 May 2014 09:07:44 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="76a49b86bc3e16725b7cfca3d85cb4c8"; logging-data="18100"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19/N4Dj4G0GPxMhCGMez8tH" User-Agent: slrn/1.0.1 (FreeBSD) Cancel-Lock: sha1:1q2tld5gjZA+QITgWL6ZNjXOxqA= Xref: news.eternal-september.org comp.lang.ada:19748 Date: 2014-05-08T09:07:44+00:00 List-Id: On 2014-05-08, Randy Brukardt wrote: > "Natasha Kerensikova" wrote in message > news:slrnlmft61.i0l.lithiumcat@nat.rebma.instinctive.eu... > ... >> But what about dereferencing an access value? Is it safe to concurrently >> dereference the same access value from multiple tasks? >> >> It's hard to imagine dereferencing a pointer to be unsafe, but as we all >> know access are more than mere pointers, with accessibility checks and >> custom storage pools and what not. > > 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. >> 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. 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? Thanks a lot for your insights, Natasha