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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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 Received: by 10.68.223.136 with SMTP id qu8mr8106743pbc.3.1327425456529; Tue, 24 Jan 2012 09:17:36 -0800 (PST) Path: lh20ni219339pbb.0!nntp.google.com!news2.google.com!postnews.google.com!t7g2000vbg.googlegroups.com!not-for-mail From: Ada BRL Newsgroups: comp.lang.ada Subject: Re: "C - like: THIS" pointer to a task type inside a task function Date: Tue, 24 Jan 2012 09:12:03 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <19cglxkm60u91.1ezey0dra41do$.dlg@40tude.net> NNTP-Posting-Host: 164.11.203.58 Mime-Version: 1.0 X-Trace: posting.google.com 1327425456 29556 127.0.0.1 (24 Jan 2012 17:17:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 24 Jan 2012 17:17:36 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: t7g2000vbg.googlegroups.com; posting-host=164.11.203.58; posting-account=yig7mwoAAAAAcduNbH7Dpal1sjCSAijA User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUARELSCNK X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7,gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-01-24T09:12:03-08:00 List-Id: On 23 Gen, 19:59, "Dmitry A. Kazakov" wrote: > On Mon, 23 Jan 2012 11:32:39 -0800 (PST), Ada BRL wrote: > > I've N clients and one server that communicate each other. > > The N clients retrieve data dynamically, send it to the server throgh > > enrty call (obviously the server can accept just one call per time) > > and wait for the reply from the server (through accept statement). > > A server cannot wait for itself either "through accept statement" or any > other way. > > =A0 =A0T4.Send_Data (Data); > =A0 =A0accept Retrieve_Data (Data); > > is a patented way to run into a deadlock. > yes...you are right ... sorry ... =3D( BUT I MADE A MISTAKE!!! There are two tasks for every communication channel: - one performing input, so retrieving data from the net and sending it to the server (call it T1_IN, T2_IN, ...) - one performing output, so retrieving data from the server and sending it on the net (call it T1_OUT, T2_OUT, ...) > > For this reason the server needs to know on which client call the > > entry: > > That does not follow. Why do the server need to know the caller? The server has to call the right "output" according to the matching "input": received data from T2_IN, server has to send data to T2_OUT and not T1 or T3... > > > package P1 is > > > =A0 =A0task type T1 is > > =A0 =A0 =A0 =A0 =A0 =A0entry Retrieve_Data(Data : String); > > =A0 =A0entry Exchange_Data (Data : in out String); > > 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. > For the reasons above I cannot use in out. > > I think this is a quite common problem and so I'm optimistic to > > receive some useful replies! > > It is considered bad design when two components know each other. Usually > the software is designed in a way that component relationships are > asymmetric, e.g. the callee knows nothing about the caller. Component kno= ws > nothing about the container, etc. The advantage of this approach is its > robustness. You can have as many callers you need without changing the > callee. Imagine, that sine from the math library would have to be modifie= d > each time somebody writes a program calling it. For concurrency symmetric > relationships impose an additional risk of deadlocking. Thank you very much. > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de