asp.net mvc 4 - What is executing the code when using await/async? -

here sample code https://www.asp.net/mvc/overview/performance/using-asynchronous-methods-in-aspnet-mvc-4

public async task<actionresult> gizmosasync() {     viewbag.syncorasync = "asynchronous";     var gizmoservice = new gizmoservice();     return view("gizmos", await gizmoservice.getgizmosasync()); } 

as understood, async/await usefull freeing worker thread can process other request. getgizmosasync not call "httpresponse.content.readasasync" (which guess executed thread io pool) it's calling other non async code " var uri = util.getserviceuri("gizmos");".

what executing "var uri = util.getserviceuri("gizmos");" if it's not thread worker pool ? there no io here.

your understanding of async little off. allows thread returned pool if it's in wait-state. last bit important. thread still executing code, it's external process going on, doesn't require thread, i.e. network comm, file i/o, etc. once external process completes, os responsible restoring control originating process, requires new thread requested pool continue.

also, because part of code async doesn't mean happens async: namely other code async , eligible async. said above, thread released if it's in wait-state; running sync mean not waiting, , therefore not released. also, things never async, if try run them async. cpu-bound requires thread run, thread never enter wait-state , never released.

update

the assumption seems there's other thread that's handling async work, that's not what's happening. said in comments, os-level work extremely technical, this best simplified explanation i've found. relevant portion of article below posterity:

what thread doing asynchronous work?

i asked question time. implication there must thread somewhere that’s blocking on i/o call external resource. so, asynchronous code frees request thread, @ expense of thread elsewhere in system, right? no, not @ all.

to understand why asynchronous requests scale, i’ll trace (simplified) example of asynchronous i/o call. let’s request needs write file. request thread calls asynchronous write method. writeasync implemented base class library (bcl), , uses completion ports asynchronous i/o. so, writeasync call passed down os asynchronous file write. os communicates driver stack, passing along data write in i/o request packet (irp).

this things interesting: if device driver can’t handle irp immediately, must handle asynchronously. so, driver tells disk start writing , returns “pending” response os. os passes “pending” response bcl, , bcl returns incomplete task request-handling code. request-handling code awaits task, returns incomplete task method , on. finally, request-handling code ends returning incomplete task asp.net, , request thread freed return thread pool.

now, consider current state of system. there various i/o structures have been allocated (for example, task instances , irp), , they’re in pending/incomplete state. however, there’s no thread blocked waiting write operation complete. neither asp.net, nor bcl, nor os, nor device driver has thread dedicated asynchronous work.

when disk completes writing data, notifies driver via interrupt. driver informs os irp has completed, , os notifies bcl via completion port. thread pool thread responds notification completing task returned writeasync; in turn resumes asynchronous request code. there few threads “borrowed” short amounts of time during completion-notification phase, no thread blocked while write in progress.

this example drastically simplified, gets across primary point: no thread required true asynchronous work. no cpu time necessary push bytes out. there’s secondary lesson learn. think device driver world, how device driver must either handle irp or asynchronously. synchronous handling not option. @ device driver level, non-trivial i/o asynchronous. many developers have mental model treats “natural api” i/o operations synchronous, asynchronous api layer built on natural, synchronous api. however, that’s backward: in fact, natural api asynchronous; , it’s synchronous apis implemented using asynchronous i/o!