We Keep Coding

Await with and without task assigning

Consider a little function:
private async Task LittleFunction()
{
var operand = new SomeObject();
var notUsedResult = await SomeAsyncOperationWith(operand); // 1
// OR
await SomeAsyncOperationWith(operand); // 2
SomeOtherOperationsWith(operand);
}
Is there any difference between 1 and 2? I know about context and other task properties I can use, but now I'm interesting in differences in state machines behavior. Thanks.

There is no appreciable difference in the 2 methods and if anything they will result in the same IL, however you can prove this for your self with a .net disassembler.
I think the more interesting point of this question is
but now I'm interesting in differences in state machines behavior.
How the state machine works is an implementation detail and likely to change from version to version (and has changed a lot since async was first implemented).
What you should be concerned with is your environment, if you have a performance issue you should use a profiler, or benchmark framework and not second guess the internals of the CLR and Jitter

There is no difference between these two; though if you do not require an assignment, in my opinion it's better to skip it for improved readability (i.e. should the methods have more going on than the simple examples above, by not introducing a new variable then no one needs to mentally keep track of notUsedResult (though your naming does a good job of that anyway).
// 1
private async Task LittleFunction()
{
var operand = new SomeObject();
var notUsedResult = await SomeAsyncOperationWith(operand);
SomeOtherOperationsWith(operand);
}
// 2
private async Task LittleFunction()
{
var operand = new SomeObject();
await SomeAsyncOperationWith(operand);
SomeOtherOperationsWith(operand);
}
There is, however, a third option:
// 3
private async Task LittleFunction()
{
var operand = new SomeObject();
var task = SomeAsyncOperationWith(operand);
SomeOtherOperationsWith(operand);
await task;
}
This is different to the above in that SomeAsyncOperationWith is called before SomeOtherOperationsWith, but may not complete until afterwards. This is better if there's no dependency between the two tasks as it allows the function to execute the SomeOtherOperationsWith logic whilst it's waiting on any IO / long running operation going on in SomeAsyncOperationWith (i.e. this is the benefit of using async in the first place). Of course, if there is a dependency to have the SomeAsyncOperationWith task complete before SomeOtherOperationsWith, you'll need to stick with one of your original solutions.

The implementation of SomeAsyncOperationWith(operand); is responsible for creating a Task, scheduling any work which cannot be immediately completed to occur at appropriate times and deciding when to mark the Task that it returns as Completed, Cancelled or Faulted.
It neither knows, nor cares, about what any calling method does with that returned Task nor the Result that the Task ends up containing.
Nothing about the "state machine" (if such even exists) is exposed to the caller.

Is an async function returning a Task usable only by an async function?

I am trying to wade through the async functionality (C# .NET) and was curious whether an async function which returns a Task (i.e. promise) is always usable in an async function ONLY. Compiler and documentation indicate this of course, but I wanted to see if I am missing something which gets around this.
For example, the ReturnRandomIntegerAsync(i) returns a Task. Note that the while loop which runs every 5 seconds is faster than the function which takes 7 seconds :
void MyFunction(){
while(true)
{
i++;
var sw = Stopwatch.StartNew();
Thread.Sleep(5000);
Task<int> j = ps.ReturnRandomIntegerAsync(i);// Call to an async
// method which has a sleep for 7 seconds (and awaits for sleep to be over))
// **OUTPUT j**.
sw.Stop();
var timespan = sw.Elapsed;
Console.WriteLine("Elapsed time : " + timespan.Seconds + "\n\n");// Time taken for this iteration.
}
}
In this example, I cannot do an await on the ps.ReturnRandomIntegerAsync(i) unless I make the MyFunction() an async one. If I don't, then j is meaningless. If I do a .Result on the ps.ReturnRandomIntegerAsync(i), then it breaks async and the elapsed time (last line in while loop) shows 12 seconds (5 in the loop + 7 in the method).
If I want the value of j in every loop iteration ,the only solution I can think of in this scenario is to have j stored somewhere (array, collection etc.) by the async method and then retrieved later.
Would that be the correct approach ?

No you don't need to use an async method to use a Task. The async keyword is simply a language feature that makes working with asynchronous operations more convenient. You can use the actual operations on Task itself (most notably ContinueWith) when writing a method and do it "the old way" if you want.
Alternatively some methods can be written entirely by composing other Task returning methods, and may not need to be async themselves.
Of course, it will indeed be quite common for methods you write that use Task instances to be async. Situations in which it's unnecessary aren't super common, and writing things out by hand, without using the language feature, is almost always way more work and doesn't have a suitable benefit.

You can certainly store tasks and await them later.
Task.WhenAll is a common use case for this:
var task1 = SomethingAsync();
var task2 = SomethingElseAsync();
// Both operations are "in flight" at this point.
// Asynchronously wait for them both to complete.
await Task.WhenAll(task1, task2);
Another example is for long-lived "main loop" kind of tasks. For example, a task that continually reads from a network stream. In this case, you want to eventually "join" with the task to be able to detect exceptions. My preferred method of doing this is to await the task in an async Task (or - very rarely - an async void) method, but you could also use ContinueWith to detect those exceptions.

What is the difference between these two asynchronous methods?

What's difference between this two asynchronous methods? If didn't, In which situation this two kind of methods can was different?
Thanks.
public async Task<int> MyMethod1Async()
{
return 1;
}
public async Task<int> MyMethod2Async()
{
return await new Task<int>(() => 1);
}

Taking a look at the two methods:
public async Task<int> MyMethod1Async()
{
return 1;
}
This will run synchronously because there are no "await" operators in it - it just returns 1, so it's no different than if you had just done the following:
public int MyMethod1()
{
return 1;
}
The following method is probably a better illustration of the difference between different "types" of async:
public async Task<string> MyMethod1Async()
{
using (HttpClient client = new HttpClient())
{
client.BaseAddress = new Uri("SomeBaseAddress");
// This will return control to the method's caller until this gets a result from the server
HttpResponseMessage message = await client.GetAsync("SomeURI");
// The same as above - returns control to the method's caller until this is done
string content = await message.Content.ReadAsStringAsync();
return content;
}
}
Code like this won't necessarily spawn extra threads (unless that's how Microsoft happened to have implemented those particular library calls). Either way, await/async does not require the creation of additional threads; it can run asynchronously on the same thread.
My standard illustration of this fact is as follows: suppose you go a restaurant with 10 people. When the waiter comes by, the first person he asks for his order isn't ready; however, the other 9 people are. Thus, the waiter asks the other 9 people for their orders and then comes back to the original guy hoping he'll be ready to order by then. (It's definitely not the case that they'll get a second waiter to wait for the original guy to be ready to order and doing so probably wouldn't save much time anyway). That's how async/await works in many cases (the exception being that some of the Task Parallel library calls, like Thread.Run(...), actually are executing on other threads - in our illustration, bringing in a second waiter - so make sure you check the documentation for which is which).
The next item you list won't work because you just create the task, you don't actually do anything with it:
public async Task<int> MyMethod2Async()
{
return await new Task<int>(() => 1);
}
I'm assuming that you actually intended to do something like the following:
public async Task<int> MyMethod2Async()
{
return await Task.Run<int>(() => 1);
}
This will run the lambda expression in the thread pool, return control to MyMethod2Async's caller until the lambda expression has a result, and then return the value from the lambda expression once it does have a result.
To summarize, the difference is whether you're running asynchronously on the same thread (equivalent to the first guy at your table telling the waiter to come back to him after everyone else has ordered) or if you're running the task on a separate thread.
At risk of oversimplifying things a lot, CPU-bound tasks should generally be run asynchronously on a background thread. However, IO-bound tasks (or other cases where the holdup is mostly just waiting for some kind of result from an external system) can often be run asynchronously on the same thread; there won't necessarily be much of a performance improvement from putting it on a background thread vs. doing it asynchronously on the same thread.

The first method returns an already completed task with a Result of 1.
The second method returns a Task<int> that will never complete.

From the point of view of the caller, how is calling an asynchronous method any different than calling a synchronous method?

What I don't understand is the following snippet from MSDN:
Note that the method is now marked with the new async keyword; this is
simply an indicator to the compiler that lets it know that in the
context of this method, the keyword await is to be treated as a point
where the workflow returns control to its caller and picks up again
when the associated task is finished.
How is that any different than how non-async methods work?
If I do
int x;
x = SomeNormalFunctionThatReturnsAnInt();
Console.WriteLine(x);
or
int x;
Task<int> task = SomeAsyncFunctionThatReturnsAnInt();
x = await task;
Console.WriteLine(x);
then from the perspective of the caller, the order of execution is the exact same: an int named x is defined, a function that returns an int is run, and when that funcion is done running, its return value is set to x, which is then written to the console.

from the perspective of the caller, the order of execution is the exact same
Yes and no.
If you await all tasks as soon as they are returned to you, then yes, that method in isolation is seeing the same "order of execution". This is actually the entire point of async/await - it allows writing most asynchronous code in a way that is very natural and similar to equivalent synchronous code.
However, the caller must be aware that it has to be asynchronous. That is, the caller generally uses await, which means that it must be async. There are some added twists that come in with asynchronous code. One example: if this is executed on a UI thread, then synchronous code knows that nothing else can execute on the UI thread between SomeNormalFunctionThatReturnsAnInt and Console.WriteLine; however, asynchronous code uses await, so it must accept that anything else can execute on the UI thread between SomeAsyncFunctionThatReturnsAnInt and Console.WriteLine. So, looking at it from that context, it's not the exact same; asynchronous methods may have their "order of execution" paused while other code runs.

If you weren't waiting the result of the function x could be not initialized. But here you wait for it so there is no difference.

you need to have some read on the async and sync to see what happens in performance level ,
in your example the result is not different as you are saying the method to wait in line of await but lets have a look at the following code snippet
class Program {
private static string result;
static void Main() {
SaySomething();
Console.WriteLine(result);
}
static async Task<string> SaySomething() {
await Task.Delay(5);
result = "Hello world!";
return “Something”;
}
}
can you try to calculate the output, the result is nothing, why ?
with the await we let the main task continue as we wait 5 milliseconds before returning result, have a look at
https://msdn.microsoft.com/en-gb/library/mt674882.aspx

Task.Run with Parameter(s)?

I'm working on a multi-tasking network project and I'm new on Threading.Tasks. I implemented a simple Task.Factory.StartNew() and I wonder how can I do it with Task.Run()?
Here is the basic code:
Task.Factory.StartNew(new Action<object>(
(x) =>
{
// Do something with 'x'
}), rawData);
I looked into System.Threading.Tasks.Task in Object Browser and I couldn't find a Action<T> like parameter. There is only Action that takes void parameter and no type.
There are only 2 things similiar: static Task Run(Action action) and static Task Run(Func<Task> function) but can't post parameter(s) with both.
Yes, I know I can create a simple extension method for it but my main question is can we write it on single line with Task.Run()?

private void RunAsync()
{
//Beware of closures. String is immutable.
string param = "Hi";
Task.Run(() => MethodWithParameter(param));
}
private void MethodWithParameter(string param)
{
//Do stuff
}
Edit
Due to popular demand I must note that the Task launched will run in parallel with the calling thread. Assuming the default TaskScheduler this will use the .NET ThreadPool. Anyways, this means you need to account for whatever parameter(s) being passed to the Task as potentially being accessed by multiple threads at once, making them shared state. This includes accessing them on the calling thread.
In my above code that case is made entirely moot. Strings are immutable. That's why I used them as an example. But say you're not using a String...
One solution is to use async and await. This, by default, will capture the SynchronizationContext of the calling thread and will create a continuation for the rest of the method after the call to await and attach it to the created Task. If this method is running on the WinForms GUI thread it will be of type WindowsFormsSynchronizationContext.
The continuation will run after being posted back to the captured SynchronizationContext - again only by default. So you'll be back on the thread you started with after the await call. You can change this in a variety of ways, notably using ConfigureAwait. In short, the rest of that method will not continue until after the Task has completed on another thread. But the calling thread will continue to run in parallel, just not the rest of the method.
This waiting to complete running the rest of the method may or may not be desirable. If nothing in that method later accesses the parameters passed to the Task you may not want to use await at all.
Or maybe you use those parameters much later on in the method. No reason to await immediately as you could continue safely doing work. Remember, you can store the Task returned in a variable and await on it later - even in the same method. For instance, once you need to access the passed parameters safely after doing a bunch some other work. Again, you do not need to await on the Task right when you run it.
Anyways, a simple way to make this thread-safe with respect to the parameters passed to Task.Run is to do this:
You must first decorate RunAsync with async:
private async void RunAsync()
Important Notes
Preferably the method marked async should not return void, as the linked documentation mentions. The common exception to this is event handlers such as button clicks and such. They must return void. Otherwise I always try to return a Task or Task<TResult> when using async. It's good practice for a quite a few reasons.
Now you can await running the Task like below. You cannot use await without async.
await Task.Run(() => MethodWithParameter(param));
//Code here and below in the same method will not run until AFTER the above task has completed in one fashion or another
So, in general, if you await the task you can avoid treating passed in parameters as a potentially shared resource with all the pitfalls of modifying something from multiple threads at once. Also, beware of closures. I won't cover those in depth but the linked article does a great job of it.
Regarding Run and StartNew the code below I find most important to know, really. There are legitimate reasons to use either, neither is obsolete or "better" than the other. Be aware simply replacing one with the other is a very bad idea unless you understand this:
//These are exactly the same
Task.Run(x);
Task.Factory.StartNew(x, CancellationToken.None,
TaskCreationOptions.DenyChildAttach, TaskScheduler.Default);
//These are also exactly the same
Task.Factory.StartNew(x);
Task.Factory.StartNew(x, CancellationToken.None,
TaskCreationOptions.None, TaskScheduler.Current);
Side Notes
A bit off topic, but be careful using any type of "blocking" on the WinForms GUI thread due to it being marked with [STAThread]. Using await won't block at all, but I do sometimes see it used in conjunction with some sort of blocking.
"Block" is in quotes because you technically cannot block the WinForms GUI thread. Yes, if you use lock on the WinForms GUI thread it will still pump messages, despite you thinking it's "blocked". It's not.
This can cause bizarre issues in very rare cases. One of the reasons you never want to use a lock when painting, for example. But that's a fringe and complex case; however I've seen it cause crazy issues. So I noted it for completeness sake.

Use variable capture to "pass in" parameters.
var x = rawData;
Task.Run(() =>
{
// Do something with 'x'
});
You also could use rawData directly but you must be careful, if you change the value of rawData outside of a task (for example a iterator in a for loop) it will also change the value inside of the task.

From now you can also :
Action<int> action = (o) => Thread.Sleep(o);
int param = 10;
await new TaskFactory().StartNew(action, param)

I know this is an old thread, but I wanted to share a solution I ended up having to use since the accepted post still has an issue.
The Issue:
As pointed out by Alexandre Severino, if param (in the function below) changes shortly after the function call, you might get some unexpected behavior in MethodWithParameter.
Task.Run(() => MethodWithParameter(param));
My Solution:
To account for this, I ended up writing something more like the following line of code:
(new Func<T, Task>(async (p) => await Task.Run(() => MethodWithParam(p)))).Invoke(param);
This allowed me to safely use the parameter asynchronously despite the fact that the parameter changed very quickly after starting the task (which caused issues with the posted solution).
Using this approach, param (value type) gets its value passed in, so even if the async method runs after param changes, p will have whatever value param had when this line of code ran.

Just use Task.Run
var task = Task.Run(() =>
{
//this will already share scope with rawData, no need to use a placeholder
});
Or, if you would like to use it in a method and await the task later
public Task<T> SomethingAsync<T>()
{
var task = Task.Run(() =>
{
//presumably do something which takes a few ms here
//this will share scope with any passed parameters in the method
return default(T);
});
return task;
}

It's unclear if the original problem was the same problem I had: wanting to max CPU threads on computation inside a loop while preserving the iterator's value and keeping inline to avoid passing a ton of variables to a worker function.
for (int i = 0; i < 300; i++)
{
Task.Run(() => {
var x = ComputeStuff(datavector, i); // value of i was incorrect
var y = ComputeMoreStuff(x);
// ...
});
}
I got this to work by changing the outer iterator and localizing its value with a gate.
for (int ii = 0; ii < 300; ii++)
{
System.Threading.CountdownEvent handoff = new System.Threading.CountdownEvent(1);
Task.Run(() => {
int i = ii;
handoff.Signal();
var x = ComputeStuff(datavector, i);
var y = ComputeMoreStuff(x);
// ...
});
handoff.Wait();
}

Idea is to avoid using a Signal like above.
Pumping int values into a struct prevents those values from changing (in the struct).
I had the following Problem: loop var i would change before DoSomething(i) was called (i was incremented at end of loop before ()=> DoSomething(i,ii) was called). With the structs it doesn't happen anymore. Nasty bug to find: DoSomething(i, ii) looks great, but never sure if it gets called each time with a different value for i (or just a 100 times with i=100), hence -> struct
struct Job { public int P1; public int P2; }
…
for (int i = 0; i < 100; i++) {
var job = new Job { P1 = i, P2 = i * i}; // structs immutable...
Task.Run(() => DoSomething(job));
}

There is another way of doing this. I found it useful.
int param;
ThreadPool.QueueUserWorkItem(someMethod, param);
void someMethod(object parameter){
var param = (int) parameter;
// do the job
}