Re: About protected objects: entries with barriers depending on external data = bad practice ?

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

On 11/12/2017 06:23 AM, reinert wrote:
> 
> Assume a protected entry with a barrier depending on external data - and it is waiting for its barrier to become true. It must be laborious to check the barrier depending on something "far-far away"? How is this checking done in practice? The entry waits for other entries, procedures or functions and when they arrive, it may start before them? Or something more efficient?
> 
> Letting barriers depend on external data = asking for trouble?

Barriers are evaluated when the PO's state changes; that is, as others have 
said, when a procedure or entry of the same PO has executed. So having a barrier 
that depends on external data requires some way of notifying the PO that the 
external data have changed. Typically this involves polling:

External : Boolean := False;
pragma Atomic (External); -- or Volatile

protected PO is
    procedure Evaluate_Barrier; -- Causes Wait's barrier to be evaluated
    entry Wait; -- Blocks caller until External becomes True
end PO;

protected body PO is
    procedure Evaluate_Barrier is null;

    entry Wait when External is
       -- Nothing to see here, folks
    begin -- Wait
       External := False;
    end Wait;
end PO;

task Poller;

task body Poller is
    Interval : constant Ada.Real_Time.Time_Span := ...;

    Next : Ada.Real_Time.Time := Ada.Real_Time.Clock + Interval;
begin -- Poller
    Forever : loop
       delay until Next;

       Next := Next + Interval;
       PO.Evaluate_Barrier;
    end loop Forever;
end Poller;

Of course, there are lots of opportunities for error here, so it should be 
avoided if possible.

-- 
Jeff Carter
"Ah, go away or I'll kill ya."
Never Give a Sucker an Even Break
100