in C#, there are two threads when I call BeginXXX

Question

I know something about the IOCP, but I'm a little confused with APM.

static FileStream fs;
static void Main(string[] args)
{
    fs = new FileStream(@"c:\bigfile.txt", FileMode.Open);
    var buffer = new byte[10000000];
    IAsyncResult asyncResult = fs.BeginRead(buffer, 0, 10000000, OnCompletedRead, null);
    Console.WriteLine("async...");
    int bytesRead = fs.EndRead(asyncResult);
    Console.WriteLine("async... over");
}

static void OnCompletedRead(IAsyncResult ar)
{
       Console.WriteLine("finished");
}

I wonder, is the read action executed by an IO thread asynchronously? Or a worker thread in a thread pool?

And the callback function OnCompletedRead, is it also executed by an IO thread in CLR thread pool?

Are these two threads the same one? If not, there are two threads generated, one executes the read action and another does the callback.

Answer 1

If you don't use an AsyncCallback argument with BeginRead then there is only one thread that runs code in your program. This uses IO completion ports to signal when the IO is complete by running a small amount of code on a thread in the IO thread pool to update the status of the operation as being complete. When you call EndRead it will block the current thread until the IO operation is complete. It is asynchronous in that when you start the read operation the current thread does not need to do anything other than wait for the IO hardware to perform the read operation, so you can do other things in the meantime and then decide when you want to stop and wait for the IO to finish.

If you do pass in an AsyncCallback then when the IO operation is complete it will execute a small amount of code on an IO thread pool thread which will trigger your callback method to be executed on a thread from the .NET thread pool.

Answer 2

Usually, mclaassen is right about the nature of IO bound work, IOCP and the APM. When BeginRead executes, it does so asynchronously all the way down to kernel mode. But, there is one caveat specifically in your example that he didn't mention in his answer.

In your example, you use the FileStream class. One important thing to note is that if you dont use the FileStream overload that accepts a useAsync boolean, when you invoke a BeginWrite / EndWrite operation, it will queue work on a new ThreadPool thread.

This is the proper overload:

public FileStream(
    string path,
    FileMode mode,
    FileAccess access,
    FileShare share,
    int bufferSize,
    bool useAsync
)

From MSDN:

useAsync:

Type: System.Boolean

Specifies whether to use asynchronous I/O or synchronous I/O. However, note that the underlying operating system might not support asynchronous I/O, so when specifying true, the handle might be opened synchronously depending on the platform. When opened asynchronously, the BeginRead and BeginWrite methods perform better on large reads or writes, but they might be much slower for small reads or writes. If the application is designed to take advantage of asynchronous I/O, set the useAsync parameter to true. Using asynchronous I/O correctly can speed up applications by as much as a factor of 10, but using it without redesigning the application for asynchronous I/O can decrease performance by as much as a factor of 10.

You have to make sure each specific method implementing the APM pattern truly uses true asynchronous work all the way down.