This question has already been answered:

I do not understand why ConfigureAwait(true) can cause trouble?

Here is a sample code:

 private async void button1_Click(object sender, EventArgs e) { int result = DoSomeWorkAsync().Result; // 1 } private async Task<int> DoSomeWorkAsync() { await Task.Delay(100).ConfigureAwait(true); //2 return 1; }

Here is its description, but whether there is a typo / curve translation or something I do not understand. Why deadlock ?:

Clicking on the button here leads to deadlock. The UI thread starts a new I / O thread on line “2” and goes to sleep on line “1”, waiting for the completion of work. After the I / O thread finishes executing, the rest of the DoSomeWorkAsync method is passed to the calling (UI) thread for execution. But he is at this time in sleep mode, waiting for the completion of the method. Dedlock.

Marked as a duplicate by MSDN.WhiteKnight , Pavel Mayorov members. c # Dec 14 '18 at 6:42 .

A similar question was asked earlier and an answer has already been received. If the answers provided are not exhaustive, please ask a new question .

    2 answers 2

    Personally, I did not understand the explanation @ tym32167. I had to start the applique myself and eat what happens ...

    So...

    Asynchronous method call:

     int result = await DoSomeWorkAsync();

    Synchronous call asynchronous method:

     int result = DoSomeWorkAsync().Result; // то есть мы ждем пока не будет результата готового

    Now we are looking at the interior of the DoSomeWorkAsync () method:

     await Task.Delay(100).ConfigureAwait(true); return 1;

    .ConfigureAwait (true) - the configuration of the task itself. Configuring a task is done from the UI stream, and not from inside the task itself.

    Deadlock comes out for the reason that two conflicting tasks are set before the computer:

    • do not go to the main thread [to get the result of a synchronous method call]
    • (inside the method) go to the main thread [to change the configuration of the task]
    • 2
      @ tym32167 - forgive me for writing + - the same thing as you ... I just didn’t like you voosche .... So, he wouldn’t like you either, most likely .... - Andrew
    • one
      And what in my answer caused you difficulties? You described exactly the same thing as me. - tym32167
    • one
      :) no problem, let the author of the question have a choice, two answers are better than one - tym32167
    • 2
      when I read the answer - I just did not understand what exactly was written there. I read it again - I still did not understand. It dawned on me that it was written there only after he himself had played with the code in the visualizer) Therefore, I decided to paint the same thing separately. I think the question here is not the incorrectness of your answer as such ... Just not enough clear wording of the explanation :) At least for me personally. And I simply did not dare to rule your answer with my words - somehow it is wrong. - Andrew
    • 2
      Aha, probably, it was necessary to paint in more detail, thanks, I will consider for the future. - tym32167

    Because the challenge

     int result = DoSomeWorkAsync().Result; // 1

    Blocks the UI thread until the task that is inside is fully completed. And taske to complete here

     await Task.Delay(100).ConfigureAwait(true); //2 return 1; // вот тут, в продолжении

    So, in order to complete the task, you need to jump into the UI stream, but it cannot jump into the UI stream, since the UI stream is blocked by itself.

    That is, the continuation of the task waits for the task to end, and the task, in order to end, must be continued. On the face of deadlock.