Re: "C - like: THIS" pointer to a task type inside a task function

[Ada BRL <ada.brl.2011@gmail.com>]

On 25 Gen, 13:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 25 Jan 2012 04:43:57 -0800 (PST), Ada BRL wrote:
> > On 24 Gen, 18:43, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Tue, 24 Jan 2012 09:12:03 -0800 (PST), Ada BRL wrote:
> >>> On 23 Gen, 19:59, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> >>> 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.
>

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=...

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 waiting
> 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 stream.
> 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 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.

Yes, it's clear :-).

>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de