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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,57893ac51069959a
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.190.99 with SMTP id gp3mr7306288pbc.1.1327394887588;
        Tue, 24 Jan 2012 00:48:07 -0800 (PST)
Path: 
 lh20ni218006pbb.0!nntp.google.com!news2.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!usenet-fr.net!gegeweb.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: "C - like: THIS" pointer to a task type inside a task function
Date: Tue, 24 Jan 2012 09:47:44 +0100
Organization: cbb software GmbH
Message-ID: <lk1ofkysw7d7.1n2uesvk2ad5m.dlg@40tude.net>
References: <19cglxkm60u91.1ezey0dra41do$.dlg@40tude.net>
 <jfkm8s$li5$1@speranza.aioe.org>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org
Mime-Version: 1.0
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: 2012-01-24T09:47:44+01:00
List-Id: <comp.lang.ada>

On Mon, 23 Jan 2012 22:17:00 +0000 (UTC), tmoran@acm.org wrote:

>> An entry can have in, out, in-out parameters like a subprogram call. You
>> can pass parameters in and get the results out, just in one call.
> 
>   If the client task, after giving work to the server, needs to do things
> other than wait for a result, then adding an "out" parameter won't work.

Yes, but that would not be a N-to-1 service then. The case you are
describing is rather N-to-M, when a task may queue several requests to 1..M
servers and later wait for completion of these requests as needed.

The solution of this problem is not in identifying the caller and then
engaging a rendezvous back to it, but rather the classical one: the request
is a proper ADT. The client task queues the requests which contain the
parameters and/or results. When the task needs the results it waits for the
request to complete.

   protected type Item_Of_Work is
 [    procedure Set_Parameters (...);  ]
      function Get_Result return ...;
      entry Wait_For_Completion;
 [    procedure/entry Cancel; -- Don't want this anymore  ]
   end Item_Of_Work;

   task type Server is
      entry Queue (Request : in out Item_Of_Work);
   end Server;

   ...
   Server_1.Queue (This);
   Server_2.Queue (That);
   ...
   This.Wait_For_Completion;
   
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de