Re: Potentially_Blocking aspect

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

On 29/04/2016 00:07, Jeffrey R. Carter wrote:
> On 04/28/2016 08:53 AM, mockturtle wrote:
>>
>> Inside a protected object it is forbidden to invoke a potentially blocking
>> operation.  Although some cases are easily recognized, it could be that a
>> procedure invokes (via several levels of indirection) a blocking action. As
>> I understand, you can specify pragma Detect_Blocking, but this works at
>> runtime (since H.5 says "An implementation is required to detect a
>> potentially blocking operation within a protected operation, and to raise
>> Program_Error").
>
> This restriction was a mistake. Protected objects exist to provide
> mutual exclusion without a thread of control.

That is too broad and too narrow. What protected object actually do is 
atomic access to the object's data and synchronization through the entry 
queues.

> There are plenty of cases
> where mutual exclusion is needed, a thread of control is not, and
> blocking operations must be called.

Yes, but that is not a job for an atomic operation, which projected 
object models. An atomic operation is logically instant. A blocking 
operation neither logically nor physically is.

> Requiring the use of a task in such
> cases is unreasonable, but is what we have.

A mutex can be easily implemented using protected objects. And nothing 
precludes Ada designers from introducing an "exclusive" interface or 
aspect (new Ada's darling). For example:

type Task_Unsafe is tagged ...;
procedure Foo (X : in out Task_Unsafe);

type Task_Safe is exclusive new Task_Unsafe with null record;

This translates into:

type Task_Safe is new Task_Unsafe with record
    Mutex : Mutex_Type;
end record;

and overrides all primitive operations of the parent type this way:

procedure Foo (X : in out Task_Safe) is
begin
    X.Mutex.Seize;
    Foo (Task_Unsafe (X));
    X.Mutex.Release;
exceptions
    when others =>
       X.Mutex.Release;
       raise;
end Foo;

[ It would be nice if Ada provided more generic means for delegation 
allowing user-defined wrappers added like above. ]

> Some compilers allow potentially blocking operations in protected
> operations by default, not raising Program_Error even when such an
> operation is detected, unless the user explicitly specifies otherwise.

Yes, but don't let that slip into production code. Text_IO.Put_Line 
inside a protected action is meant for debugging only.

And conversion bugs into run-time errors is a bad idea in general. 
Clearly no run-time check should be made, it is the same wrong of all 
dynamic constraint and accessibility checks.

> Clearly, people frequently want to put such operations into protected
> operations.

And the compiler should prevent them doings this, as much as it can.

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