4 ms·

Think of it this way: What happens when IIS runs out of threads? Without async code, it queues of requests and users sit there getting nothing from your serve

Think of it this way: What happens when IIS runs out of threads? Without async code, it queues of requests and users sit there getting nothing from your server. With async code, that's not the case! Well, until you reach the limit of what async code does, but that limit is quite high. Typically a request thread that ends up blocking on I/O in some way (like accessing a database) sits there doing absolutely nothing for a very long time. The time it takes to get data from a database could be spent servicing many, many more requests! Async does just that. And before you ask, it doesn't spawn off any threads ... it leverages the asynchronous nature of the operating system to service I/O requests. It's actually really, really rad. > Usually seems to be a premature optimization If you have a user-facing system, it's most definitely not a premature optimization. If you know, for a fact, that you'll never need to worry about responsiveness, they're not worth it.

louthy 11y ago
There are 32,768 threads in the thread-pool on a 64bit machine. How many do you need?
- edgyswingset 11y ago
  > How many do you need? That's an irrelevant question until you legitimately need to scale out. Async code lets you scale up so that when 32,769 users access a site relatively at the same time, you don't force a user to wait for IIS to free up a new thread.
  - louthy 11y ago
    > 'to wait for IIS to free up a new thread.' Apologies if I'm not following your train of thought here. The thread-pool has the threads right, not IIS? When you do something like Task.Run(...) the task-scheduler will schedule your work on a thread-pool thread (32,768 pre-allocated at start-up). Of course you have to wait for the scheduler to give you one of the threads from the pool. Are you saying async doesn't need threads/TPL? I know it has some funky concurrency stuff that allows interleaved processing (rather than thread-pool processing), is this what you're referring to? Even IO would have to do something like this behind the scenes: Result IOMethod() { EventWaitHandle wait = new AutoResetEvent(false); // Do your IO - pass in the handle wait.WaitOne(); return result; } Wouldn't the pre-IO and post-IO need to be run via the scheduler if you want it to run asynchronously? The WaitOne will release the thread back to the pool. How is async any different?
    - louthy 11y ago
      Ok, did a bit of reading for myself. I had obviously only vaguely took in what was said when it was first released as a language feature. So async will run all code on the current thread, until it gets to some IO. At that point it switches to running the code that you'd normally expect to run asynchronously. Once the IO returns it runs the remainder of the async 'closure' (for want of a better word) with the result. A kind of coroutines system, I guess similar to node.js.
      - edgyswingset 11y ago
        Yep! The async model in node.js is very similar. Here's a fantastic blog post about the details of it all: http://blog.stephencleary.com/2013/11/there-is-no-thread.html http://blog.stephencleary.com/2013/11/there-is-no-thread.htm...
    - MichaelGG 11y ago
      There's no way it's creating 32k threads on start up. That's the default max. Threads aren't totally cheap so they alloc a lot less. Asp.net allocates more. Used to be 25 or 50 per CPU.
  - UK-AL 11y ago
    async doesn't use threads. Async is a goto state machine. While the IO is set as blocked at the operating system level, it does something else. Then when it's unblocked, it jumps back.
    - guiomie 11y ago
      I'm still having a hard time with async. I see lot's of async code using Tasks, pretty much 99% of the time. Wouldn't this make async code using threads anyway?
      - UK-AL 11y ago
        A task may or may not be run on another thread. It just represents a unit of work with a potential result. It can be confusing because Task objects original main use was running stuff on background worker threads. That is no longer the case. Note, you can use async and threads. But a lot of code using async and task are NOT using threads.
      - edgyswingset 11y ago
        Async code, down in the "guts" of the system, will borrow user-level and OS-level threads, so while it's correct that it does use threads, it won't spawn off new ones. Spawning off a new thread ultimately wouldn't accomplish much (after all, why not have IIS just use a new one?). I like to think of it as utilizing the operating system more efficiently. I/O on a system is asynchronous by default. Async code will essentially delegate work so the OS can do what it does best!
- jameshart 11y ago
  Each of those threads has a stack allocated to it - and from what I understand, the CLR will actually commit a megabyte of RAM for every thread. You really don't want to have all of the threads permitted in the threadpool up and running at once if you can avoid it. Async allows you to handle 32000 simultaneous requests without having to have 32000 threads and 32000 stacks active at once.
runfaster2000 11y ago
This is another similar answer: http://blogs.msdn.com/b/dotnet/archive/2012/11/13/the-net-framework-4-5-is-optimized-for-the-cloud.aspx http://blogs.msdn.com/b/dotnet/archive/2012/11/13/the-net-fr....

louthy 11y ago

There are 32,768 threads in the thread-pool on a 64bit machine. How many do you need?

edgyswingset 11y ago
> How many do you need? That's an irrelevant question until you legitimately need to scale out. Async code lets you scale up so that when 32,769 users access a site relatively at the same time, you don't force a user to wait for IIS to free up a new thread.
- louthy 11y ago
  > 'to wait for IIS to free up a new thread.' Apologies if I'm not following your train of thought here. The thread-pool has the threads right, not IIS? When you do something like Task.Run(...) the task-scheduler will schedule your work on a thread-pool thread (32,768 pre-allocated at start-up). Of course you have to wait for the scheduler to give you one of the threads from the pool. Are you saying async doesn't need threads/TPL? I know it has some funky concurrency stuff that allows interleaved processing (rather than thread-pool processing), is this what you're referring to? Even IO would have to do something like this behind the scenes: Result IOMethod() { EventWaitHandle wait = new AutoResetEvent(false); // Do your IO - pass in the handle wait.WaitOne(); return result; } Wouldn't the pre-IO and post-IO need to be run via the scheduler if you want it to run asynchronously? The WaitOne will release the thread back to the pool. How is async any different?
  - louthy 11y ago
    Ok, did a bit of reading for myself. I had obviously only vaguely took in what was said when it was first released as a language feature. So async will run all code on the current thread, until it gets to some IO. At that point it switches to running the code that you'd normally expect to run asynchronously. Once the IO returns it runs the remainder of the async 'closure' (for want of a better word) with the result. A kind of coroutines system, I guess similar to node.js.
    - edgyswingset 11y ago
      Yep! The async model in node.js is very similar. Here's a fantastic blog post about the details of it all: http://blog.stephencleary.com/2013/11/there-is-no-thread.html http://blog.stephencleary.com/2013/11/there-is-no-thread.htm...
  - MichaelGG 11y ago
    There's no way it's creating 32k threads on start up. That's the default max. Threads aren't totally cheap so they alloc a lot less. Asp.net allocates more. Used to be 25 or 50 per CPU.
- UK-AL 11y ago
  async doesn't use threads. Async is a goto state machine. While the IO is set as blocked at the operating system level, it does something else. Then when it's unblocked, it jumps back.
  - guiomie 11y ago
    I'm still having a hard time with async. I see lot's of async code using Tasks, pretty much 99% of the time. Wouldn't this make async code using threads anyway?
    - UK-AL 11y ago
      A task may or may not be run on another thread. It just represents a unit of work with a potential result. It can be confusing because Task objects original main use was running stuff on background worker threads. That is no longer the case. Note, you can use async and threads. But a lot of code using async and task are NOT using threads.
    - edgyswingset 11y ago
      Async code, down in the "guts" of the system, will borrow user-level and OS-level threads, so while it's correct that it does use threads, it won't spawn off new ones. Spawning off a new thread ultimately wouldn't accomplish much (after all, why not have IIS just use a new one?). I like to think of it as utilizing the operating system more efficiently. I/O on a system is asynchronous by default. Async code will essentially delegate work so the OS can do what it does best!
jameshart 11y ago
Each of those threads has a stack allocated to it - and from what I understand, the CLR will actually commit a megabyte of RAM for every thread. You really don't want to have all of the threads permitted in the threadpool up and running at once if you can avoid it. Async allows you to handle 32000 simultaneous requests without having to have 32000 threads and 32000 stacks active at once.

runfaster2000 11y ago

This is another similar answer: http://blogs.msdn.com/b/dotnet/archive/2012/11/13/the-net-framework-4-5-is-optimized-for-the-cloud.aspx http://blogs.msdn.com/b/dotnet/archive/2012/11/13/the-net-fr....