Can a protected action tie up the calling task?

Can a protected action tie up the calling task?

[Samuel Mize]

Greetings,

I need to verify a point on how protected actions work.  Please email
me, as my news feed provides *very* variable delays.

My understanding is that, after an entry or procedure completes, the
queues for that object are serviced as far as possible before the
protected action completes.  This is done by any convenient thread of
control (ARM 9.5.3(22)).  This permission ALLOWS but does not REQUIRE
that the task calling the entry or procedure be released before the
protected action completes.

Thus, in the following example, if another task has already called
Complete before task T1 calls Prepare:

- T1's thread of control can execute Complete;

- this COULD keep T1 suspended until Complete terminates.

Example:

     protected Monitor is
      entry Prepare (D: in Data);
      entry Complete;
    private
      Ready_To_Complete: boolean := false;
    end Monitor;

    protected body Monitor is
      entry Prepare (D: in Data)
      when not Ready_To_Complete is
        ...
      entry Complete
      when Ready_To_Complete is
        ...
    end Monitor;

So to ENSURE that T1 can continue processing IMMEDIATELY on completion
of Prepare, we must ensure that Complete is not called before Prepare.
A third entry is probably the simplest way to do this (task T2 calls
Wait_For_Preparation, then Complete).

    protected Monitor is
      entry Prepare (D: in Data);
      entry Wait_For_Preparation;
      procedure Complete;
    private
      Ready_To_Complete: boolean := false;
    end Monitor;

    protected body Monitor is
      entry Prepare (D: in Data)
      when not Ready_To_Complete is
        ...
      entry Wait_For_Preparation
      when Ready_To_Complete is
        ...
      procedure Complete is
        ...
    end Monitor;

Is this correct?  Have I missed something?

Thanks,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net -- Team Ada
(personal net account)

Re: Can a protected action tie up the calling task?

[Tucker Taft]

Samuel Mize (smize@news.imagin.net) wrote:

: I need to verify a point on how protected actions work.  Please email
: me, as my news feed provides *very* variable delays.

: My understanding is that, after an entry or procedure completes, the
: queues for that object are serviced as far as possible before the
: protected action completes.  This is done by any convenient thread of
: control (ARM 9.5.3(22)).  This permission ALLOWS but does not REQUIRE
: that the task calling the entry or procedure be released before the
: protected action completes.

The task may continue before the overall protected *action* completes,
but certainly not before its own protected *operation* completes.
A protected *action* is a sequence of protected operations all
done under a single locking of the protected object.  As soon
as the protected operation associated with a given caller
is complete, that caller may continue (unless of course the
protected operation ends with a requeue).

: Thus, in the following example, if another task has already called
: Complete before task T1 calls Prepare:

: - T1's thread of control can execute Complete;

: - this COULD keep T1 suspended until Complete terminates.

If T1's thread of control is executing Complete, then that
thread is certainly not suspended.
If T1's thread of control is *not* executing Complete, then
there would be no reason why it would be suspended any longer
than absolutely necessary (and I wouldn't waste any energy
in trying to account for that possibility -- that is like
worrying that computing 2+3 might take 2 hours).

: Example:

:      protected Monitor is
:       entry Prepare (D: in Data);
:       entry Complete;
:     private
:       Ready_To_Complete: boolean := false;
:     end Monitor;

:     protected body Monitor is
:       entry Prepare (D: in Data)
:       when not Ready_To_Complete is
:         ...
:       entry Complete
:       when Ready_To_Complete is
:         ...
:     end Monitor;

It is a little hard to know how Prepare and Complete are related
since you don't show what they do to the "Ready_To_Complete"
flag, but I will presume that Prepare sets it True, and
Complete sets it back to False.

: So to ENSURE that T1 can continue processing IMMEDIATELY on completion
: of Prepare, we must ensure that Complete is not called before Prepare.

I can't quite imagine why you care so much.  Even if T1
*can* continue processing immediately, there is no reason
why it will if its priority is lower.  And remember that
when a task holds a protected object lock, it inherits
the ceiling priority of the protected object, so whichever
task that executes Complete will inherit a priority that is
definitely not lower than T1's priority.

: A third entry is probably the simplest way to do this (task T2 calls
: Wait_For_Preparation, then Complete).

:     protected Monitor is
:       entry Prepare (D: in Data);
:       entry Wait_For_Preparation;
:       procedure Complete;
:     private
:       Ready_To_Complete: boolean := false;
:     end Monitor;

:     protected body Monitor is
:       entry Prepare (D: in Data)
:       when not Ready_To_Complete is
:         ...
:       entry Wait_For_Preparation
:       when Ready_To_Complete is
:         ...
:       procedure Complete is
:         ...
:     end Monitor;

: Is this correct?  Have I missed something?

The only thing missing is the background for the problem.
What is it that Complete is doing that you want to be sure
that T1 doesn't execute or wait for?  Given inheritance
of ceiling priority, it is a little hard to imagine how
you could ever guarantee that T1 will continue first.

: Thanks,
: Sam Mize

: -- 
: Samuel Mize -- smize@imagin.net -- Team Ada
: (personal net account)

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA