asynchronous calls & threading. which is better?

[Li kai Liu Angus]

Hi, I've seen a few Server/Client programs here. Many of the server programs that can handle many connections at the same use asynchronous calls. I just can't figure out why this approach is popular in C#. Why most people use it instead of threads? Any advantages? If I want to write a ftp server that can take control of each connection(e.g. D/L speed control, kill connection on user's demand), are asynchronous calls recommended in this case? Is the underlying mechanism of asychronous calls also use threading things? Thanks in advance:) A beginner

[Nish Nishant]

When there are too many connections, there are too many threads and if each connection requires moderate to heavy processing, you'll bring the machine down in no time Nish

---

Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.

[Eric Gunnerson msft]

The "NT family" of Windows (ie NT, Win2K, WinXP) supports a feature known as "I/O completion ports". In this feature, the O/S calls back to the user code when an I/O operation completes. In .NET, the built-in async functions use this support. That means you can be waiting for 100 different read operations to finish using completion ports without a lot of overhead, where if you used threads, you'd need to have 100 of them running at the same time, and that takes a lot more resources.

[Eric Gunnerson msft]

Sometimes I get lucky...

[Nish Nishant]

Eric Gunnerson (msft) wrote: In .NET, the built-in async functions use this support. Wow! That's cool info Eric Gunnerson. Thanks for that. It amazes me also to see you spot just the right threads here on CP. Thanks, once again, Nish

---

Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.

[Li kai Liu Angus]

Thank you:) but when to use threads? I mean what situations are better for creating threads, or in what cases, using asynchronous calls would be better? Now, I see that creating threads is more costly than using asynchronous calls. It seems that I cannot control the number of "threads" using asynchronous call. Then, if I'm writing a ftp server that only take 5 connections in maximum, it looks useless to me, is it?

[Not Active]

One reason to use async over threads would be in the case of file transfers. You would need to have the thread spinning and polling for completion. With an async call you would be notified when the operation completed. I would say a thread would be better used for a things like background operations, like refreshing a directory listing. It can be launched while the use is doing something else without interfering.

[James T Johnson]

Eric Gunnerson (msft) wrote: The "NT family" of Windows (ie NT, Win2K, WinXP) supports a feature known as "I/O completion ports". In this feature, the O/S calls back to the user code when an I/O operation completes. In .NET, the built-in async functions use this support. What happens on 98/ME (*shudder*)? James Simplicity Rules!

[Eric Gunnerson msft]

If there's built-in support using completion ports (ie there are BeginXXX() and EndXXX() calls on the class), I think that's always the preferred choice, since it doesn't take any threads at all. It is true that for small numbers of concurrent processes, it can be a lot easier to write them as separate threads, because you can write the code all at once as part of a method, while with the async case, you may have to write your code in several chunks as part of the callback routines.

[Eric Gunnerson msft]

On the 98 series, the runtime emulates the feature using threads.

[Eric Gunnerson msft]

If there's built-in support for async (ie the class has BeginXXX() and EndXXX() methods), then you would normally use that if you care about scaling. If you're writing something small, then writing the threaded version is generally easier, because you write your code in one chunk rather than having to write several callback functions.

[James T Johnson]

Thanks Eric :) James Simplicity Rules!