

Everything .NET programmers know about Asynchronous Programming is wrong - deedee
http://hanselminutes.com/327/everything-net-programmers-know-about-asynchronous-programming-is-wrong

======
harrytuttle
Genuine question...

We have way over a million lines of c#, in asp.net, mvc and windows forms. We
get 80,000,000 http requests a day.

We have no async (delegates or 4.5 stuff), no threading other than what WCF,
AppFabric and ASP.Net give us.

About 25% is generic CRUD code but the rest is complicated matching,
integration and math code. We also touch most fundamental computer science
domains.

This begs the question: you really need async in the language?

~~~
d4nt
I think async is a systems programming tool rather than an application
programming tool. If you're writing a web server or a web browser, it'd be
useful. But for a web application, you're already sitting on a highly scalable
and robust async library called IIS so when you need a background task the
easiest thing to do is to make it a RESTful API call. I find many web
developers now intuitively break up their application into parallelizable
chunks without ever really thinking about async or threads, they just just say
"this web page is taking a long time to load, maybe I can defer some of the
work until after the page load" or (as you seem to have done) "maybe I can use
tools like AppFabric Workflow to orchestrate all these small tasks".

~~~
mullr
When you say that a background task should be made into a RESTful API call, I
assume you mean that instead of spinning up a local thread to do the work you
should defer it to another service. Certainly you can do that, but async/await
is still relevant in that case.

The key question is: while said REST call is happening, what is the caller
doing? Normally, he's sitting there and blocking his thread until the call
finishes (i.e. consuming one thread from the connection thread pool). With
async/await, the thread is released back into the thread pool until the result
is ready, then it picks up where it left off.

So anything where you might want to deal with background operations that take
a long time (including network / db / filesystem access, i.e. most
applications that aren't pure functions) in a connection-oriented system can
greatly benefit from async/await. Even if it's just a regular desktop app, it
appears to be a useful mechanism for coordinating different background tasks.

~~~
d4nt
Your point is a good one. Without wanting to get too deep into a design for
some hypothetical system, I guess I was thinking that I'd either try and
modify the current request such that it can return something to its caller
(e.g. Render a web page saying "Loading..." with a setTimeout call in it). Or
use .NET's HTTP request library which has a delegate callback option that lets
you get on with other stuff.

~~~
jbrechtel
One benefit to something like async/await is letting you get on with other
stuff without having to murk up your code with callbacks/delegates which read
more like GOTOs than async/await.

------
earlz
The single biggest problem I have with async/await in C# is how it requires an
act of god to call an async(await) method from a non-async method. And even
then, wrapping exceptions and such is a huge pain as well.

I would love async if it was completely optional and I could call async code
from a synchronous context. Like if I could just say `var tmp=await Foo();`
within a synchronous method (and it just ran Foo on the current thread and
blocked)..

Instead, it requires one of the methods outlined here:
[http://stackoverflow.com/questions/5095183/how-would-i-
run-a...](http://stackoverflow.com/questions/5095183/how-would-i-run-an-async-
taskt-method-synchronously)

~~~
sequence7
So why don't you just define a non async method (A) and then one that is async
(B) that calls A? If you want to run async then call B if not then call A.

If you could define a method as async and then call it either syncronously or
not the whole point of the async keyword is lost. You would end up with the
compiler doing a load of work because every developer will just slap async on
every method just in case rather than actually thinking about what needs to be
async and what doesn't.

Adding the async keyword is not a magic bullet, there's a huge amount of work
going on under the hood every time you use it and it's important that
developers appreciate that.

~~~
earlz
The problem with your two-method suggestion is that it's usually not /me/ I'm
concerned about. The problem is usually things like "I need to open this file
from a synchronous context in a Windows Store App". The problem is that with
Windows Store (where async is suppose to shine), async is the rule, not the
exception

Also, two methods sharing the same code sounds absolutely horrible.

~~~
sequence7
Method B calls A it doesn't share any code and it is then explicit that one
method is async and the other is not. You want to do two different things so
why not have two methods?

------
TheAnimus
The problem that I keep seeing is people think that TPL or Async/Await heck,
even Rx is a Threading library....

As a result people still use monitors or any kind of blocking wait event.
Including the TaskCompletetionSource in the framework I don't think helped
this.

A lot of what I've seen on different projects using these newer tools is an
attempt to re-create what they would do before. Doing a Producer Consumer,
that's a blocking de-queue etc.

~~~
Strilanc
What's wrong with TaskCompletionSource? I use it constantly. It's great for
translating other async styles (like passing a callback as the last argument)
into tasks.

How would you implement Observable.LastAsync, without using something
equivalent to TaskCompletionSource along the way?

~~~
danabramov
I think your parent is arguing that, _despite_ TaskCompletionSource exists,
some people _still_ don't use it much and resort to callbacks (presumably
because they have not learned about it).

As in “adding TaskCompletionSource to the framework didn't help some folks
adjusting to Task style, and they keep using callbacks”.

~~~
Strilanc
Ah, that makes sense.

------
grandpoobah
"Everything .NET programmers know about Asynchronous Programming in ASP.NET is
wrong" would perhaps be a better title.

~~~
300bps
I would've gone with, "Over 14 Month Old Podcast Makes Overly Broad Claims to
Linkbait" as a headline.

------
gchokov
That's pretty bold statement. And it's not true.

------
jamieomatthews
After listening, I don't think they mention Task.Factory.StartNew, this is how
I usually throw things into the background. Whats wrong with this approach?

~~~
bigdubs
Nothing per se, but the TPL uses the thread pool as well.

------
cgtyoder
.NET != ASP.NET

------
sauravt
on a related news, [http://www.everything.net](http://www.everything.net) ,
records a sudden surge in traffic.

------
kyberias
This is from 2012.

