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]

"Steve - DND" <steve!@!digita lnothing.com> wrote in message
news:O6******** ********@TK2MSF TNGP09.phx.gbl. ..

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..._threading.pdf

Erik

[Chad Z. Hower aka Kudzu]

"Steve - DND" <steve!@!digita lnothing.com> wrote in
news:O6******** ******@TK2MSFTN GP09.phx.gbl:

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.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

[Steve - DND]

"Erik Frey" <er*******@hotm ail.com> wrote in message
news:eg******** ******@TK2MSFTN GP11.phx.gbl...

"Steve - DND" <steve!@!digita lnothing.com> wrote in message
news:O6******** ********@TK2MSF TNGP09.phx.gbl. ..

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

"Steve - DND" <steve!@!digita lnothing.com> wrote in message
news:ux******** ******@TK2MSFTN GP09.phx.gbl...

"Erik Frey" <er*******@hotm ail.com> wrote in message
news:eg******** ******@TK2MSFTN GP11.phx.gbl...

"Steve - DND" <steve!@!digita lnothing.com> wrote in message
news:O6******** ********@TK2MSF TNGP09.phx.gbl. ..

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

[William Stacey [MVP]]

A good way to go would be to wait on multiple socket events (one socket for
each tcp client) in a WaitForMultiple Events 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.
--
William Stacey, MVP
--
William Stacey, MVP

"Steve - DND" <steve!@!digita lnothing.com> wrote in message
news:O6******** ******@TK2MSFTN GP09.phx.gbl...

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

[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.359375 0
Sync get/put: 00:00:01.093750 0
CLR Async get/put: 00:00:37.625000 0

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.

--
William Stacey, MVP

"Steve - DND" <steve!@!digita lnothing.com> wrote in message
news:ux******** ******@TK2MSFTN GP09.phx.gbl...

"Erik Frey" <er*******@hotm ail.com> wrote in message
news:eg******** ******@TK2MSFTN GP11.phx.gbl...

"Steve - DND" <steve!@!digita lnothing.com> wrote in message
news:O6******** ********@TK2MSF TNGP09.phx.gbl. ..

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

[Chad Z. Hower aka Kudzu]

"Steve - DND" <steve!@!digita lnothing.com> wrote in
news:ux******** ******@TK2MSFTN GP09.phx.gbl:

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 (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

[Chad Z. Hower aka Kudzu]

"William Stacey [MVP]" <st***********@ mvps.org> wrote in
news:eK******** ******@TK2MSFTN GP09.phx.gbl:

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

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"

[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!

--
William Stacey, MVP

"Chad Z. Hower aka Kudzu" <cp**@hower.org > wrote in message
news:Xn******** **********@127. 0.0.1...

"William Stacey [MVP]" <st***********@ mvps.org> wrote in
news:eK******** ******@TK2MSFTN GP09.phx.gbl:

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

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programmin g is an art form that fights back"