* Two-Way Task Communication In Ada (w/o Protected Objects)
@ 1996-11-25 0:00 ericferg
1996-11-27 0:00 ` Stephen Leake
1996-11-27 0:00 ` Paul Chardon
0 siblings, 2 replies; 4+ messages in thread
From: ericferg @ 1996-11-25 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Two-Way Task Communication In Ada (w/o Protected Objects)
1996-11-25 0:00 Two-Way Task Communication In Ada (w/o Protected Objects) ericferg
1996-11-27 0:00 ` Stephen Leake
@ 1996-11-27 0:00 ` Paul Chardon
1 sibling, 0 replies; 4+ messages in thread
From: Paul Chardon @ 1996-11-27 0:00 UTC (permalink / raw)
To: ericferg
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Two-Way Task Communication In Ada (w/o Protected Objects)
1996-11-25 0:00 Two-Way Task Communication In Ada (w/o Protected Objects) ericferg
@ 1996-11-27 0:00 ` Stephen Leake
1996-11-27 0:00 ` Paul Chardon
1 sibling, 0 replies; 4+ messages in thread
From: Stephen Leake @ 1996-11-27 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Two-Way Task Communication In Ada (w/o Protected Objects)
@ 1996-11-27 0:00 W. Wesley Groleau (Wes)
0 siblings, 0 replies; 4+ messages in thread
From: W. Wesley Groleau (Wes) @ 1996-11-27 0:00 UTC (permalink / raw)
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
---------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1996-11-27 0:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-11-25 0:00 Two-Way Task Communication In Ada (w/o Protected Objects) ericferg
1996-11-27 0:00 ` Stephen Leake
1996-11-27 0:00 ` Paul Chardon
-- strict thread matches above, loose matches on Subject: below --
1996-11-27 0:00 W. Wesley Groleau (Wes)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox