C＃とF＃の非同期。C＃の非同期の落とし穴

こんにちは、Habr！TomasPetricekによる記事「AsyncinC＃およびF＃Asynchronous gotchas in C＃」の翻訳を紹介します。



2月に、マイクロソフトがMVPのために主催するイベントである年次MVPサミットに参加しました。この機会にボストンとニューヨークを訪れ、F＃について2回講演し、チャンネル9のタイププロバイダーに関する講演を録音しました。他の活動（パブへの訪問、F＃について他の人とのチャット、朝の長い昼寝など）にも関わらず、私はいくつかの議論をすることもできました。







（NDAの下ではない）1つの議論は、C＃5.0の新しいキーワードについての非同期クリニックの話でした-非同期と待機。 LucianとStephenは、非同期プログラムを作成するときにC＃開発者が直面する一般的な問題について話しました。この投稿では、F＃の観点からいくつかの問題を見ていきます。会話は非常に活発で、誰かがF＃の聴衆の反応を次のように説明しました:(





F＃で書いているMVPがC​​＃のコード例を見るとき、彼ら



は女の子のようにくすくす笑います）なぜこれが起こっているのですか？ F＃非同期モデル（F＃1.9.2.7に登場、2007年にリリースされ、Visual Studio 2008に同梱）を使用すると、よくある間違いの多くが発生しない（または発生する可能性がはるかに低い）ことがわかりました。

落とし穴＃1：非同期が非同期で機能しない

C＃非同期プログラミングモデルの最初のトリッキーな側面に直接ジャンプしましょう。次の例を見て、行が印刷される順序を想像してみてください（トークに示されている正確なコードは見つかりませんでしたが、Lucianが同様のことを示したことを覚えています）。

  async Task WorkThenWait()
  {
      Thread.Sleep(1000);
      Console.WriteLine("work");
      await Task.Delay(1000);
  }
 
  void Demo() 
  {
      var child = WorkThenWait();
      Console.WriteLine("started");
      child.Wait();
      Console.WriteLine("completed");
  }

「開始」、「作業」、「完了」が印刷されると思うなら、あなたは間違っています。コードは「work」、「started」、「completed」を出力します。自分で試してみてください。作成者は、（WorkThenWaitを呼び出して）作業を開始し、タスクが完了するのを待ちたいと考えていました。問題は、WorkThenWaitが重い計算（ここではThread.Sleep）を実行することから始まり、その後でのみawaitを使用することです。



C＃では、asyncメソッドの最初のコードが（呼び出し元のスレッドで）同期的に実行されます。これを修正するには、たとえば、最初にawait Task.Yield（）を追加します。

対応するF＃コード

F＃では、これは問題ではありません。F＃で非同期コードを作成する場合、非同期{…}ブロック内のすべてのコードは延期され、後で実行されます（明示的に実行した場合）。上記のC＃コードは、F＃の以下に対応します。

let workThenWait() = 
    Thread.Sleep(1000)
    printfn "work done"
    async { do! Async.Sleep(1000) }
 
let demo() = 
    let work = workThenWait() |> Async.StartAsTask
    printfn "started"
    work.Wait()
    printfn "completed"
  

明らかに、workThenWait関数は非同期計算の一部として作業（Thread.Sleep）を実行せず、関数が呼び出されたときに実行されます（非同期ワークフローの開始時ではありません）。F＃の一般的なパターンは、関数の本体全体を非同期でラップすることです。F＃では、次のように記述します。これは期待どおりに機能します。

let workThenWait() = async
{ 
    Thread.Sleep(1000)
    printfn "work done"
    do! Async.Sleep(1000) 
}
  

落とし穴＃2：結果を無視する

C＃非同期プログラミングモデルの別の問題があります（この記事はLucianのスライドから直接引用しています）。次の非同期メソッドを実行するとどうなるかを推測します。

async Task Handler() 
{
   Console.WriteLine("Before");
   Task.Delay(1000);
   Console.WriteLine("After");
}
 

「前」と表示され、1秒待ってから「後」と表示されると思いますか？違う！両方のメッセージは、中間の遅延なしに一度​​に出力されます。問題は、Task.Delayがタスクを返すことであり、それが完了するまで待つのを忘れていました（awaitを使用）。

対応するF＃コード

繰り返しますが、おそらくF＃ではこれに遭遇しなかったでしょう。Async.Sleepを呼び出し、返されたAsyncを無視するコードを簡単に記述できます。

let handler() = async
{
    printfn "Before"
    Async.Sleep(1000)
    printfn "After" 
}
 

このコードをVisualStudio、MonoDevelop、またはTry F＃に貼り付けると、すぐに警告が表示されます。

警告FS0020：この式のタイプはunitである必要がありますが、タイプはAsync ‹unit›です。式の結果を破棄するにはignoreを使用するか、結果を名前にバインドします。

警告FS0020：この式はタイプunitである必要がありますが、タイプAsync ‹unit›です。式の結果を破棄するにはignoreを使用するか、結果を名前に関連付けます。

コードをコンパイルして実行することはできますが、警告を読むと、式がAsyncを返すことがわかり、do ！：を使用してその結果を待つ必要があります。

let handler() = async 
{
   printfn "Before"
   do! Async.Sleep(1000)
   printfn "After" 
}
 

落とし穴＃3：無効を返す非同期メソッド

会話のかなりの部分が非同期voidメソッドに向けられました。 async void Foo（）{…}と書くと、C＃コンパイラはvoidを返すメソッドを生成します。しかし、内部では、タスクを作成して実行します。これは、作業が実際にいつ行われるかを予測できないことを意味します。



スピーチでは、非同期ボイドパターンの使用に関して次の推奨事項が作成されました。





（天国のために、非同期ボイドの使用を停止し



てください！）公平を期すために、非同期ボイドメソッドは次のことができることに注意してください。イベントハンドラーを作成するときに役立ちます。イベントハンドラーはvoidを返す必要があり、バックグラウンドで継続する作業を開始することがよくあります。しかし、これがMVVMの世界で実際に役立つとは思いません（ただし、会議でのデモは確かに優れています）。C＃での非同期プログラミングに関するMSDNMagazineの記事の



抜粋を使用して問題を示します。

async void ThrowExceptionAsync() 
{
    throw new InvalidOperationException();
}

public void CallThrowExceptionAsync() 
{
    try 
    {
        ThrowExceptionAsync();
    } 
    catch (Exception) 
    {
        Console.WriteLine("Failed");
    }
}
 

このコードは「失敗」と表示されると思いますか？この記事のスタイルをすでに理解していることを願っています...

実際、例外は処理されません。ジョブの開始後、ThrowExceptionAsyncがすぐに終了し、例外がバックグラウンドスレッドのどこかにスローされるためです。

対応するF＃コード

したがって、プログラミング言語の機能を使用する必要がない場合は、そもそもその機能を含めないのがおそらく最善です。F＃では、非同期void関数を記述できません。関数の本体を非同期{…}ブロックでラップすると、戻りタイプは非同期になります。タイプ注釈を使用してユニットが必要な場合、タイプの不一致が発生します。



Async.Startを使用して、上記のC＃コードに一致するコードを記述できます。

let throwExceptionAsync() = async {
    raise <| new InvalidOperationException()  }

let callThrowExceptionAsync() = 
  try
     throwExceptionAsync()
     |> Async.Start
   with e ->
     printfn "Failed"

ここでも例外は処理されません。しかし、Async.Startを明示的に記述する必要があるため、何が起こっているのかはより明白です。そうしないと、関数が非同期を返しているという警告が表示され、結果が無視されます（前のセクション「結果の無視」と同様）。

落とし穴＃4：voidを返す非同期ラムダ関数

非同期ラムダ関数をデリゲートとしてメソッドに渡すと、状況はさらに複雑になります。この場合、C＃コンパイラは、デリゲートのタイプからメソッドのタイプを推測します。アクションデリゲート（または同様のもの）を使用する場合、コンパイラーは、ジョブを開始してvoidを返す非同期void関数を作成します。Funcデリゲートを使用する場合、コンパイラはTaskを返す関数を生成します。



これはルシアンのスライドからのサンプルです。次の（完全に正しい）コードはいつ終了しますか？1秒（すべてのタスクの待機が終了した後）またはすぐに終了しますか？

Parallel.For(0, 10, async i => 
{
    await Task.Delay(1000);
});

For that accept Actionデリゲートのオーバーロードのみがあることを知らない限り、この質問に答えることはできません。したがって、ラムダ関数は常に非同期voidとしてコンパイルされます。また、（おそらくペイロードの）負荷を追加することは重大な変更になることも意味します。

対応するF＃コード

F＃には特別な「非同期ラムダ関数」はありませんが、非同期計算を返すラムダ関数を作成できます。このような関数はAsyncを返すため、voidを返すデリゲートを期待するメソッドに引数として渡すことはできません。次のコードはコンパイルされません。

Parallel.For(0, 10, fun i -> async {
  do! Async.Sleep(1000) 
})

エラーメッセージは、関数タイプint-> Asyncがアクションデリゲートと互換性がないことを示しています（F＃ではint-> unitである必要があります）。

エラーFS0041：メソッドForに一致するオーバーロードがありません。使用可能なオーバーロードを以下に示します（または[エラーリスト]ウィンドウに表示します）。

エラーFS0041：Forメソッドのオーバーロードが見つかりません。使用可能なオーバーロードを以下に（またはエラーリストボックスに）示します。

上記のC＃コードと同じ動作を得るには、明示的に開始する必要があります。バックグラウンドで非同期シーケンスを実行する場合、これはAsync.Start（ユニットを返し、スケジュールし、ユニットを返す非同期計算を実行します）を使用して簡単に実行できます。

Parallel.For(0, 10, fun i -> Async.Start(async {
  do! Async.Sleep(1000) 
}))

もちろんこれを書くこともできますが、何が起こっているのかを確認するのは非常に簡単です。Parallel.Forの特性として、リソースを浪費していることも簡単にわかります。これは、CPUを集中的に使用する計算（通常は同期関数）を並列で実行するためです。

落とし穴＃5：ネストタスク

ルシアンは聴衆の人々の知性をテストするためだけにこの石を含めたと思いますが、ここにあります。問題は、次のコードがコンソールへの2つのピン間で1秒間待機するかどうかです。

Console.WriteLine("Before");
await Task.Factory.StartNew(
    async () => { await Task.Delay(1000); });
Console.WriteLine("After");

まったく意外なことに、これらの結論の間に遅れはありません。これはどのように可能ですか？ StartNewメソッドはデリゲートを受け取り、タスクを返します。ここで、Tはデリゲートによって返されるタイプです。この場合、デリゲートはTaskを返すため、結果としてTaskを取得します。 awaitは、外部タスクが完了するのを待つだけで（内部タスクをすぐに返します）、内部タスクは無視されます。



C＃では、これはStartNewの代わりにTask.Runを使用することによって（またはラムダ関数でasync / awaitを削除することによって）修正できます。



このようなものをF＃で書けますか？Task.Factory.StartNew関数と非同期ブロックを返すラムダ関数を使用して、非同期を返すタスクを作成できます。タスクが完了するのを待つには、Async.AwaitTaskを使用してタスクを非同期実行に変換する必要があります。これは、Async <Async>を取得することを意味します。

async {
  do! Task.Factory.StartNew(fun () -> async { 
    do! Async.Sleep(1000) }) |> Async.AwaitTask }

繰り返しますが、このコードはコンパイルされません。問題はそうすることです！右側にAsyncが必要ですが、実際にはAsync <Async>を受け取ります。言い換えれば、結果を単に無視することはできません。これについて明示的に何かを行う必要があり

ます（Async.Ignoreを使用してC＃の動作を再現できます）。エラーメッセージは前のメッセージほど明確ではないかもしれませんが、それは一般的な考えを与えます：

エラーFS0001：この式はタイプAsync ‹unit›であると予想されていましたが、ここではタイプunitがあります

エラーFS0001：非同期式 'ユニット'が必要です。ユニットタイプが存在します

落とし穴＃6：非同期が機能しない

これは、ルシアンのスライドからの別の問題のあるコードです。今回は、問題は非常に単純です。次のスニペットは、非同期FooAsyncメソッドを定義し、それをハンドラーから呼び出しますが、コードは非同期で実行されません。

async Task FooAsync() 
{
    await Task.Delay(1000);
}
void Handler() 
{
    FooAsync().Wait();
}

問題を見つけるのは簡単です-FooAsync（）と呼びます。Wait（）。これは、タスクを作成してから、Waitを使用して、完了するまでプログラムをブロックすることを意味します。タスクを開始したいだけなので、Waitを削除するだけで問題が解決します。



同じコードをF＃で記述できますが、非同期ワークフローは.NETタスク（元々はCPUバウンド計算用に設計された）を使用せず、代わりにWaitにバンドルされていないF＃非同期タイプを使用します。これは、次のように書く必要があることを意味します。

let fooAsync() = async {
    do! Async.Sleep(1000) }
let handler() = 
    fooAsync() |> Async.RunSynchronously

もちろん、そのようなコードは偶然に書かれる可能性がありますが、非同期の破損の問題に直面した場合、コードがRunSynchronouslyを呼び出すことに簡単に気付くので、作業は-名前が示すように-同期的に行われます。

概要

この記事では、C＃の非同期プログラミングモデルが予期しない方法で動作する6つのケースを見てきました。それらのほとんどは、MVPサミットでのルシアンとスティーブンの会話に基づいているので、よくある落とし穴の興味深いリストを提供してくれた両方に感謝します！



F＃の場合、非同期ワークフローを使用して、最も近い関連コードスニペットを見つけようとしました。ほとんどの場合、F＃コンパイラは警告またはエラーを発行します。または、プログラミングモデルに同じコードを表現する（直接の）方法がありません。これは、以前のブログ投稿で私が行った声明を裏付けていると思います。「F＃プログラミングモデルは、機能的（宣言的）プログラミング言語に間違いなく適しているようです。また、何が起こっているのかを推論しやすくなると思います。」



最後に、この記事は、C＃:-)の非同期性に対する破壊的な批判として理解されるべきではありません。 C＃の設計がそれと同じ原則に従う理由を完全に理解しています-C＃の場合、（個別の非同期の代わりに）タスクを使用することが理にかなっています。これには多くの結果があります。そして、私は他の解決策の理由を理解することができます-これはおそらく非同期プログラミングをC＃に統合するための最良の方法です。しかし同時に、F＃はより良い仕事をしていると思います-部分的にはその合成能力のためですが、より重要なのはF＃エージェントのようなクールなアドオンのためです。さらに、F＃の非同期性にも問題があります（最も一般的な間違いは、リークを回避するために、do！ではなくreturn！を使用する必要があることです）が、これは別のブログ投稿のトピックです。



PS翻訳者から。この記事は2013年に書かれましたが、ロシア語に翻訳するのに十分興味深く関連性があるように思えました。これはHabréへの私の最初の投稿なので、激しく蹴らないでください。