Two-Way Task Communication In Ada (w/o Protected Objects)

Two-Way Task Communication In Ada (w/o Protected Objects)

[ericferg]

In a message dated 96-11-24 20:15:03 EST, blaak@mda.ca writes:

<< Two way communication with peers can be done by using a protected
object. Just
 pretty it up with Send/Receive operations (make a Channel abstraction)
and have
 the tasks work with a channel object to communicate.
  >>

Thanks for the info.  Though I didn't mention it, I was actually trying to
AVOID  intermediate protected objects between the tasks (which would act
as shared "dequeues" or "argument buffers" ... the "Channel abstraction"
you mention).

Would anyone happen to know of any way to position or structure Ada task
declarations such that two tasks will have visibility of each other, and
may _directly_ invoke each other's entries (and thus provide for direct,
two way message & argument passing, without the use of intermediate
argument buffers)?

If so, please post a reply or e-mail me at EricFerg@aol.com

Thanks once again, blaak@mda.ca, for your response!

Eric Ferguson

Re: Two-Way Task Communication In Ada (w/o Protected Objects)

[W. Wesley Groleau (Wes)]

I don't recommend this, but if you MUST have two tasks communicating
WITHOUT any intermediates, here's an example:

task Guru is
  entry Listen ( Question : String );
end Guru;

task Novice is
  entry Listen ( Answer : String );
end Novice;

task body Novice is
begin
  Exist:
    loop
      Experiment;
      Scratch_Head;
      Guru.Listen ( Question => "Why does this happen?" );
      Do_Something_Else_While_The_Guru_Thinks;
      accept Listen ( Answer : String ) do
        Parse_Unconstrained_String_Somehow;
      end Listen;
      Scratch_Head;
    end loop Exist;
end Novice;

task body Guru is
begin
  Exist:
    loop
      select
        accept Listen ( Question : String ) do
          Store_Unconstrained_String;
        end Listen;
      else
        Meditate;
        if I_Feel_Like_Speaking then
          if Question_Is_Stored then
             Novice.Listen ( Answer => Incomprehensible_Remark
                                       ( Based_On => Unconstrained_String ) );
          else
             Novice.Listen ( Answer => Incomprehensible_Remark );
          end if;
        end if;
        Meditate;
      end select;
    end loop Exist;
end Guru;

--------

Why is it not recommended?  Well, it may very well run, but then again,
you may very well have Novice waiting for Guru to Listen to its Question
and AT THE SAME TIME have Guru waiting for Novice to Listen to its
(possibly unsolicited) Answer.  Reversing the direction of one rendezvous
(i.e., putting the accept on the other side) will not change this.

There are tricks like time-outs and such that will prevent deadlock,
but.... one step at a time ....

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Senior Software Engineer - AFATDS                         FAX: 219-429-5194
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
1010 Production Road                          (Mac): wwgrol@most.fw.hac.com
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Two-Way Task Communication In Ada (w/o Protected Objects)

[Paul Chardon]

ericferg@aol.com wrote:
> 
> In a message dated 96-11-24 20:15:03 EST, blaak@mda.ca writes:
> 
> << Two way communication with peers can be done by using a protected
> object. Just
>  pretty it up with Send/Receive operations (make a Channel abstraction)
> and have
>  the tasks work with a channel object to communicate.
>   >>
> 
> Thanks for the info.  Though I didn't mention it, I was actually trying to
> AVOID  intermediate protected objects between the tasks (which would act
> as shared "dequeues" or "argument buffers" ... the "Channel abstraction"
> you mention).
> 
> Would anyone happen to know of any way to position or structure Ada task
> declarations such that two tasks will have visibility of each other, and
> may _directly_ invoke each other's entries (and thus provide for direct,
> two way message & argument passing, without the use of intermediate
> argument buffers)?
> 
> If so, please post a reply or e-mail me at EricFerg@aol.com
> 
> Thanks once again, blaak@mda.ca, for your response!
> 
> Eric Ferguson

A way to do that is offer by the structure of specification and body.
You can then build such compilations units :
-----------------------
Task A is
	entry entry_A;
end A;
-----------------------
Task B is
	entry entry_B;
end B;
-----------------------
with A;
Task body B is
begin
	...
	A.entry_A;
end B;
-----------------------
with B;
Task body A is
begin
	...
	B.entry_B;
end A;	
-----------------------

I hope it is what you mean. If not, I've buid a data structure in Ada95
with a tagged type and a task in order to make visibility possible
between two objects without to use the dependency between body and spec.

	Bye, Paul.

Re: Two-Way Task Communication In Ada (w/o Protected Objects)

[Stephen Leake]

ericferg@aol.com wrote:
> 
> [snip]

> Would anyone happen to know of any way to position or structure Ada task
> declarations such that two tasks will have visibility of each other, and
> may _directly_ invoke each other's entries (and thus provide for direct,
> two way message & argument passing, without the use of intermediate
> argument buffers)?
> 

This compiles with gnat 3.04 :

procedure Example is

   task Don is
      entry One_Side;
   end Don;

   task Mclean is
      entry Another_Side;
   end Mclean;

   task body Don is
   begin
      accept One_Side
      do
         Mclean.Another_Side;
      end One_Side;

   end Don;

   task body Mclean is
   begin
      accept Another_Side;

      Don.One_Side;
   end;

begin

   Don.One_Side;
end Example;

Clearly this example does no real work :-). Perhaps you want the two
tasks to be in separate packages? Then the bodies can still reference
each other.

-- 
- Stephe