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 o5mr10450829pbv.7.1327499346728; Wed, 25 Jan 2012 05:49:06 -0800 (PST) Path: lh20ni222520pbb.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!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: Wed, 25 Jan 2012 14:48:36 +0100 Organization: cbb software GmbH Message-ID: <1rp216zwnjx3j$.rjwu8m3hxgp1.dlg@40tude.net> References: <19cglxkm60u91.1ezey0dra41do$.dlg@40tude.net> <2c51ce87-87ef-438c-bec5-e3b8114f0471@cf6g2000vbb.googlegroups.com> 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="iso-8859-1" Content-Transfer-Encoding: 8bit Date: 2012-01-25T14:48:36+01:00 List-Id: On Wed, 25 Jan 2012 04:43:57 -0800 (PST), Ada BRL wrote: > On 24 Gen, 18:43, "Dmitry A. Kazakov" > wrote: >> 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. > > So, please tell me if I'm right, the server has to implement inside > itself the N output socket connections and I just need to have N tasks > implementing a socket connection each useful just for reading data > from the net and forwarding it to the server? Useful basically for being blocked when there is no data to read from the socket (actually no data in the network buffer). >> 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. > > Are you referring to the tasks reading from the net? Yes. There is a limit on the number of threads a process is allowed to have. It is not very big, 200 or so under Windows. If you needed to deal with 1000 connections, it would not help to be able to have 2000 threads, because switching them will consume too much resources. >> 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? > > So I don't have to use tasks neither for reading? Sorry but I haven't > got the concept... One task may service several sockets simultaneously. Normally the OS handles sockets asynchronously to the task reading or writing it, anyway. So it brings nothing to have more than just one task (I don't consider multiple network ports here). The task gets notified when the state of a socket changes. It looks into that socket, takes, for example, the data already read to this time, processes them and go back to sleep. For more information see, for example: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspx > Just to see if I have understood everything: > > - NO "writers tasks", > - N "readers tasks": every task has just one connection (socket) to > the peer from which receives data, > - Server is connected (by sockets) to N clients to which sends data > after elaboration, > - Server has one entry like: entry Receive_Data(Id_Reader_task : in > Integer; Data : in String), and inside its infinite loop accept this > entry, > - the generic "reader task" i calls the entry of the server like: > Server.Receive_Data(i, data); You could consider protected objects, as others already suggested. The reader might simply queue the packet read and continue, rather than waiting for a rendezvous with it. Usually, there are higher level protocol superimposed on the socket stream. It is a good idea to handle that in the reader and queue "digested" requests of higher level semantics to the server. Note one important advantage of having a queue of requests rather than communicating directly to the server. The queue decouples the readers from the server. So you could have two or three servers processing the requests from the queue. On a multi-core architecture that could give you better throughout. The number of servers can be adjusted later, you need not to decide it upfront as you would with direct rendezvous. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de