|C# Guru - An Interview With Eric Lippert|
|Written by Nikos Vaggalis|
|Thursday, 10 April 2014|
Page 3 of 4
NV: Could you clarify when to use await and when Task.Run?
EL: The two do very different things.
Task.Run means “here’s some code that does some high-latency work. Please immediately give me a Task which represents this work, so that this thread can continue to run normally. At some point in the future, find an idle thread in the thread pool and execute the work on that thread. When the work is done, let the Task object you created know that fact.”
By contrast, await task means “I already have a task object which represents some high-latency work. This method is unable to do any more of its work until the high-latency work is complete. Therefore, return from this method immediately so that this thread can continue to do more work. At some time after the task is complete, resume execution of this method at the point where we left off.”
NV: Where does the Statemachine and the Synchronization context fit into it?
Both are mechanisms that work together to determine where and how a method which did an await gets resumed when the awaited task is completed.
When you use await in a C# method, the compiler transforms the code into a state machine, the details of which are a bit complicated to explain. Basically by a state machine we mean code where there is a number – the state of the machine – that says at what point in the code the method should be resumed at when the task is complete. This is an implementation detail of the compiler, and not something you typically have to worry about.
The synchronization context determines whether the method resumes on the same thread that it awaited on. For example, in a Windows Forms application we would expect that a method that awaited on the UI thread would resume on the UI thread. But if we awaited on a worker thread in a console application, it seems reasonable that the method could be resumed on any worker thread; after all, the one that actually did the awaiting might be busy doing something else when the task completes.
EL: Ah, good question.
EL: Any system that allows efficient code reuse without having to establish a sub-typing relationship, I think is worth looking into.
EL: Let me break that down into a couple of questions.
Will there be a C# 6.0? Yes, that's been announced.
Will there be breaking changes?
For example, something I faced all the time on the compiler team was
"in this obscure case we are allowing the program to compile, but the resulting program doesn't make any sense and according to the spec it should be an error".
In those unfortunate cases we would get a small committee together to argue out the likelihood of breaking any customer vs the value of getting the compiler correct. In a lot of those cases we kept the compiler technically wrong, just to avoid accidentally breaking someone who had a crazy program. The bar is pretty high for breaking changes.
EL:I am under NDA and cannot discuss it in details, so I will only discuss what Mads Torgersen has already disclosed in public. Mads did a "Future of C#" session in December of last year. He discussed eight or nine features that the C# language design team is strongly considering for C# 6.0. If you read that list carefully -- Wesner Moise has a list here
- you'll see that there is no "major headliner" feature.
I'll leave you to draw your own conclusions from that list.
Incidentally, I knew Wesner slightly in the 1990s. Among his many claims to fame is he invented the pivot table. Interesting guy.
NV: Java as tortured as it might be, revitalizes itself due to Linux and the popularity of mobile devices. Does .NET's and C#'s future depend on the successful adoption of Windows by the mobile devices ?
EL: That's a complicated question, as are all predictions of the future.
But by narrowly parsing your question and rephrasing it into an -- I hope -- equivalent form, I think it can be answered. For the future of technology X to depend on the success of technology Y means "we cannot conceive of a situation in which Y fails but X succeeds".
So, can we conceive of a situation in which the market does not strongly adopt Windows on mobile devices, but C# is adopted on mobile devices? Yes, absolutely we can conceive of such a situation.
Xamarin's whole business model is predicated on that conception. They've got C# code running on Android, so C# could continue to have a future on the mobile platform even if Windows does not get a lot of adoption.
Or, suppose both Microsoft fails to make headway on Windows on mobile and Xamarin fails to make headway on C# on Android, etc. Can we conceive of a world in which C# still has a future? Sure.
Mobile is an important part of the ecosystem, but it is far from the whole thing. There are lots of ways that C# could continue to thrive even if it is not heavily adopted as a language for mobile devices.
If the question is the more general question of "is C# going to thrive?" I strongly believe that it is. It is extremely well placed: a modern programming language with top-notch tools and a great design and implementation team.
|Last Updated ( Thursday, 10 April 2014 )|