Re: Safety of unprotected concurrent operations on constant objects

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

On 14-05-12 02:13 AM, Dmitry A. Kazakov wrote:
> As a side note safety is not about
> halting or time constraints. A never ending subprogram could be still safe.
> Overstretching this a bit, a task body running infinite loop is task-safe.

Right. And that would still be the case by the rules I have been 
suggesting. (Note the distinction between "task safe" proper and 
Task_Safe the aspect, with an underscore.) The idea is that subprograms 
that have either Task_Safe or Potentially_Blocking aspects are task safe.

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.


>
> 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.

Another rule I haven't stated is that any subroutine that modifies a 
variable (or internal state) that isn't via a protected object, atomic, 
or volatile and a type that can be atomically updated (such as Integer), 
is not Task_Safe. This would only need to be checked directly in the 
body of the task-safe subprogram, since any subprograms called by that 
subprogram also need to be Task_Safe, and would have been checked during 
their compilation.

So for example, a spinloop on a regular integer would not be considered 
Task_Safe, but a spinloop on a volatile integer would be considered task 
safe (assuming there were no other rule violations).

The rules are meant to be static checks, that are relatively easy to 
implement (I hope) and they shouldn't introduce any run-time overhead. 
They would only generate a compiler warning or suppressable error. (i.e 
No runtime exception) So such a construct as you have above wouldn't be 
disallowed. It'd only be that in a mode of stricter checking, the 
programmer would need to suppress the warning or error and indicate that 
the usage is OK.