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

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

[reinert]

Mostly for curiosity:

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?

reinert,
https://korsnesbiocomputing.no/

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

[Dmitry A. Kazakov]

On 2017-11-12 06:23, 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?

Barrier is evaluated only when required to. E.g. in the case of a 
protected object after you leave an object's procedure or entry. Updates 
from outside are most likely ignored.

> Letting barriers depend on external data = asking for trouble?

Well, most of the time.

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

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

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2017-11-12 06:23, 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?
>
> Barrier is evaluated only when required to. E.g. in the case of a
> protected object after you leave an object's procedure or
> entry. Updates from outside are most likely ignored.

GNAT generates a barrier-evaluation function which is called as Dmitry
says. If that function (i.e. the entry condition) involves external data
then the external data will be considered, but only at that time.

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

[Jeffrey R. Carter]

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

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

[Randy Brukardt]

"reinert" <reinkor@gmail.com> wrote in message 
news:eba98c11-5a28-476d-b508-96e73469a256@googlegroups.com...
>Letting barriers depend on external data = asking for trouble?

Yes. Barriers are only checked after some other protected action completes 
(that might change the *internal* data). There is no attempt to check for 
changes in external data.

                       Randy.