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.213.68 with SMTP id nq4mr10647704pbc.2.1327503957659; Wed, 25 Jan 2012 07:05:57 -0800 (PST) Path: lh20ni222724pbb.0!nntp.google.com!news2.google.com!postnews.google.com!o13g2000vbf.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: Wed, 25 Jan 2012 07:05:57 -0800 (PST) Organization: http://groups.google.com Message-ID: <78412bc2-abc1-4d69-a949-487ce070a8de@o13g2000vbf.googlegroups.com> References: <19cglxkm60u91.1ezey0dra41do$.dlg@40tude.net> <2c51ce87-87ef-438c-bec5-e3b8114f0471@cf6g2000vbb.googlegroups.com> <1rp216zwnjx3j$.rjwu8m3hxgp1.dlg@40tude.net> NNTP-Posting-Host: 164.11.203.58 Mime-Version: 1.0 X-Trace: posting.google.com 1327503957 23673 127.0.0.1 (25 Jan 2012 15:05:57 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 25 Jan 2012 15:05:57 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: o13g2000vbf.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-25T07:05:57-08:00 List-Id: On 25 Gen, 13:48, "Dmitry A. Kazakov" wrote: > 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 thro= gh > >>>>> 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 i= t > >>> 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 dedic= ated > >> output task. The network stack is already buffered and most likely > >> asynchronous to the sender once you have initiated send. Thus you coul= d > >> 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. > Luckily I don't have thousands of tasks, I can have at about 8 - 10 "readers" from net. > >> 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=3D..= . Just a question: If I have understood well, I may have just one thread connected with N clients through N sockets, using the SAME PORT. How may I know if one client (say number 5) is connected or not? I need an array of connections and so on... In the case of N readers I can know it, because there's a mapping one- to-one. In the case unique reader with N sockets, the OS (in my case MS Windows 7 Pro) handles the concurrent requests of sending data to the reader queueing them and delivering each request per time to the (unique) reader. For this reason I must trust the fairness / reliability of the OS. I MUST BE SURE that the data is delivered to the server...what do you suggest me to do? Multiple readers or only one? > > > 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 waiti= ng > for a rendezvous with it. Regardless to the unique reader / N readers, I have to use a protected object that incapsulates a buffer (implemented by an array of strings type); the reader(s) write into this protected buffer and the server reads from it. Am I right? Protected objects implements mutual exclusion by construction. > > Usually, there are higher level protocol superimposed on the socket strea= m. > It is a good idea to handle that in the reader and queue "digested" > requests of higher level semantics to the server. Yes, this is my case since I have to make some elaboration of incoming data, and I prefer to forward to the server "digested" data rather than raw one. > > Note one important advantage of having a queue of requests rather than > communicating directly to the server. The queue decouples the readers fro= m > the server. So you could have two or three servers processing the request= s > 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. Yes, it's clear :-). > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de