0

My application accepts many concurrent tcp connections and I call socket.BeginReceive(...) or socket.ReceiveAsync(SocketAsyncEventArgs e) whenever a client is connected. I want to know if all my BeginReceive() calls are handled by one thread or each call is handled by a different background thread?

Johnny
  • 8,939
  • 2
  • 28
  • 33
Shakeel
  • 11
  • 4
  • [msdn - async](https://msdn.microsoft.com/library/hh191443(vs.110).aspx#Anchor_2) – mrogal.ski Dec 05 '16 at 13:39
  • 2
    You might find this interesting also: http://blog.stephencleary.com/2013/11/there-is-no-thread.html – Evk Dec 05 '16 at 13:40
  • It doesn't consume *any* thread at all. `await` *awaits* an asynchronous operation to complete, then continues in the same execution context, eg the original UI thread – Panagiotis Kanavos Dec 05 '16 at 13:40
  • `BeginReceive` isn't the same as `async/await`, which is what everyone understands when you mention `async API`. The socket operation itself is performed by the OS and network driver. It is *always* asynchronous and doesn't use background threads. The driver/OS emulate synchronous operation by blocking the calling thread. – Panagiotis Kanavos Dec 05 '16 at 13:43
  • Yes, great Panagiotis, you understood correctly my question. But I don't agree with your last sentence [The driver/OS emulate sysnchronous....] or I am missing something. Please can you provide more details. If I start 500 Beginxxx operations will OS use single thread to callback my callback delegte? – Shakeel Dec 05 '16 at 13:50
  • The OS won't use anything to make the call (except the original thread). The *driver* will do whatever it decides to do. As for callbacks, why use callbacks? Why use some *other* thread if you want to go back to the original thread? That's what happens with `await`. If you pass a callback, the callback will be executed on a background thread, but nothing forces you to do so. – Panagiotis Kanavos Dec 05 '16 at 13:54
  • Thank you very much @Evk, the link you suggested provides perfect answer to my question. I don't see here any option to give you points etc. – Shakeel Dec 06 '16 at 06:39
  • Similarly the link provided by @m.rogalski also explains the working details excellently. Thanks to him also. – Shakeel Dec 06 '16 at 06:42

2 Answers2

1

Multiple concurrent Async calls do not open multiple background threads as explained here blog.stephencleary.com/2013/11/there-is-no-thread.html.

All credit goes to @Evk for suggesting this link and the original author of link.

Shakeel
  • 11
  • 4
0

The answer is no, you can read following.

MSDN Asynchronous Programming with Async and Await (C# and Visual Basic) Threads

Async methods are intended to be non-blocking operations. An await expression in an async method doesn’t block the current thread while the awaited task is running. Instead, the expression signs up the rest of the method as a continuation and returns control to the caller of the async method.

The async and await keywords don't cause additional threads to be created. Async methods don't require multithreading because an async method doesn't run on its own thread. The method runs on the current synchronization context and uses time on the thread only when the method is active. You can use Task.Run to move CPU-bound work to a background thread, but a background thread doesn't help with a process that's just waiting for results to become available.

The async-based approach to asynchronous programming is preferable to existing approaches in almost every case. In particular, this approach is better than BackgroundWorker for IO-bound operations because the code is simpler and you don't have to guard against race conditions. In combination with Task.Run, async programming is better than BackgroundWorker for CPU-bound operations because async programming separates the coordination details of running your code from the work that Task.Run transfers to the threadpool.

Community
  • 1
  • 1
Johnny
  • 8,939
  • 2
  • 28
  • 33
  • Thanks Lepijohnny, but as I explained in explanation section, my question is related to socket.BeginReceive(..), BeginSend(..) and all other dotnet APIs which use Beginxxx, Endxxx pattern. My question is not intended for async/await scenarios. – Shakeel Dec 05 '16 at 13:44
  • @Shakeel actually `async/await` is the rule, not the exception. When people talk about `async APIs` they mean those returning Task. The `Begin/End` APIs are considered legacy, for the last 4-5 years. And sockes [are indeed used](http://stackoverflow.com/a/1388691/134204) with `async/await`, because it's a lot easier to use them like this – Panagiotis Kanavos Dec 05 '16 at 13:48
  • @Shakeel what you described is the [APM pattern](https://msdn.microsoft.com/en-us/library/ms228963(v=vs.110).aspx) – Panagiotis Kanavos Dec 05 '16 at 13:50