Re: Safety of unprotected concurrent operations on constant objects

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 06 May 2014 00:00:40 -0600, Brad Moore wrote:

> On 05/05/2014 10:36 AM, Dmitry A. Kazakov wrote:
>> On Mon, 05 May 2014 09:11:05 -0600, Brad Moore wrote:
>>
>>> Eg. For Ada.Containers.Vectors...
>>>
>>> type Vector is tagged private
>>>      with
>>>         Constant_Indexing => Constant_Reference,
>>>         Variable_Indexing => Reference,
>>>         Default_Iterator  => Iterate,
>>>         Iterator_Element  => Element_Type,
>>>         Task_Safe         => False;
>>>
>>> Then programmers could apply the aspect to their own abstractions, which
>>> better defines the contract of the subprogram or type.
>>
>> Task safety is not a type property. Even for a tagged type an unsafe
>> operation can be defined later on. For non-tagged types it is even less
>> clear which operations must be safe and which not.
>>
>> Furthermore, task-safety cannot be inherited or composed. At least not
>> without massive overhead to prevent deadlocking when two safe types meet as
>> mutable parameters of a safe subprogram.
> 
> I agree that such a property is not likely inheritable or composable, 
> and I don't think we'd want it to be.  I think conceivably it could 
> apply to a type, however. It may be that such an aspect could only be 
> applicable to tagged types, and only would apply to the primitive 
> subprograms of that type. The aspect, if true would become false for any 
> derivations of that type, unless those derived types also explicitly set 
> the aspect to True.

If you limit it to primitive operations then much simpler to do this:

   type My_Container is tagged ...; -- All operations are unsafe

   type My_Safe_Container is protected new My_Container with null record;

When inherited from, the compiler would override each primitive operation
and wrap it with a reentrant mutex taken. When an operation gets overridden
its new body is wrapped. Calling operation within a protected action would
be bounded error. At least the compiler would be able to maintain mutexes
of such objects, e.g. order them to prevent deadlocks.

[Better of course, would be to have a decent delegation support]

>> And, just how this contract is supposed to be verified?
> 
> I see it more as a contract or promise made by the implementer to the 
> users of that subprogram that concurrent calls to the subprogram will 
> work.

You can use this contract no more you can verify it. Because the compiler
does not know if a call is concurrent or not.

> At this point, I have doubts that the compiler could 100% guarantee that 
> a subprogram call is task safe, but there are likely rules and
> restrictions that could be applied that would allow the compiler to 
> catch many problems.
> 
> In particular, the aspect could restrict the associated subprogram to
> disallow:
> 
> (1) Calls on other non-protected subprograms that are not Pure or
>      Task_Safe;

But calling a task-safe subprogram from another task-safe subprogram were a
much bigger problem than calling a non-safe subprogram. Protected
operations specifically forbid to do exactly this. You could call another
task-safe operation only on the same object and only if the implementation
deploys reentrant locking.

The rules you propose actually are good only for lock-free concurrency.
Unfortunately only few things can be done lock-free, and most types of
containers certainly not.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de