Question on using protected objects

Question on using protected objects

[DuckE]

Without getting into the details of what I'm leading up to, is the line
marked in the text
code snippet below a valid thing to do?

  SUBTYPE aWaitSelect IS INTEGER RANGE 1 .. 3;
  TYPE aWaitArray IS ARRAY( aWaitSelect ) OF BOOLEAN;

  PROTECTED TYPE aQueueingType IS
    ENTRY GetEntry( waitSelect  : aWaitSelect; getResult : out Integer );
    PROCEDURE Release( waitSelect  : aWaitSelect );
  PRIVATE
    ENTRY WaitForIt( aWaitSelect );
    waitFlag : aWaitArray := ( OTHERS => FALSE );
    counter  : Natural := 0;
  END aQueueingType;

  PROTECTED BODY aQueueingType IS
    PROCEDURE Release( waitSelect : aWaitSelect ) IS
    BEGIN
      waitFlag( waitSelect  ) := TRUE;
    END Release;
    ENTRY GetEntry( waitSelect : aWaitSelect;
                     getResult : out Integer ) WHEN GetEntry'COUNT = 0 IS
    BEGIN
      getResult := counter;
      counter := counter + 1;
      REQUEUE WaitForIt( waitSelect );
    END GetEntry;
    ENTRY WaitForIt ( FOR waitSelect IN aWaitSelect )
         WHEN waitFlag( waitSelect ) IS  -- <<<<<<<<<<<< is it OK to use
waitSelect here???
    BEGIN
      waitFlag( waitSelect ) := FALSE;
    END WaitForIt;
  END aQueueingType;


Thanks in advance,
SteveD

Re: Question on using protected objects

[Jeffrey Carter]

What does your compiler say? (Hint: I suggest using GNAT with the -gnaty
option.)

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail

Re: Question on using protected objects

[DuckE]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3BB56747.D60CA49F@acm.org...
> What does your compiler say? (Hint: I suggest using GNAT with the -gnaty
> option.)

The compiler is perfectly happy with this.  It even "appears" to do exactly
what I want.  If I were programming in C, that's as far as I would go before
using this construct.  In Ada I try to avoid the "try it and see if it
works" mode of operation since it sometimes leads to unpredictable results.

Here is the complete test program that "appears" do do exactly what I want,
I just don't know whether it is appropriate to use the "defining_identifier"
as part of the "entry_barrier" (LRM 9.5.2):

WITH Ada.Text_Io;

PROCEDURE TestProtType IS

  nbWaiters : CONSTANT := 4;

  SUBTYPE aWaitSelect IS INTEGER RANGE 1 .. nbWaiters;

  TYPE aWaitArray IS ARRAY( aWaitSelect ) OF BOOLEAN;

  PROTECTED TYPE aQueueingType IS
    ENTRY GetEntry( waitSelect  : aWaitSelect; getResult : out Integer );
    PROCEDURE Release( waitSelect  : aWaitSelect );
  PRIVATE
    ENTRY WaitForIt( aWaitSelect );
    waitFlag : aWaitArray := ( OTHERS => FALSE );
    counter  : Natural := 0;
  END aQueueingType;

  PROTECTED BODY aQueueingType IS
    PROCEDURE Release( waitSelect : aWaitSelect ) IS
    BEGIN
      waitFlag( waitSelect  ) := TRUE;
    END Release;
    ENTRY GetEntry( waitSelect : aWaitSelect;
                     getResult : out Integer ) WHEN GetEntry'COUNT = 0 IS
    BEGIN
      getResult := counter;
      counter := counter + 1;
      REQUEUE WaitForIt( waitSelect );
    END GetEntry;
    ENTRY WaitForIt ( FOR waitSelect IN aWaitSelect )
         WHEN waitFlag( waitSelect ) IS
    BEGIN
      waitFlag( waitSelect ) := FALSE;
    END WaitForIt;
  END aQueueingType;

  qFlag : aQueueingType;

  TASK TYPE aWaiter( waitSelect : aWaitSelect ) IS
  END aWaiter;

  TASK BODY aWaiter IS
    getResult : Integer;
  BEGIN
    qFlag.GetEntry( waitSelect, getResult );
    Ada.Text_Io.Put_Line( "Waiter " &
                          aWaitSelect'IMAGE(waitSelect) &
                          ", " & Integer'IMAGE( getResult ) &
                          " released!" );
  END aWaiter;

  TYPE aWaiterPtr IS ACCESS ALL aWaiter;
  nbWaitTasks : CONSTANT := 3;

BEGIN
  FOR lpCnt IN 1 .. nbWaitTasks LOOP
    FOR ii IN aWaitSelect'RANGE LOOP
      DECLARE
        waitPtr : aWaiterPtr;
      BEGIN
        waitPtr := NEW aWaiter( ii );
      END;
    END LOOP;
  END LOOP;
  FOR lpCnt IN 1 .. nbWaitTasks LOOP
    FOR ii IN aWaitSelect'RANGE LOOP
      DELAY 1.0;
      qFlag.Release( ii );
    END LOOP;
  END LOOP;
  DELAY 1.0;
END TestProtType;

>
> --
> Jeff Carter
> "You cheesy lot of second-hand electric donkey-bottom biters."
> Monty Python & the Holy Grail

Re: Question on using protected objects

[Jeff Creem]

"DuckE" <nospam_steved94@home.com> wrote in message
news:C9jt7.52545$QK.35535895@news1.sttln1.wa.home.com...
> "Jeffrey Carter" <jrcarter@acm.org> wrote in message
> news:3BB56747.D60CA49F@acm.org...
> > What does your compiler say? (Hint: I suggest using GNAT with the -gnaty
> > option.)
>
> The compiler is perfectly happy with this.  It even "appears" to do
exactly
> what I want.  If I were programming in C, that's as far as I would go
before
> using this construct.  In Ada I try to avoid the "try it and see if it
> works" mode of operation since it sometimes leads to unpredictable
results.


That is the strangest statement I ever heard. To summarize ... If you were
using
a language where the compiler checks less at compile time and is less able
to
tell you at run time about problems you are ?MORE? inclined to stop after a
clean
compile and a run that appears to work?

Re: Question on using protected objects

[DuckE]

"Jeff Creem" <jeff@thecreems.com> wrote in message
news:GMkt7.44297$vq.9196633@typhoon.ne.mediaone.net...
>
> "DuckE" <nospam_steved94@home.com> wrote in message
> news:C9jt7.52545$QK.35535895@news1.sttln1.wa.home.com...
> > "Jeffrey Carter" <jrcarter@acm.org> wrote in message
> > news:3BB56747.D60CA49F@acm.org...
> > > What does your compiler say? (Hint: I suggest using GNAT with
the -gnaty
> > > option.)
> >
> > The compiler is perfectly happy with this.  It even "appears" to do
exactly
> > what I want.  If I were programming in C, that's as far as I would go
before
> > using this construct.  In Ada I try to avoid the "try it and see if it
> > works" mode of operation since it sometimes leads to unpredictable
> results.
>
>
> That is the strangest statement I ever heard. To summarize ... If you were
using
> a language where the compiler checks less at compile time and is less able
to
> tell you at run time about problems you are ?MORE? inclined to stop after
a clean
> compile and a run that appears to work?
>

My experience in C is that things are often not well defined.  When I try
something
in C, I don't expect that if it works in my test it will work the same for
different
compilers.  In Ada my expectations are higher.  In Ada I expect that if I
"play by
the rules" my source code will work across multiple compilers on multiple
targets.
  Just because some code is accepted by one compiler, it doesn't mean it
will be
accepted by all compilers.

In Ada (as well as in most other programming languages), if you give the
compiler
correct source code it will give you correct executables.  If you give the
compiler
bad source code the result is undefined.  In my experience Ada catches many
more
problems in source code at compile time than other languages, but in some
cases
you can still generate an executable from bad code.

For example bad source code might print a string that has not been
initialized.  The
results depend on many factors.

SteveD

Re: Question on using protected objects

[Ehud Lamm]

In a nutshell: You can NOT use an entry parameter inside the barrier
condition, but you CAN use the entry index specification of an entry family.

Ehud

Re: Question on using protected objects

[Tucker Taft]

DuckE wrote:

> Without getting into the details of what I'm leading up to, is the line
> marked in the text
> code snippet below a valid thing to do?

Yes.

Is there a reason you thought it might be illegal?

It compiles cleanly in my favorite compiler.

I presume you might be wondering whether you can
use the entry family index in an entry barrier.  The
answer is definitely.  An entry family is like an array
of entries, and each has its own entry queue, and may
hence have an entry barrier expression that differs
according to the entry family index.

Normal entries are not allowed to reference their "normal"
parameters in the entry barrier expression because there is
only one entry queue, and the entry barrier applies to the
queue as a whole, not individual calls on the entry.
The parameters of course depend on individual calls.

-Tucker Taft  stt@avercom.net


>
>
>   SUBTYPE aWaitSelect IS INTEGER RANGE 1 .. 3;
>   TYPE aWaitArray IS ARRAY( aWaitSelect ) OF BOOLEAN;
>
>   PROTECTED TYPE aQueueingType IS
>     ENTRY GetEntry( waitSelect  : aWaitSelect; getResult : out Integer );
>     PROCEDURE Release( waitSelect  : aWaitSelect );
>   PRIVATE
>     ENTRY WaitForIt( aWaitSelect );
>     waitFlag : aWaitArray := ( OTHERS => FALSE );
>     counter  : Natural := 0;
>   END aQueueingType;
>
>   PROTECTED BODY aQueueingType IS
>     PROCEDURE Release( waitSelect : aWaitSelect ) IS
>     BEGIN
>       waitFlag( waitSelect  ) := TRUE;
>     END Release;
>     ENTRY GetEntry( waitSelect : aWaitSelect;
>                      getResult : out Integer ) WHEN GetEntry'COUNT = 0 IS
>     BEGIN
>       getResult := counter;
>       counter := counter + 1;
>       REQUEUE WaitForIt( waitSelect );
>     END GetEntry;
>     ENTRY WaitForIt ( FOR waitSelect IN aWaitSelect )
>          WHEN waitFlag( waitSelect ) IS  -- <<<<<<<<<<<< is it OK to use
> waitSelect here???
>     BEGIN
>       waitFlag( waitSelect ) := FALSE;
>     END WaitForIt;
>   END aQueueingType;
>
> Thanks in advance,
> SteveD

Re: Question on using protected objects

[DuckE]

"Tucker Taft" <stt@avercom.net> wrote in message
news:3BB604E6.684884D9@avercom.net...
>
[snip]
> I presume you might be wondering whether you can
> use the entry family index in an entry barrier.  The
> answer is definitely.  An entry family is like an array
> of entries, and each has its own entry queue, and may
> hence have an entry barrier expression that differs
> according to the entry family index.

Yes, that is EXACTLY what I was wondering.  Thank you for clearing that up
for me.

SteveD

>
> Normal entries are not allowed to reference their "normal"
> parameters in the entry barrier expression because there is
> only one entry queue, and the entry barrier applies to the
> queue as a whole, not individual calls on the entry.
> The parameters of course depend on individual calls.
>
> -Tucker Taft  stt@avercom.net
>
>