From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 14 Oct 2014 18:49:08 -0500
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Newsgroups: comp.lang.ada
Subject: Re: passing messages between the tasks
Date: Tue, 14 Oct 2014 19:49:10 -0400
Organization: IISS Elusive Unicorn
Message-ID: <jrcr3ah1osn5gktan2tn41c2css9ekofn1@4ax.com>
References: <b7a2745e-a0df-400b-a057-828473919fee@googlegroups.com>
 <41154c4b-6158-4701-ab25-85afa3b24ed2@googlegroups.com>
 <X1f%v.438333$1s.413373@fx05.iad> <m1k1sc$v8k$1@dont-email.me>
 <9fa74920-0bb1-49d4-93ac-f781529f0c98@googlegroups.com>
X-Newsreader: Forte Agent 6.00/32.1186
X-No-Archive: YES
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 108.68.178.170
X-Trace: 
 sv3-HP7u69ueGkt2GhrYhAAZBRcs1qr5R+LTPGyU9Rw4BR7Tu4qJjLaEbPNnbpnu1TQ3bQIG03JKYG1i99X!t/xJNNaW8DqaeVrjO32c0aN8ENdhc5LZBHNpbIs7Gl+jKu6xVyAgXFzfnIoSABA7dUYF/+2Hiocb!jjNFNbIqcpwbW9N1YGeX+P6CR5x5
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2976
Xref: news.eternal-september.org comp.lang.ada:22485
Date: 2014-10-14T19:49:10-04:00
List-Id: <comp.lang.ada>

On Tue, 14 Oct 2014 14:08:08 -0700 (PDT), compguy45@gmail.com declaimed the
following:

> 15       accept reset(id : Integer) do

> 23
> 24 begin
> 25    lamps(1).reset(id => 1);

	Note that this scheme has nothing that prevents one doing

	lamps(1).reset(id => 3);

	You'd be better off with something where the tasks first wait for an
initialization rendezvous. (PSEUDO_CODE)

	for i in lamps'range loop
		lamp(i).init(id => i);
	end loop;

	Then later you rendezvous on your reset with just

	lamp(1).reset;

as the lamp(1) task already knows its id from the init() point.

>I am trying to figure out how to do following....have say main tasks call reset on say lamps(3).reset....
>Then lamp(3) would call reset on lamps(2) and lamps(1) and wait....then someone lamps(2) and lamps(1) when they done with reset would somehow let lamp(3) know about it....Is this possible to do...?

	You need to develop a data structure of some sort in which you TELL
each task which tasks are subordinate to it... Which likely means using
access to task.

	And a rendezvous doesn't continue until the accept block exits, so if
all action takes place in the accepts there is no explicit need to wait.

	accept reset do
		subordinate(1).reset;
		subordinate(2).reset;
	end reset;

Whereas if you had

	accept reset do
		Null;
	end reset;
	subordinate(1).reset;
	subordinate(2).reset;

the task would wait for a reset invocation, but the rendezvous would end,
letting the invoker continue -- and then would do the subordinate task
resets.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/