Re: GNAT and Tasklets

["Randy Brukardt" <randy@rrsoftware.com>]

"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnm97p2q.nrc.lithiumcat@nat.rebma.instinctive.eu...
> Hello,
>
> On 2014-12-18, Randy Brukardt <randy@rrsoftware.com> wrote:
>> [...]                           That's true of *any* Ada object --  
>> without
>> documentation and/or code to manage it, it should be assumed to only work
>> with one task at a time.
>
> That's a bit at odds with a recent (or not so recent) discussion, where
> I didn't find in the RM where it is written that concurrent read-only
> basic operations (like access dereference, array indexing, etc) are
> task-safe, and the answer was that everything should work as expected
> unless explicitly noted otherwise, even when concurrency is involved.

No it's not. You are talking about "operations" and I'm talking about 
"objects". Very different things! Now, any ADT is going to have both objects 
and operations, so it's rather hard to do a concurrent operation without 
using concurrent objects.

> For example, I wrote Constant_Indefinite_Ordered_Maps (available at
> https://github.com/faelys/natools/blob/trunk/src/natools-constant_indefinite_ordered_maps.ads )
> which is an ordered map based on a binary search in a sorted array.
> It is meant to be task-safe without any code to manage it, basing its
> safety solely under the assumption that concurrent access dereference
> and concurrent array indexing are safe.

Sure, those OPERATIONS are safe. But not (necessarily) access to the object: 
that's only safe if the object is volatile or if the object is never 
written. See 9.10 and the associated A(3).

I personally do not believe in the "read-only" data structure (although 
others disagree). My experience is that such structures are usually 
read-mostly -- which means they still need some sort of protection. Some 
have claimed that protection by convention is enough -- which to me brings 
to mind what they say about the "rhythm" method of contraception ("people 
that use rhythm are called parents"). Someone will break the convention and 
then you'll get cars that will accelerate without commands and other lovely 
things.

> I hope it's not a brittle assumption...

It's safe if you can truly prove that the data structure is read-only and 
*never* gets written. I think *that* is brittle, but YMMV.

Example: the parameters in my spam filter rarely change. But rarely is not 
never, and unless I was willing to restart the filter for every parameter 
change, they still have to be protected.

                                        Randy.



>
> Natasha