Protected Objects (Geeenhills & VxWorks)

Protected Objects (Geeenhills & VxWorks)

[R. Tim Coslet]

We have been having repeated problems where Protected Objects don't seem
to be functioning correctly in the environment we are working with
(Greenhills V1.8.9 w/ VxWorks).

The simplest case I have is the following...

   protected body Example_Protected_Object is

      entry Send when Available or
                                I_Am_Tired_Of_Waiting is
      begin

         -- Do some things here...

         -- reset the barrier flags
         Available := False;
         I_Am_Tired_Of_Waiting := False;

         -- reset the waiting flag
         Waiting_For_It := False;

      end Send;

      procedure Signal_Available is
      begin

         -- set the barrier flag to indicate data has been received
         Available := True;

      end Signal_Available;

      procedure Check_For_Timeout is
      begin

         -- set the barrier flag to indicate data has not been received
         I_Am_Tired_Of_Waiting := Waiting;

         -- set the waiting flag
         Waiting := True;

      end Check_For_Timeout;

   end Example_Protected_Object;


The entry (Send) is called from one task, to hold it until data arrives.

The procedure (Available) is called from a task that is triggered by an
interrupt.
The procedure (Check_For_Timeout) is called from the main program loop,
running at a lower priority than the other two tasks.

When everything is working normally, Available is called following the
interrupt processing and the queued call to Send is released from its
barrier. Check_For_Timeout is also periodically called by the main
program and as expected nothing happens.

When I prevent Available from being called however the system locks up.
This is not what I expected. I expected the call to Check_For_Timeout by
the main program to release the queued call to Send from its barrier.

Am I using the protected object correctly, or is something broken in the
Greenhills implementation of protected objects? I strongly suspect
Greenhills as I have read the LRM sections repeatedly and they seem to
say this should work and we were previously forced to convert all
protected object Interrupt Handlers to direct calls to VxWorks services
(bypassing the Ada implementation).

            R. Tim Coslet
            CosletT@KaiserE.com

Re: Protected Objects (Geeenhills & VxWorks)

[Tucker Taft]

"R. Tim Coslet" wrote:
> 
> We have been having repeated problems where Protected Objects don't seem
> to be functioning correctly in the environment we are working with
> (Greenhills V1.8.9 w/ VxWorks).
> 
> The simplest case I have is the following...

It would help if you included the source for the spec of the protected unit,
and the source for the main subprogram.  It is not clear who
sets the value of Waiting.  Also, can you be sure that the
main routine is actually calling Check_For_Timeout more than once?
Perhaps you could add some kind of trace calls into these routines
to document the order in which things are being called.

You should also certainly check with Green Hills.  I'm sure
they have a number of customers who are using protected
objects to handle interrupts on VxWorks.
In this case, it seems like the interrupt is irrelevant, since
you claim that you are testing the case when the interrupt does not
occur, and a timeout is supposed to take effect.

-Tucker Taft  stt@averstar.com
> 
>    protected body Example_Protected_Object is
> 
>       entry Send when Available or
>                                 I_Am_Tired_Of_Waiting is
>       begin
> 
>          -- Do some things here...
> 
>          -- reset the barrier flags
>          Available := False;
>          I_Am_Tired_Of_Waiting := False;
> 
>          -- reset the waiting flag
>          Waiting_For_It := False;
> 
>       end Send;
> 
>       procedure Signal_Available is
>       begin
> 
>          -- set the barrier flag to indicate data has been received
>          Available := True;
> 
>       end Signal_Available;
> 
>       procedure Check_For_Timeout is
>       begin
> 
>          -- set the barrier flag to indicate data has not been received
>          I_Am_Tired_Of_Waiting := Waiting;
> 
>          -- set the waiting flag
>          Waiting := True;
> 
>       end Check_For_Timeout;
> 
>    end Example_Protected_Object;
> 
> The entry (Send) is called from one task, to hold it until data arrives.
> 
> The procedure (Available) is called from a task that is triggered by an
> interrupt.
> The procedure (Check_For_Timeout) is called from the main program loop,
> running at a lower priority than the other two tasks.
> 
> When everything is working normally, Available is called following the
> interrupt processing and the queued call to Send is released from its
> barrier. Check_For_Timeout is also periodically called by the main
> program and as expected nothing happens.
> 
> When I prevent Available from being called however the system locks up.
> This is not what I expected. I expected the call to Check_For_Timeout by
> the main program to release the queued call to Send from its barrier.
> 
> Am I using the protected object correctly, or is something broken in the
> Greenhills implementation of protected objects? I strongly suspect
> Greenhills as I have read the LRM sections repeatedly and they seem to
> say this should work and we were previously forced to convert all
> protected object Interrupt Handlers to direct calls to VxWorks services
> (bypassing the Ada implementation).
> 
>             R. Tim Coslet
>             CosletT@KaiserE.com

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Protected Objects (Geeenhills & VxWorks)

[R. Tim Coslet]

I have verified the timeline of events using WindView when the program runs
successfully (I can't use WindView when it locks up... all I see then is that
the system is totally idle except for the VxWorks support interrupts and the
WindView support tasks).

The sequence is always:

1)    Main Loop calls Check_For_Timeout.
2)    Main Loop calls some other routines to activate the I/O channels.
3)    Main Loop calls the task entry for the I/O Processing task.
4)    The I/O Processing Task calls Send and is suspended by the barrier.
5)    Main Loop continues.
6)    About 2 ms later the interrupt arrives from the I/O channel.
7)    The Interrupt Task does its processing then calls Signal_Available.
8)    The barrier is removed and Send runs in the context of the Interrupt Task.

9)    The I/O Processing Task resumes and is suspended at its accept statement.

These events happen every 3rd cycle through the Main Loop (as designed).

I had expected (from what the LRM says) that if I prevented step 7 from
happening, then the processing in steps 8 and 9 would follow the call the
Check_For_Timeout in step 1 and Send would run in the context of the Main Loop
task.

                R. Tim Coslet

Re: Protected Objects (Geeenhills & VxWorks)

[R. Tim Coslet]

   protected type Example_Protected_Object is

      entry Send;

      procedure Signal_Available;

      procedure Check_For_Timeout;

   private

      Available       : Boolean := False;

      I_Am_Tired_Of_Waiting : Boolean := False;

      Waiting               : Boolean := False;

   end Example_Protected_Object;


The procedure Check_For_Timeout is actually getting called from a procedure that
is called by another procedure... (nested a few levels deep) inside the main
loop (which is in a task scheduled by another interrupt), not the main
subprogram. The scheduling logic of the main loop task calls Check_For_Timeout
just before making the call to an entry in the task that calls the entry Send,
every 3rd time the main loop runs. The intention of the call to
Check_For_Timeout is to make sure that that task has gotten out of the Send
entry of the protected object, so that it can accept another call and not queue
it, if the interrupt is missed (which in this system would indicate a serious
hardware malfunction).

The main subprogram in this system is only used for initialization. Once that is
complete it suspends itself (via a call to VxWorks) and all further processing
is done in tasks.

BTW, I have to test this by faking in software that the interrupt didn't occur
as the hardware always generates it, whether I want it or not :-)

Greenhills has been less than helpful on allot of things, and I thought that
this was basically an Ada95 usage question...

We have almost removed all protected objects and converted to code that directly
calls VxWorks (the guy that has been doing this says he would rather just
rewrite the ENTIRE program in C, because at least he can tell exactly what the
code is doing whereas Ada "does too many things that you have no control over").
This approach bothers me.

            R. Tim Coslet

Tucker Taft wrote:

> "R. Tim Coslet" wrote:
> >
> > We have been having repeated problems where Protected Objects don't seem
> > to be functioning correctly in the environment we are working with
> > (Greenhills V1.8.9 w/ VxWorks).
> >
> > The simplest case I have is the following...
>
> It would help if you included the source for the spec of the protected unit,
> and the source for the main subprogram.  It is not clear who
> sets the value of Waiting.  Also, can you be sure that the
> main routine is actually calling Check_For_Timeout more than once?
> Perhaps you could add some kind of trace calls into these routines
> to document the order in which things are being called.
>
> You should also certainly check with Green Hills.  I'm sure
> they have a number of customers who are using protected
> objects to handle interrupts on VxWorks.
> In this case, it seems like the interrupt is irrelevant, since
> you claim that you are testing the case when the interrupt does not
> occur, and a timeout is supposed to take effect.
>
> -Tucker Taft  stt@averstar.com
> >
> >    protected body Example_Protected_Object is
> >
> >       entry Send when Available or
> >                                 I_Am_Tired_Of_Waiting is
> >       begin
> >
> >          -- Do some things here...
> >
> >          -- reset the barrier flags
> >          Available := False;
> >          I_Am_Tired_Of_Waiting := False;
> >
> >          -- reset the waiting flag
> >          Waiting_For_It := False;
> >
> >       end Send;
> >
> >       procedure Signal_Available is
> >       begin
> >
> >          -- set the barrier flag to indicate data has been received
> >          Available := True;
> >
> >       end Signal_Available;
> >
> >       procedure Check_For_Timeout is
> >       begin
> >
> >          -- set the barrier flag to indicate data has not been received
> >          I_Am_Tired_Of_Waiting := Waiting;
> >
> >          -- set the waiting flag
> >          Waiting := True;
> >
> >       end Check_For_Timeout;
> >
> >    end Example_Protected_Object;
> >
> > The entry (Send) is called from one task, to hold it until data arrives.
> >
> > The procedure (Available) is called from a task that is triggered by an
> > interrupt.
> > The procedure (Check_For_Timeout) is called from the main program loop,
> > running at a lower priority than the other two tasks.
> >
> > When everything is working normally, Available is called following the
> > interrupt processing and the queued call to Send is released from its
> > barrier. Check_For_Timeout is also periodically called by the main
> > program and as expected nothing happens.
> >
> > When I prevent Available from being called however the system locks up.
> > This is not what I expected. I expected the call to Check_For_Timeout by
> > the main program to release the queued call to Send from its barrier.
> >
> > Am I using the protected object correctly, or is something broken in the
> > Greenhills implementation of protected objects? I strongly suspect
> > Greenhills as I have read the LRM sections repeatedly and they seem to
> > say this should work and we were previously forced to convert all
> > protected object Interrupt Handlers to direct calls to VxWorks services
> > (bypassing the Ada implementation).
> >
> >             R. Tim Coslet
> >             CosletT@KaiserE.com
>
> --
> -Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
> Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
> AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Protected Objects (Geeenhills & VxWorks)

[R. Tim Coslet]

Ooops!

            R. Tim Coslet

Tucker Taft wrote:

> It is not clear who sets the value of Waiting.

> >    protected body Example_Protected_Object is
> >
> >       entry Send when Available or
> >                                 I_Am_Tired_Of_Waiting is
> >       begin
> >
> >          -- Do some things here...
> >
> >          -- reset the barrier flags
> >          Available := False;
> >          I_Am_Tired_Of_Waiting := False;
> >
> >          -- reset the waiting flag
> >          Waiting_For_It := False;

My mistake. In cleaning out the code for this posting I didn't change this names
right.This should have read:

               -- reset the waiting flag
               Waiting := False;

> >
> >       end Send;
> >
> >       procedure Signal_Available is
> >       begin
> >
> >          -- set the barrier flag to indicate data has been received
> >          Available := True;
> >
> >       end Signal_Available;
> >
> >       procedure Check_For_Timeout is
> >       begin
> >
> >          -- set the barrier flag to indicate data has not been received
> >          I_Am_Tired_Of_Waiting := Waiting;
> >
> >          -- set the waiting flag
> >          Waiting := True;
> >
> >       end Check_For_Timeout;
> >
> >    end Example_Protected_Object;

Re: Protected Objects (Geeenhills & VxWorks)

[DuckE]

Suggestion:  Just for grins try the following minor restructing:


  protected type Example_Protected_Object is

    entry Send;
    procedure Signal_Available;
    procedure Check_For_Timeout;

  private

    Available : Boolean := False;
    I_Am_Tired_Of_Waiting : Boolean := False;
    Waiting : Boolean := False;
    CanSend : Boolean := False;
  end Example_Protected_Object;

  protected body Example_Protected_Object is

  entry Send when CanSend is
  begin

    -- Do some things here...

    -- reset the barrier flags
    Available := False;
    I_Am_Tired_Of_Waiting := False;

    -- reset the waiting flag
    Waiting := False;
    CanSend := Available or I_Am_Tired_Of_Waiting;
  end Send;

  procedure Signal_Available is
  begin

    -- set the barrier flag to indicate data has been received
    Available := True;
    CanSend := Available or I_Am_Tired_Of_Waiting;
  end Signal_Available;

  procedure Check_For_Timeout is
  begin

    -- set the barrier flag to indicate data has not been received
    I_Am_Tired_Of_Waiting := Waiting;

    -- set the waiting flag
    Waiting := True;
    CanSend := Available or I_Am_Tired_Of_Waiting;
  end Check_For_Timeout;

  end Example_Protected_Object;


The logic is exactly the same as what you had before, but the blocking
condition is a simple boolean.

I have found that in practice this makes things go more smoothly (not
to mention it makes the logic easier to follow).

I hope this helps.

SteveD

Re: Protected Objects (Geeenhills & VxWorks)

[R. Tim Coslet]

While I'd still like to know what is going wrong with what I had before, I
gave up on this approach.

I removed the Check_For_Timeout procedure and all the private variables
except Available. Then changed the call to the Send entry in the I/O
Processing Task to a Timed Entry Call (LRM section 9.7.2)... and
everything seems to work fine now.

DuckE wrote:

> Suggestion:  Just for grins try the following minor restructing:
>
>   protected type Example_Protected_Object is
>
>     entry Send;
>     procedure Signal_Available;
>     procedure Check_For_Timeout;
>
>   private
>
>     Available : Boolean := False;
>     I_Am_Tired_Of_Waiting : Boolean := False;
>     Waiting : Boolean := False;
>     CanSend : Boolean := False;
>   end Example_Protected_Object;
>
>   protected body Example_Protected_Object is
>
>   entry Send when CanSend is
>   begin
>
>     -- Do some things here...
>
>     -- reset the barrier flags
>     Available := False;
>     I_Am_Tired_Of_Waiting := False;
>
>     -- reset the waiting flag
>     Waiting := False;
>     CanSend := Available or I_Am_Tired_Of_Waiting;
>   end Send;
>
>   procedure Signal_Available is
>   begin
>
>     -- set the barrier flag to indicate data has been received
>     Available := True;
>     CanSend := Available or I_Am_Tired_Of_Waiting;
>   end Signal_Available;
>
>   procedure Check_For_Timeout is
>   begin
>
>     -- set the barrier flag to indicate data has not been received
>     I_Am_Tired_Of_Waiting := Waiting;
>
>     -- set the waiting flag
>     Waiting := True;
>     CanSend := Available or I_Am_Tired_Of_Waiting;
>   end Check_For_Timeout;
>
>   end Example_Protected_Object;
>
> The logic is exactly the same as what you had before, but the blocking
> condition is a simple boolean.
>
> I have found that in practice this makes things go more smoothly (not
> to mention it makes the logic easier to follow).
>
> I hope this helps.
>
> SteveD