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 qu8mr8131311pbc.3.1327426152878; Tue, 24 Jan 2012 09:29:12 -0800 (PST) Path: lh20ni219367pbb.0!nntp.google.com!news2.google.com!postnews.google.com!i25g2000vbt.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:27:17 -0800 (PST) Organization: http://groups.google.com Message-ID: <3bf5a198-61ae-4c6d-82fb-5ff3fbf42326@i25g2000vbt.googlegroups.com> References: <19cglxkm60u91.1ezey0dra41do$.dlg@40tude.net> NNTP-Posting-Host: 164.11.203.58 Mime-Version: 1.0 X-Trace: posting.google.com 1327426152 3969 127.0.0.1 (24 Jan 2012 17:29:12 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 24 Jan 2012 17:29:12 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i25g2000vbt.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:27:17-08:00 List-Id: I have already inserted a post but it isn't visualized yet... 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); > I made a mistake, sorry ... :-( I have two tasks for every channel of communication: - input task: retrieves data from the net and send it to the server (call it Ti_IN), - output task: receives data from the server and send it on the net (call it Ti_OUT). For this reason I need: 1) to know who's sending data to the server --> I've already implemented it with "in" parameter, 2) have a reference to the output threads, in order to call every time the entry of the correct thread. For example: T2_IN calls Server.Send_Data(Data, 2); Inside the server I have to call T2_OUT.Retrieve_Data(Data); and NOT the entry on T1_OUT or T3_OUT. So the entry Retrieve_Data is implemented only by the _OUT tasks. > is a patented way to run into a deadlock. I recognize you are definitely true :-)! > > > 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? > > > 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. > > > 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. > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de Thank you very much and sorry for the mistake....but yesterday I have been programming for lots of hours without any rest...