Re: Safety of unprotected concurrent operations on constant objects

[Brad Moore <brad.moore@shaw.ca>]

On 14-05-13 02:56 AM, Dmitry A. Kazakov wrote:
> On Mon, 12 May 2014 22:50:03 -0600, Brad Moore wrote:
>
>> I lumped task safe programs with while loops into the
>> Potentially_Blocking category, because while loops can be used to
>> implement busy spin-loops, which can be considered a form of blocking.
>
> Loops are used in many (if not most) lock-free algorithms. They have
> bounded time, because the loop condition is that the task has been
> preempted during execution of the loop body, which may happen only once,
> provided scheduling is any reasonable.
>
>>> What I had in mind are designs like:
>>>
>>> type T is record
>>>      M : aliased Mutex;
>>>      ...
>>> end record;
>>>
>>> A safe operation on this type looks like:
>>>
>>>      procedure Safe_Search (X : in out T; ...) is
>>>          Lock : Holder (T.M'Access);
>>>      begin
>>>          Unsafe_Search (X, ...);
>>>      end Safe_Search;
>>>
>>> Here safe operations call to unsafe ones all the time and never do each
>>> other because M is not reeentrant.
>>
>> Thanks for the example. A good case to consider. By the rules I'm
>> thinking of, this would not be a task-safe construct however, which I
>> think is rightly so.
>>
>> The Task_Safe attribute is about subprograms that can be proven to be
>> safe. This construct is unsafe, because it doesn't guarantee that there
>> aren't direct concurrent calls to Unsafe_Search happening while inside
>> the body of Safe_Search. (It would probably be too difficult to prove,
>> and so its better to assume the worst, when it comes to safety.)
>> Therefore Safe_Search is also not a task-safe call.
>
> This is why I consider these attributes useless as they would work for
> marginal cases only.

I think most of the code out there that was written for concurrency 
would probably satisfy the rules. (i.e. It doesn't seem marginal to me) 
In the case of your example, it likely could be made to satisfy the 
rules with some simple adjustments.

For example, you could fold the body of Unsafe_Search into the body of 
Safe_Search. Then you would be guaranteeing that there would be no way 
to circumvent the lock, as there is only the one entry point to your 
function. Your mutex lock function could then have the Task_Safe aspect.

Another approach would be to put the body of Unsafe_Search inside a 
protected object, again guaranteeing that there is no way to circumvent 
the protection.

I think most protected objects typically do not call unsafe subprograms.

>
> [...]
>
> The rules you are proposing seem to me focusing on rather atomicity than
> task safety.
>

The goal is to be able to say that a subprogram can be called safely, 
without erroneousness with other concurrent calls.

Atomicity plays a part of it, but subprograms such as pure functions 
that don't modify state also fall under the umbrella.