* global rendezvou's
@ 1999-05-15 0:00 kumkwat
1999-06-05 0:00 ` Matthew Heaney
0 siblings, 1 reply; 3+ messages in thread
From: kumkwat @ 1999-05-15 0:00 UTC (permalink / raw)
HI
I was wondering if it was possible to have a entry call in a task that
was not only defined in multiple tasks but because it is then I
wouldn't have to specify the name of the task first before calling the
entry. Basically I don't want to call the entry on a specific task but
just tell everyone that I want to pass an object to the first thread
that calls an accept. I've got a way via a protected object as a
buffer but was wondering if I could circumvent that and just do it this
way.
e.g
task temp1 is
entry hello;
end temp1;
task temp2 is
entry hello;
end temp2;
-- somewhere in the main thread
hello;
-- and not temp1.hello; or temp2.hello;
Thanks
Jason
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: global rendezvou's
1999-05-15 0:00 global rendezvou's kumkwat
@ 1999-06-05 0:00 ` Matthew Heaney
1999-06-05 0:00 ` Nick Roberts
0 siblings, 1 reply; 3+ messages in thread
From: Matthew Heaney @ 1999-06-05 0:00 UTC (permalink / raw)
kumkwat@my-dejanews.com writes:
> I was wondering if it was possible to have a entry call in a task that
> was not only defined in multiple tasks but because it is then I
> wouldn't have to specify the name of the task first before calling the
> entry. Basically I don't want to call the entry on a specific task but
> just tell everyone that I want to pass an object to the first thread
> that calls an accept. I've got a way via a protected object as a
> buffer but was wondering if I could circumvent that and just do it this
> way.
If you want a broadcast feature, then you need to use a protected object
to implement a signal.
There are many examples of this in the ACM patterns archive; see the
dining philosophers series of articles.
<http://www.acm.org/archives/patterns.html>
> task temp1 is
> entry hello;
> end temp1;
>
> task temp2 is
> entry hello;
> end temp2;
>
>
> -- somewhere in the main thread
> hello;
>
> -- and not temp1.hello; or temp2.hello;
You sound like you know this, but here it goes:
protected Task_Initialization is
procedure Start;
entry Wait;
private
Started : Boolean := False;
end;
protected body Task_Initialization is
procedure Start is
begin
Started := True;
end;
entry Wait when Started is
begin
null;
end;
end;
task body Temp1 is
begin
Task_Initialization.Wait;
...
end;
task body Temp2 is
begin
Task_Initialization.Wait;
...
end;
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: global rendezvou's
1999-06-05 0:00 ` Matthew Heaney
@ 1999-06-05 0:00 ` Nick Roberts
0 siblings, 0 replies; 3+ messages in thread
From: Nick Roberts @ 1999-06-05 0:00 UTC (permalink / raw)
And if anyone is wondering why Ada is designed this way, it is (someone
correct me if I'm wrong) to do with implementation: the Ada rendezvous
mechanism (wherein the recipient is always specified by the sender) makes
for a particularly simple implementation, not requiring any chunks of memory
to be allocated for queue space (queues of waiting callers are simply
implemented by a having a 'waiting-link-through' pointer in each task's
descriptor).
-------------------------------------
Nick Roberts
http://www.adapower.com/lab/adaos
-------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1999-06-05 0:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-05-15 0:00 global rendezvou's kumkwat
1999-06-05 0:00 ` Matthew Heaney
1999-06-05 0:00 ` Nick Roberts
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox