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=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6d10b4841e4a643b
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2002-04-15 07:04:22 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: dennison@telepath.com (Ted Dennison)
Newsgroups: comp.lang.ada
Subject: Re: Are rendezvous dead?
Date: 15 Apr 2002 07:04:21 -0700
Organization: http://groups.google.com/
Message-ID: <4519e058.0204150604.2e65daca@posting.google.com>
References: <3CB940F7.4EC50CFD@yahoo.com>
NNTP-Posting-Host: 65.115.221.98
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1018879461 9582 127.0.0.1 (15 Apr 2002 14:04:21
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 15 Apr 2002 14:04:21 GMT
Xref: archiver1.google.com comp.lang.ada:22548
Date: 2002-04-15T14:04:21+00:00
List-Id: <comp.lang.ada>

Anatoly Chernyshev <rhezusfactor@yahoo.com> wrote in message news:<3CB940F7.4EC50CFD@yahoo.com>...
> The question is: are there any practical instances (in Ada 95) when use
> of rendezvous is more advantageous than of protected types? In other
> words, is it worhty of trying to write the code using only protected
> types and completely ignoring rendezvous as possible solution (like the
> GOTO operator)?

I personally find them complementary, not competative with each other.

What you can now do in Ada 95 is use tasks *only* for those entities
that logically contain their own thread of control, without having to
create a lot of extra fluff tasks.

In a multi-threaded algorithm you generally want to have each task
designated as either a client or a server. There are some exceptions,
but it is usually a very bad idea to make a task that tries to be
both.

So what do you do when, as often happens, you have two servers or two
clients that need to communicate with each other? The obvious solution
is to create a "gender-bender" task that does nothing but act as a
client or server and pass the data along. But a whole new task seems a
bit heavy of a solution for such a simple problem, does it not? In
Ada83 there was no other way, so Ada83 tasking programs tended to have
oodles of tasks. But in Ada 95, all you have to do is create a
protected "buffer" or "queue" to handle the communications.

That brings us to the other issue in Ada83 that caused task explosion:
task-safe data types. To do it right, you'd essentially need a
different task too coordinate synchronization for each and every data
object. In a fairly complex system, that could work out to oodles of
synchronization tasks. With protected objects, we no longer need those
sync tasks.

So as a design issue, I think one should generally do the following:

1) Identify the threads of control in your system.
2) Work out which need to be servers and which need to be clients.
3) Identify your server-server and client-client communications (which
you should try to minimise in step 2), and place buffers/queues
between them.
4) Use tasks with rendezvous to implement your servers and clients,
and protected types to implement all buffers, queues, and other
complex data types that are accessed by more than one task.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html