Is it necessary to use the async Begin/End methods if already on a separate thread?

Question

Trying to figure out whether or not I should use async methods or not such as:

• TcpListener.BeginAcceptTcpClient
• TcpListener.EndcceptTcpClient

and

• NetworkStream.BeginRead
• NetworkStream.EndRead

as opposed to their synchronous TcpListener.AcceptTcpClient and NetworkStream.Read versions. I've been looking at related threads but I'm still a bit unsure about one thing:

Question: The main advantage of using an asynchronous method is that the GUI is not locked up. However, these methods will be called on separate Task threads as it is so there is no threat of that. Also, TcpListener.AcceptTcpClient blocks the thread until a connection is made so there is no wasted CPU cycles. Since this is the case, then why do so many always recommend using the async versions? It seems like in this case the synchronous versions would be superior?

Also, another disadvantage of using asynchronous methods is the increased complexity and constant casting of objects. For example, having to do this:

private void SomeMethod()
{
    // ...

    listener.BeginAcceptTcpClient(OnAcceptConnection, listener);
}

private void OnAcceptConnection(IAsyncResult asyn)
{
    TcpListener listener = (TcpListener)asyn.AsyncState;

    TcpClient client = listener.EndAcceptTcpClient(asyn);
}

As opposed to this:

TcpClient client = listener.AcceptTcpClient();

Also it seems like the async versions would have much more overhead due to having to create another thread. (Basically, every connection would have a thread and then when reading that thread would also have another thread. Threadception!)

Also, there is the boxing and unboxing of the TcpListener and the overhead associated with creating, managing, and closing these additional threads.

Basically, where normally there would just be individual threads for handling individual client connections, now there is that and then an additional thread for each type of operation performed (reading/writing stream data and listening for new connections on the server's end)

Please correct me if I am wrong. I am still new to threading and I'm trying to understand this all. However, in this case it seems like using the normal synchronous methods and just blocking the thread would be the optimal solution?

Answer 1

TcpListener.AcceptTcpClient blocks the thread until a connection is made so there is no wasted CPU cycles.

But there is also no work getting done. A Thread is a very expensive operating system object, about the most expensive there is. Your program is consuming a megabyte of memory without it being used while the thread blocks on connection request.

However, these methods will be called on separate Task threads as it is so there is no threat of that

A Task is not a good solution either, it uses a threadpool thread but the thread will block. The threadpool manager tries to keep the number of running TP threads equal to the number of cpu cores on the machine. That won't work well when a TP thread blocks for a long time. It prevents other useful work from being done by other TP threads that are waiting to get their turn.

BeginAcceptTcpClient() uses a so-called I/O completion callback. No system resources are consumed while the socket is listening. As soon as a connection request comes in, the operating system runs an APC (asynchronous procedure call) which grabs a threadpool thread to make the callback. The thread itself is in use for, typically, a few microseconds. Very efficient.

This kind of code will get a lot simpler in the next version of C# with the next async and await keywords. End of the year, maybe.

Answer 2

If you call AcceptTcpClient() on any thread, that thread is useless until you get a connection.

If you call BeginAcceptTcpClient(), the calling thread can stop immediately, without wasting the thread.

This is particularly important when using the ThreadPool (or the TPL), since they use a limited number of pool threads.
If you have too many threads waiting for operations, you can run out of threadpool threads, so that new work items will have to wait until one of the other threads finish.