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 Received: by 10.68.73.229 with SMTP id o5mr8408458pbv.7.1327430622014; Tue, 24 Jan 2012 10:43:42 -0800 (PST) Path: lh20ni219563pbb.0!nntp.google.com!news2.google.com!eweka.nl!feeder.eweka.nl!feeder.erje.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: "C - like: THIS" pointer to a task type inside a task function Date: Tue, 24 Jan 2012 19:43:35 +0100 Organization: cbb software GmbH Message-ID: References: <19cglxkm60u91.1ezey0dra41do$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: CNp+VBSYV+ysZXOiVRxJxw.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="iso-8859-1" Content-Transfer-Encoding: 8bit Date: 2012-01-24T19:43:35+01:00 List-Id: On Tue, 24 Jan 2012 09:12:03 -0800 (PST), Ada BRL wrote: > 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. >> >> � �T4.Send_Data (Data); >> � �accept Retrieve_Data (Data); >> >> is a patented way to run into a deadlock. >> > yes...you are right ... sorry ... =( 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, ...) OK. When you are working with sockets you normally do not need a dedicated output task. The network stack is already buffered and most likely asynchronous to the sender once you have initiated send. Thus you could consider sending data straight out of the server. Note also that unless you have a relatively small number of sockets to handle (a dozen or so), a task per socket doing blocking read would not scale. Tasks are used to read sockets simply because it is easier to program this way. If you have 2-3 sockets, why bother with asynchronous socket I/O? But you won't likely get a better performance in terms of data throughout and latencies with separate reader/writer tasks. Having one server engaging rendezvous with writers that would make this design even less reasonable. That is because you have the jobs *serialized* in the server. Writers will be either idle most of the time waiting for the server or else block server, which would want to make a rendezvous with a *concrete* writer each time. You would gain nothing from parallelism here, because serialization of processing is enforced by server, it only appears parallel. Unless there is some considerable post-processing in the writers, it would rather eat performance on meaningless task switching. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de