Re: Status of AdaCL: Ada Class Library

["Alex R. Mosteo" <alejandro@mosteo.com>]

Stephen Leake wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> Am 22.02.2010, 02:51 Uhr, schrieb Björn Persson <bjorn@rombobjörn.se>:
>>
>>> I had intended to switch from Charles to Ada.Containers, but I changed
>>> my mind when I learned that Ada.Containers can't even be read by
>>> multiple
>>  > tasks at once.
>>
>> For the record, we've studied this several times and have always
>> concluded that hidden synchronization is dangerous. That is,
>> synchronization should be explicit. Beyond that, it is impossible to come
>> up with a reasonable definition of what should be locked -- it really
>> depends on the use of the containers.
> 
> I agree with this, but I think the OP was implying that you needed
> locking even for read-only access of Ada.Containers from multiple
> tasks; is that true? I don't see why it should be; each task declares
> its own cursors, which don't interfere with each other.

I think that the downward closure subprograms update some flags inside the 
container. E.g., in gnat doubly linked lists, within the Query_Element:

procedure Query_Element
     (Position : Cursor;
      Process  : not null access procedure (Element : Element_Type));

Pretty read-only, it seems, but inside you find:

      declare
         C : List renames Position.Container.all'Unrestricted_Access.all;
         B : Natural renames C.Busy;
         L : Natural renames C.Lock;

      begin
         B := B + 1;
         L := L + 1;
(...)

So, basically, yes, even certain read-only uses are not thread-safe (Element 
would be, at least in gnat implementation).

Never though of this before, but even wrapping a call to that in a protected 
function would be dangerous, since protected functions are concurrent? And 
that's a procedure with only "in" arguments, which would be callable from 
such a function.

Am I right here?