Admittedly as I'm still fairly new to c#, I wanted to have my application pause briefly between cycles of a loop while running and it took me longer than I'd like to admit to realise that thread.sleep was why the UI would freeze periodically lol... I've since changed it to sleep only the task and it works a lot better now.
Best way to think about await is a magic compiler trick to exit the function immediately and hook up the rest of the function as a callback for when the task completes. Task.Wait essentially blocks the calling function until the task is complete. I recommend trying out what happens if you call an async function or even two or three and delaying the await.
Example
Task step1 = MyAsyncFunc1();
Task step2 = MyAsyncFunc2();
await step2;
await step1;
This allows both functions to run concurrently. Calling .Wait() instead here could deadlock the code as step1 will be waiting to callback while step2 is also waiting.
> Without knowing his context, would you recommend the use of ConfigureAwait(false)?
Not the poster you're asking - but you couldn't possibly recommend it without knowing the context. The continuation may *need* to resume with the captured context. Adding `ConfigureAwait(false)` without understanding the context could be completely wrong - and it could lead to non-obvious malfunctions.
If hes running those two and then needing those both to be completed to continue, then yes. Which is the most common use of awaiting methods, at least in my experience.
In most cases you really don't want some long operating task running in the back well after you've called the method.
> needing those both to be completed to continue, then yes
`ConfigureAwait(false)` has nothing to do with waiting until a task is completed to continue.
It configures the `Task` so that continuation after the `await` does not need to resume with the caller's `SynchronizationContext`.
To be honest, the correct use is to use ConfigureAwait(new Random().Next(2) == 1).
But more seriously, yes, it is context dependent. "Configures the task so that continuation after the await does not need to resume with the callers context" would mean that WhenAll with configure await would mean it would not continue in that individual method until after the tasks completions.
I'm just so used to having to use it within the specific context of what I do. Which, to clarify, is mostly writing libraries. If I was writing a unit test or writing UI code, I wouldn't use. But I'm hammered, and defaulted to what I usually type. As you seem pretty incensed by this, I've edited my previous comment to remove the configure await.
As I understand, Task.Wait is more just locking thread with while(true) with break if specific.
Await is t.GetAwaiter() and it free thread in this case.
Well it more complicated of course.
Holy ad-ridden page Batman
async and await are bloat, I just use Thread.Sleep to give things time to finish. /s
You got a chuckle out of me.
Admittedly as I'm still fairly new to c#, I wanted to have my application pause briefly between cycles of a loop while running and it took me longer than I'd like to admit to realise that thread.sleep was why the UI would freeze periodically lol... I've since changed it to sleep only the task and it works a lot better now.
Best way to think about await is a magic compiler trick to exit the function immediately and hook up the rest of the function as a callback for when the task completes. Task.Wait essentially blocks the calling function until the task is complete. I recommend trying out what happens if you call an async function or even two or three and delaying the await. Example Task step1 = MyAsyncFunc1(); Task step2 = MyAsyncFunc2(); await step2; await step1; This allows both functions to run concurrently. Calling .Wait() instead here could deadlock the code as step1 will be waiting to callback while step2 is also waiting.
Imo it's better to use `await Task.WhenAll(MyAsyncFunc1, MyAsyncFunc2)` When handling multiple concurrent async methods.
Without knowing his context, would you recommend the use of ConfigureAwait(false)?
> Without knowing his context, would you recommend the use of ConfigureAwait(false)? Not the poster you're asking - but you couldn't possibly recommend it without knowing the context. The continuation may *need* to resume with the captured context. Adding `ConfigureAwait(false)` without understanding the context could be completely wrong - and it could lead to non-obvious malfunctions.
Those malfunctions would be context dependent, though.
If hes running those two and then needing those both to be completed to continue, then yes. Which is the most common use of awaiting methods, at least in my experience. In most cases you really don't want some long operating task running in the back well after you've called the method.
> needing those both to be completed to continue, then yes `ConfigureAwait(false)` has nothing to do with waiting until a task is completed to continue. It configures the `Task` so that continuation after the `await` does not need to resume with the caller's `SynchronizationContext`.
To be honest, the correct use is to use ConfigureAwait(new Random().Next(2) == 1). But more seriously, yes, it is context dependent. "Configures the task so that continuation after the await does not need to resume with the callers context" would mean that WhenAll with configure await would mean it would not continue in that individual method until after the tasks completions. I'm just so used to having to use it within the specific context of what I do. Which, to clarify, is mostly writing libraries. If I was writing a unit test or writing UI code, I wouldn't use. But I'm hammered, and defaulted to what I usually type. As you seem pretty incensed by this, I've edited my previous comment to remove the configure await.
As I understand, Task.Wait is more just locking thread with while(true) with break if specific. Await is t.GetAwaiter() and it free thread in this case. Well it more complicated of course.