Re: Safety of unprotected concurrent operations on constant objects

[Natasha Kerensikova <lithiumcat@instinctive.eu>]

On 2014-05-08, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Natasha Kerensikova" <lithiumcat@instinctive.eu> 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