Asynchronous Programming

[Steve - DND]

I'm trying to determine if I need to make my application multi-threaded, or
if it can be done with asynchronous programming. I realize that asynch calls
do create a new thread in the background, but when they come back, they
return to the thread that launched them, is that correct? If I go
multi-threaded, then I just need to spawn a new thread for each new
connection, right?

What I'm doing here is making a service that accepts connections via TCP,
does some stuff, and then returns a response. Would my best bet be to go
asych or multi-threaded? Any articles on either or both would be much
appreciated.

Thanks,
Steve

 

[Erik Frey]

I'm trying to determine if I need to make my application multi-threaded, or
if it can be done with asynchronous programming. I realize that asynch calls
do create a new thread in the background, but when they come back, they
return to the thread that launched them, is that correct? If I go
multi-threaded, then I just need to spawn a new thread for each new
connection, right?

What I'm doing here is making a service that accepts connections via TCP,
does some stuff, and then returns a response. Would my best bet be to go
asych or multi-threaded? Any articles on either or both would be much
appreciated.

Thanks,
Steve

Here's my favorite doc regarding threading in .NET:

http://www.eps-software.com/download/whitepaper_threading.pdf

Erik

 

[Chad Z. Hower aka Kudzu]

I'm trying to determine if I need to make my application multi-threaded,
or if it can be done with asynchronous programming. I realize that
asynch calls do create a new thread in the background, but when they
come back, they return to the thread that launched them, is that
correct? If I go multi-threaded, then I just need to spawn a new thread
for each new connection, right?

My advice is unless its just one isolated task - such as a single file read
or other, thread it. Your code will be much cleaner.

What I'm doing here is making a service that accepts connections via
TCP, does some stuff, and then returns a response. Would my best bet be
to go asych or multi-threaded? Any articles on either or both would be
much appreciated.

Multi threaded. Your code will be much cleaner, and more maintainable.

 

[William Stacey [MVP]]

A good way to go would be to wait on multiple socket events (one socket for
each tcp client) in a WaitForMultipleEvents call, then get the index of the
event and look that up to get your client socket object. You need to use
the win32 WSAEventSelect() method to make the sockets non-blocking and
associate and event with the socket - .NET does not currently support this
in managed code. However, after you do that, you should be able to use the
standard socket and TCPclient send and rec methods as normal. If you will
have many concurrent clients with concurrent send and receives, then using
one thread per client is not really optimal in server design and will be
slower then other designs because of the thread context switches and
contention for shared resources goes up with number of threads.. If many
clients, you probably want to go async. You could probably also use I/O
completion ports and a thread pool, have not really seen good examples of
this from managed code however.

 

[Steve - DND]

Here's my favorite doc regarding threading in .NET:

http://www.eps-software.com/download/whitepaper_threading.pdf

One thing I have a question on is scalability performance. I keep reading
that a multi-threaded approach may not necessarily scale very well. How many
threads is too many before the switching starts to kill the app? I will
probably have about 50-75(possibly up to 100) concurrent connections at peak
times. From what I have read, it sounds like this would be too many threads
to create.

 

[Chris R]

Steve,

Check out the ThreadPool Class. It'll handle multiple threads for you
in a much cleaner manner.

Chris R.

 

[William Stacey [MVP]]

I would agree. If all those clients are ~active, your going to spend a
larger respective amount of time context switching and competing for locks,
etc. then actually working. Each thread also gets a smaller quantum time to
do work as more threads are running in the system. So less time each thread
has to work, more context switch time, more contention for locks, etc. I am
not sure the Async read and writes using standard Socket or TCPClient are
much better. AFAICT, if you post reads for all those sockets, it will still
use that many threads from the pool to run the delegates for replies, not
much better as you end up hurding threads and your still using one thread
per client per read/write afaict. And does it queue the Async Reads if the
thread pool runs out of threads (i.e. more then 25) and block on new Async
requests or queue them and let the 25 threads work on the queue? Not sure.
There is some gray area here that would need to be tested. The overhead of
using the system supplied Async abstration is not free either. There a lot
of setup and tear down expense. Doing some informal testing on a circular
queue with one producer and one consumer I get about this each time:
Custom Async get/put: 00:00:10.3593750
Sync get/put: 00:00:01.0937500
CLR Async get/put: 00:00:37.6250000

The System async infrastructor is about 3-4 times slower then doing async
yourself and service the queue with one thread running in a tight loop. The
clr async is really easy, however, and seems to work well.

If perf is key, you may have to resort to overlapped io sockets or
WSAEventSelect and wrap a few pInvoke apis.

 

[Chad Z. Hower aka Kudzu]

One thing I have a question on is scalability performance. I keep
reading that a multi-threaded approach may not necessarily scale very
well. How many threads is too many before the switching starts to kill
the app? I will probably have about 50-75(possibly up to 100) concurrent
connections at peak times. From what I have read, it sounds like this
would be too many threads to create.

Ill post more later - but 100 thread is NOTHING. Dont worry till you get near
500 or more... Even 1000 is ok in most circumstances.

 

[Chad Z. Hower aka Kudzu]

I would agree. If all those clients are ~active, your going to spend a
larger respective amount of time context switching and competing for
locks, etc. then actually working. Each thread also gets a smaller
quantum time to do work as more threads are running in the system. So

Actually thats not correct - its a common misconception. I have to go out to
pay some bills but will post more on this later. Or check your copy of Indy
in Depth for details about this...

 

[William Stacey [MVP]]

Lay it on me brother As a side note, was not talking about Indy, but
..Net. If the Socket classes BeginX methods do not use the Std Async tech
with the thread pool, I would be interested in that and appreciate the
correction. Thanks!

 

[Chad Z. Hower aka Kudzu]

Lay it on me brother As a side note, was not talking about Indy, but

Yes. I know - its just that I know all about this threading stuff and common
misconceptions because of having to explain it so many times on the Delphi
forums.

 

[Chad Z. Hower aka Kudzu]

A good way to go would be to wait on multiple socket events (one socket for
each tcp client) in a WaitForMultipleEvents call, then get the index of the

The problem with this is there is a limit of 64 per call, so you still need
to break it into threads anways. And then you break your code away from
seqeuntial to handling 64 state machines... makes for ugly code.

contention for shared resources goes up with number of threads.. If many
clients, you probably want to go async. You could probably also use I/O
completion ports and a thread pool, have not really seen good examples of
this from managed code however.

Indy has support for this using fibers. This part is in SuperCore and hasnt
been ported to .net yet. This part will likely have to be unmanaged until
fibers, etc are accesible as managed objects.

 

[Chad Z. Hower aka Kudzu]

One thing I have a question on is scalability performance. I keep
reading that a multi-threaded approach may not necessarily scale very

Key word is "may not". In most cases, espeically with sockets its fine. In
fact its better.

well. How many threads is too many before the switching starts to kill
the app? I will probably have about 50-75(possibly up to 100) concurrent

It depends what they are doing. But just to prove a point, press Ctrl-Alt-Del
now. Select task manager, then Performance tab.

I have 493 threads running, with 1% CPU load. My machine is barely loaded
right now compared to what I normally do to it. And guess what? Ive never had
any smoke roll out of the fan port yet.

What you will hit before any limits is the process memory limit. You will hit
this at about 1000 threads (There are ways to go higher, but normally you
should not as 1000 threads in one process has other issues).

If you arent going over 200-300 threads, dont even worry about it. That is
unless each one is calculating Pi to the 4 billionth digit.

connections at peak times. From what I have read, it sounds like this
would be too many threads to create.

Not at all. Windows wont even notice that many.

 

[Chad Z. Hower aka Kudzu]

I would agree. If all those clients are ~active, your going to spend a
larger respective amount of time context switching and competing for
locks, etc. then actually working. Each thread also gets a smaller

Not true as people assume.... If they are all active calculating Pi - yes.
But active in this case means "socket activity" then no. The reason for
this is bandwidth.

Lets take a 100 MB ethernet. Calculate its max speed against the CPU. You
will see that it is MANY magnitudes slower than even todays most slothful
of CPUs. Factor in hardward buffers, and software driver buffers and each
thread is activated very rarely in the scheme of things even in a fully
loaded ethernet card.

Beause of this, threads spend most of their time waiting on network calls.
This causes them to be skipped over by the scheduler until their blocking
calls have returned. This reduces the "theoretical" context switching by
many thousands.

quantum time to do work as more threads are running in the system. So

Most thread in this type of system wont reach their quantum because they
will voluntarily sleep first.

less time each thread has to work, more context switch time, more

Nope - because they will switch to threads which are running, which in such
a system most threads on each pass will be sleeping. In fact many of the
switches will be to the idle or system threads.

contention for locks, etc. I am not sure the Async read and writes
using standard Socket or TCPClient are much better. AFAICT, if you post

There are two types of asyncs. The asyncs with windows messages are usually
even slower.

Another factor is the blocking "thunk" to kernel level. But again, only for
advanced systems.

In the scheme of things, what this user describes is a very small system
and he should focus on clean readable code. Performance will be just fine
and there is not need to build and advanced design and muck up his code.

If perf is key, you may have to resort to overlapped io sockets or
WSAEventSelect and wrap a few pInvoke apis.

Problems there too.

IOCP is the only TRUE fast way, and it has a TON of problems that should be
avoided and only used as a LAST resort.

 

[beagle]

It depends what they are doing. But just to prove a point, press Ctrl-Alt-Del
now. Select task manager, then Performance tab.

I have 493 threads running, with 1% CPU load. My machine is barely loaded
right now compared to what I normally do to it. And guess what? Ive never had
any smoke roll out of the fan port yet.

This metric is fairly meaningless because it doesn't indicate how many
of those threads are active at any given time. If only a handful of
those threads are active, there won't be much context switching going
on.

If all 493 threads are busy reading/writing data to/from reasonably
active socket connections, you'll be doing lots of context switches per
second, and chewing up a lot more CPU doing those context switches.

 

[beagle]

A good way to go would be to wait on multiple socket events (one socket for
each tcp client) in a WaitForMultipleEvents call, then get the index of the
event and look that up to get your client socket object. You need to use
the win32 WSAEventSelect() method to make the sockets non-blocking and
associate and event with the socket - .NET does not currently support this
in managed code.

I believe WaitForMultipleEvents() can only wait on 64 event objects at
a time. The OP mentioned a potential peak as high as 100, so if he
used this approach, a modified version would be required. Also I
believe WaitForMultipleObjects() tends to favor the lower numbered
objects which could present problems for certain usage patterns.

 

[Chad Z. Hower aka Kudzu]

(e-mail address removed) wrote in

This metric is fairly meaningless because it doesn't indicate how many

Its not meaningless. It wasnt meant to point out that they all could be
active. But nearly all users are under the impression that if you even CREATE
100 threads you will see smoke rolling. This proves this point false.

of those threads are active at any given time. If only a handful of
those threads are active, there won't be much context switching going
on.

As to the second part - you need to read the rest of the message. I have
built servers up to 1,000 thread that run just fine and do not consume tons
or RAM, nor CPU.

In stress testing I've pushed them above 1,500.

If all 493 threads are busy reading/writing data to/from reasonably
active socket connections, you'll be doing lots of context switches per
second, and chewing up a lot more CPU doing those context switches.

Wrong - Please go back and read my complete message. It appear you just read
the first part.

 

[William Stacey [MVP]]

Thanks. Good to know. If you use EventSelect() and use the same event
object for each socket, is there a way to tell what socket caused the event
to fire? TIA

 

[Chad Z. Hower aka Kudzu]

Thanks. Good to know. If you use EventSelect() and use the same event
object for each socket, is there a way to tell what socket caused the event
to fire? TIA

Not unless you log it somewhere..

 

[William Stacey [MVP]]

That is kinda the issue however. All you know is that the event was
signaled - you don't know what socket caused the signal (afaict). So I
guess you can wait on the event and enum the active socket list to poll each
one to see if it has some data and then wait on event again in a loop.