为什么Stream.BeginRead（）是同步的？

Question

The Stream.BeginRead() takes a callback function as one of the parameters. That callback function should be called asynchronously, but .net fakes that by calling callback function from the BeginRead() directly. Why is that happening? It seems like there is no difference between Read() and BeginRead().
Please see the stack view below:

Answer 1

As the documentation for Stream indicates:

The default implementation of BeginRead on a stream calls the Read method synchronously , which means that Read might block on some streams. However, instances of classes such as FileStream and NetworkStream fully support asynchronous operations if the instances have been opened asynchronously. Therefore, calls to BeginRead will not block on those streams. You can override BeginRead (by using async delegates, for example) to provide asynchronous behavior .

In other words, it is up to each Stream sub-class to provide true asynchronous behavior.

Now, in the case of the ConnectStream you see in your stack trace, that's another .NET class (internal, undocumented) and it actually does provide an asynchronous implementation of BeginRead() . This can be seen in the source code . But, there's another important rule for asynchronous operations generally: asynchronous operations following the APM may in fact complete synchronously . There's even a property on IAsyncResult to indicate this occurrence.

This in fact turns out to be the case for many asynchronous APIs. For example, when using await , it is possible that the method will not return at the await expression, but instead will retrieve the completion result immediately and just keep on executing in the current thread. This happens not only when the awaitable is just a synchronous operation dressed up in an asynchronous wrapper, but also when what would normally be an asynchronous operation can in fact be completed synchronously.

I'm sure that if you were to check the IAsyncResult.CompletedSynchronously property in your callback, you would find it was set to true , as it's supposed to be when the API completes an asynchronous operation synchronously. That property exists primarily for this very scenario, in case your own code needs to distinguish between operations that complete asynchronously and those that complete synchronously (in general, it shouldn't, but we all know code isn't always as it should be, and even sometimes can't be :) ).