Need a Sanity Check

Need a Sanity Check

[autstspe]

Hello.  I'm seeing some strange behavior from an Ada95 program.  I've
spoken to several people I work with and we all agree it should not
behave the way it does.  Its a simple program so I was wondering if
someone could take a look at the following an tell me what the output
should be.  It should take just a minute.  Unfortunately, due to
restrictions, I can't say much more. Thanks.

==========================================================================
package T123_Pack is

   task type  Three_Entries_Type is
     entry Start ;
     entry One ;
     entry Two ;
     entry Three ;
   end Three_Entries_Type ;

   Three_Entries : Three_Entries_Type ;

   procedure Start ;

end T123_Pack ;
--------------------------------------
with Text_Io ;
package body T123_Pack is

   task body Three_Entries_Type is

   begin

        accept Start ;

          Text_Io.Put_Line("Start");

        loop

        select

          accept One do

           Text_Io.Put_Line("One");

          end ;

        or

          accept Two do

           Text_Io.Put_Line("Two");

          end ;

        or

          accept Three do

           Text_Io.Put_Line("Three");

          end ;

          loop
             null ;
             delay(0.02);
          end loop ;

        end select ; -- select

       end loop ;

  end Three_Entries_Type ;

  procedure Start is

          begin
               Three_Entries.Start ;
          end ;

end T123_Pack ;

--------------------------------------
-- main procedure
--------------------------------------
with T123_Pack ;

procedure T123 is

begin

   T123_Pack.Three_Entries.Start ;
   T123_Pack.Three_Entries.Three ;
   T123_Pack.Three_Entries.One ;

   loop
         T123_Pack.Three_Entries.Three ;
         T123_Pack.Three_Entries.Two ;
         delay(0.02) ;
   end loop ;

end T123 ;

Re: Need a Sanity Check

[Jeffrey Carter]

autstspe wrote:

> Hello.  I'm seeing some strange behavior from an Ada95 program.  I've
> spoken to several people I work with and we all agree it should not
> behave the way it does.  Its a simple program so I was wondering if
> someone could take a look at the following an tell me what the output
> should be.  It should take just a minute.  Unfortunately, due to
> restrictions, I can't say much more. Thanks.
> 
> ==========================================================================
> package T123_Pack is
> 
>    task type  Three_Entries_Type is
>      entry Start ;
>      entry One ;
>      entry Two ;
>      entry Three ;
>    end Three_Entries_Type ;
> 
>    Three_Entries : Three_Entries_Type ;
> 
>    procedure Start ;
> 
> end T123_Pack ;
> --------------------------------------
> with Text_Io ;
> package body T123_Pack is
> 
>    task body Three_Entries_Type is
> 
>    begin
> 
>         accept Start ;
> 
>           Text_Io.Put_Line("Start");
> 
>         loop
> 
>         select
> 
>           accept One do
> 
>            Text_Io.Put_Line("One");
> 
>           end ;
> 
>         or
> 
>           accept Two do
> 
>            Text_Io.Put_Line("Two");
> 
>           end ;
> 
>         or
> 
>           accept Three do
> 
>            Text_Io.Put_Line("Three");
> 
>           end ;
> 
>           loop
>              null ;
>              delay(0.02);
>           end loop ;
> 
>         end select ; -- select
> 
>        end loop ;
> 
>   end Three_Entries_Type ;
> 
>   procedure Start is
> 
>           begin
>                Three_Entries.Start ;
>           end ;
> 
> end T123_Pack ;
> 
> --------------------------------------
> -- main procedure
> --------------------------------------
> with T123_Pack ;
> 
> procedure T123 is
> 
> begin
> 
>    T123_Pack.Three_Entries.Start ;
>    T123_Pack.Three_Entries.Three ;
>    T123_Pack.Three_Entries.One ;
> 
>    loop
>          T123_Pack.Three_Entries.Three ;
>          T123_Pack.Three_Entries.Two ;
>          delay(0.02) ;
>    end loop ;
> 
> end T123 ;

Your task will accept Start and output "Start". Then it will accept 
Three and output "Three". Then it goes into an infinite loop. Meanwhile, 
your main procedure is waiting for the task to accept One. The 
consequences should be obvious.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: Need a Sanity Check

[autstspe]

Thanks, that's what we all think.  Of course, that's not whats
happening.  The kernel appears to have a bug in it.

Re: Need a Sanity Check

[Steve]

I believe the output you get from this program is dependent on the runtimes 
implementation of Text_IO.

The old ARM 9.5.1:
  During a protected action, it is a bounded error to invoke an operation 
that is potentially blocking.  The following are defined to be potientially 
blocking operations:

  an accept_statement

  a call on a subprogram whose body contains a potnentially blocking 
operation.

I believe the calls to Text_IO may be potentially blocking.  A language 
lawyer may be able to help with this.

To get away from this restriction you might see if changing the source from:

  accept Three do
    Text_Io.Put_Line( "Three" );
  end;

To:

  accept Three do
    null;
  end;
  Text_Io.Put_Line( "Three" );

Or just

   accept Three;
   Text_Io.Put_Line( "Three" );

to see if this changes the behavior.

Whether it is right or wrong, I have a note in my mind to only do simple 
things like copying data inside of an accept statement.

Steve
(The Duck)


"autstspe" <ati@san.rr.com> wrote in message 
news:1115772555.000422.205200@f14g2000cwb.googlegroups.com...
> Hello.  I'm seeing some strange behavior from an Ada95 program.  I've
> spoken to several people I work with and we all agree it should not
> behave the way it does.  Its a simple program so I was wondering if
> someone could take a look at the following an tell me what the output
> should be.  It should take just a minute.  Unfortunately, due to
> restrictions, I can't say much more. Thanks.
>
> ==========================================================================
> package T123_Pack is
>
>   task type  Three_Entries_Type is
>     entry Start ;
>     entry One ;
>     entry Two ;
>     entry Three ;
>   end Three_Entries_Type ;
>
>   Three_Entries : Three_Entries_Type ;
>
>   procedure Start ;
>
> end T123_Pack ;
> --------------------------------------
> with Text_Io ;
> package body T123_Pack is
>
>   task body Three_Entries_Type is
>
>   begin
>
>        accept Start ;
>
>          Text_Io.Put_Line("Start");
>
>        loop
>
>        select
>
>          accept One do
>
>           Text_Io.Put_Line("One");
>
>          end ;
>
>        or
>
>          accept Two do
>
>           Text_Io.Put_Line("Two");
>
>          end ;
>
>        or
>
>          accept Three do
>
>           Text_Io.Put_Line("Three");
>
>          end ;
>
>          loop
>             null ;
>             delay(0.02);
>          end loop ;
>
>        end select ; -- select
>
>       end loop ;
>
>  end Three_Entries_Type ;
>
>  procedure Start is
>
>          begin
>               Three_Entries.Start ;
>          end ;
>
> end T123_Pack ;
>
> --------------------------------------
> -- main procedure
> --------------------------------------
> with T123_Pack ;
>
> procedure T123 is
>
> begin
>
>   T123_Pack.Three_Entries.Start ;
>   T123_Pack.Three_Entries.Three ;
>   T123_Pack.Three_Entries.One ;
>
>   loop
>         T123_Pack.Three_Entries.Three ;
>         T123_Pack.Three_Entries.Two ;
>         delay(0.02) ;
>   end loop ;
>
> end T123 ;
> 

Re: Need a Sanity Check

[Jean-Pierre Rosen]

Steve a �crit :
> I believe the output you get from this program is dependent on the runtimes 
> implementation of Text_IO.
> 
> The old ARM 9.5.1:
>   During a protected action, it is a bounded error to invoke an operation 
> that is potentially blocking.  The following are defined to be potientially 
> blocking operations:

An accept statement is a potentially blocking operation, but it is *not* 
a protected operation, therefore it is safe to call Text_IO from within 
an accept statement (but an accept statement cannot be called from 
within a protected subprogram or entry).

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Need a Sanity Check

[mark]

"(but an accept statement cannot be called from within a protected
subprogram or entry)."

Is that a language restriction?  Compiling using GNAT I get -

     warning: potentially blocking operation in protected operation

when calling another tasks entry point from within a protected entry.
I'm sure its not going to block based on the task it is calling has a
single accept and is only called from this protected entry.   The task
called does nothing special besides dump a buffer to disk.  Doing it
this way just decouples the disk write from the rest of the system.

So, is GNAT not enforcing language standards or is that really not part
of the standard?

Re: Need a Sanity Check

[Randy Brukardt]

"mark" <ati@san.rr.com> wrote in message
news:1116619695.361267.218380@g49g2000cwa.googlegroups.com...
> "(but an accept statement cannot be called from within a protected
> subprogram or entry)."
>
> Is that a language restriction?  Compiling using GNAT I get -
>
>      warning: potentially blocking operation in protected operation
>
> when calling another tasks entry point from within a protected entry.
> I'm sure its not going to block based on the task it is calling has a
> single accept and is only called from this protected entry.   The task
> called does nothing special besides dump a buffer to disk.  Doing it
> this way just decouples the disk write from the rest of the system.
>
> So, is GNAT not enforcing language standards or is that really not part
> of the standard?

It's a bounded error, meaning that it either raises Program_Error or goes
forward (which might cause deadlock). In any case, it is not checked at
compile-time (because you could call anything from a protected object). And
even if it works on a specific compiler, it's not portable; another compiler
might raise Program_Error. Note that Ada 2006 adds a pragma Detect_Blocking,
which changes this to a requirement to raise Program_Error. (That's part of
Ravenscar, but I generally recommend it to everyone, because it makes the
behavior predictable.)

                           Randy.