問題タブ [async-workflow]

関数型コードは非関数型コードよりも本質的に並列化が容易であると常に耳にするので、次のことを行う関数を作成することにしました。

文字列の入力が与えられた場合、各文字列の一意の文字の数を合計します。したがって、入力が与えられると[ "aaaaa"; "bbb"; "ccccccc"; "abbbc" ]、メソッドはを返しますa: 6; b: 6; c: 8。

これが私が書いたものです：

inputの各文字列は独自のスレッドで処理できるため、このコードは理想的には並列化可能です。インナーループはすべての入力間で共有されるマップにアイテムを追加するため、見た目ほど簡単ではありません。

内側のループを独自のスレッドに分解したいのですが、可変状態を使用したくありません。非同期ワークフローを使用してこの関数を書き直すにはどうすればよいですか？

私は C# プログラマですが、F# の非同期ワークフローについて質問があります。C# クラス ライブラリに次のクラスがあるとします。

私の理解では、F# では、次のように呼び出すことができる ReadAllAsync という関数を作成できます。

また、呼び出し元のスレッドをブロックするのではなく、それをスレッド プールに解放し、操作が終了すると別のスレッドに戻ります。Async.Primitive を使用して F# でこれをコーディングする方法を理解していると思いますが、私の質問は、この ReadAllAsync 関数を C# コードから呼び出すことはできますか? その場合、F# コードをクラス ライブラリにパッケージ化して C# からアクセスするにはどうすればよいですか?

dotNet に DirectoryInfo.GetFiles / Directory.GetDirectories の非同期バージョンはありますか? F# の async ブロックでそれらを使用したいのですが、AsyncCallbacks で呼び出せるバージョンがあると便利です。

問題は、おそらく低速のネットワーク接続を介した SMB マウントで、一連のディレクトリを吸い込もうとしていることです。他の作業を行っている可能性があるときに、ネットワークの読み取りを待機しているスレッド プール スレッドの束を望んでいません。

私は現在、ネットワーク経由で収集デバイスを制御する必要があるサーバー アプリケーションに取り組んでいます。このため、多くの並列プログラミングを行う必要があります。時間の経過とともに、処理エンティティ (スレッド/プロセス/アプリケーション) 間の通信には 3 つのアプローチがあることを学びました。残念ながら、3 つのアプローチにはそれぞれ欠点があります。

A)同期リクエスト(同期関数呼び出し)を行うことができます。この場合、呼び出し元は、関数が処理されて応答が受信されるまで待機します。例えば：

問題は、発信者がアイドリングしていることです。時々、これはオプションではありません。たとえば、呼び出しがユーザー インターフェイス スレッドによって行われた場合、応答が到着するまでアプリケーションがブロックされているように見えますが、これには長い時間がかかる可能性があります。

B)非同期リクエストを作成し、コールバックが行われるのを待つことができます。クライアントコードは、実行する必要があるものは何でも続行できます。

このソリューションには、コールバック関数が必然的に別のスレッドで実行されるという大きな欠点があります。問題は、発信者に応答を返すのが難しいことです。たとえば、サービスを非同期的に呼び出したダイアログのボタンをクリックしましたが、コールバックが到着したときにダイアログが長時間閉じられていました。

これ自体はそれほど大きな問題ではありません。ただし、そのような呼び出しを複数回行いたい場合、それらはすべて前の呼び出しの応答に依存します。私の経験では、これは手に負えないほど複雑になります。

C)最後のオプションは、非同期リクエストを作成し、レスポンスが到着するまでポーリングを続けることです。has-the-response-arrived-yet チェックの合間に、何か役に立つことができます。これは、実行する一連の非同期関数呼び出しがある場合を解決するために、私が知っている最善の解決策です。これは、応答が到着したときに呼び出し元のコンテキスト全体がまだ残っているという大きな利点があるためです。また、呼び出しの論理的な順序はかなり明確なままです。例えば：

この 3 番目の解決策の問題は、呼び出し元の関数から戻ることができないことです。これは、間にやりたい作業が非同期で行われている作業とはまったく関係がない場合には適していません。長い間、上記のオプションの欠点を持たない関数を非同期的に呼び出す可能性があるかどうか疑問に思っていました。誰かがアイデアを持っていますか、おそらく何か巧妙なトリックはありますか?

注:例は C++ ライクな擬似コードです。ただし、この質問は C# と Java、そしておそらく他の多くの言語にも同様に当てはまると思います。

F# で非同期ワークフローを使用して、複数の Web 要求を取得しようとしています。

ただし、一部のリクエストで時折エラーが返され (例: http 500)、これを処理する方法がわかりません。デバッガーで実行すると、F# プログラムが無限ループに陥ってしまうようです。

私が見た例はそのままではコンパイルされなかったので、おそらくいくつかのものが欠けています。最初に役に立ったのは、次のコードです。

そして、リクエストをフェッチするためのコードが少しあります。これは、私が見た例からはかなり標準的です。

そして、結果を取得しようとします:

しかし、デバッガーでプログラムを実行すると、req.EndGetResponseサーバーが内部サーバー エラー 500 を返したため、で中断します。実行を継続し続けると、ファンキー ループに入り、req.EndGetResponse(場合によっては連続していくつか) と let status = Async.RunSynchronously(async_value)で中断します。 .

例外の問題を回避してステータス コードを取得するにはどうすればよいですか? また、上記で行ったタイプのものが必要ですか? それとも、F#/VS 2010 Beta 1 用のライブラリ/dll が不足していますか?

Async.RunSynchronously私は実際に( (my_array_of_async_values))を使用して複数のリクエストを並行して実行Async.Parallelしていますが、それが私が抱えている例外の問題に関連しているとは思いません。

私が遭遇した例は、おそらく何かが欠けている指標ではAsync.Runなく、使用のみを使用しているという事実... =/Async.RunSynchronously

させてくれた印象でした！in f＃は、一連の割り当てを並行して実行するのに十分なほどスマートでした。ただし、次のサンプルは異なる動作を示しており、a、b、cの割り当ては同期して実行されているようです。

それはどうあるべきか/あるべきか？

そして、a、b、cを並行して実行したい場合、Async.Parallell ... |> Async.RunSynchronously ...を使用することになっていますか？

上記のサンプルはもちろん役に立ちません。実際のユースケースは、DBにクエリを実行し、同時にいくつかのWebサービスを呼び出すようなものです。

F＃の非同期ワークフローに相当するScalaとは何ですか？

たとえば、次のF＃スニペットは慣用的なScalaにどのように変換されますか？

私は関数型プログラミング全般に不慣れで、最近 F# を学び始めました。Async<'U option>シーケンス内の項目を選択するために戻る非同期ワークフローを使用したいと考えていました。いい関数を見つけましたSeq.pickが、それを非同期ワークフローでどのように使用できるかわかりません。

それが不可能な場合は、命令型スタイル プログラムを使用してリストから項目を選択する別の方法があります。以下は、私のプログラムの修正版です。フィードバックは大歓迎です。

ありがとうございます。

編集: jpalmer の回答に基づいて質問を更新しました。Seq.filter私は両方と以前に気づき、ロックできる最初のアイテムが必要なので、それが私のニーズをよりよく満たすSeq.pickと判断しました. Seq.pickただし、関数の戻り値を変更するのを忘れていました。 を返す代わりに、 を返すtrue必要がありSome(item)ます。その更新により、1) 変換するスレッドをブロックし、2) 命令型のループに頼ることなく、これにアプローチするエレガントな方法はありAsync<'U option>ます'Uか?

たまたまnullになるネストされたAsyncを呼び出すときに、問題に遭遇しました。例外が発生しましたが、非同期ワークフローが提供する通常の例外処理方法ではキャッチできません。

以下は、問題を再現する簡単なテストです。

次の例外が発生します。

この場合、例外をキャッチする必要があると本当に思いますか、それともこれは本当に期待される動作ですか? (記録には Visual Studio 2010 Sp1 を使用しています)

また、次のテスト ケースAsync.CatchでAsync.StartWithContinuations示されているのと同じ問題が発生します。

ワークフロービルダーのバインドメソッド内で例外が発生したようで、結果として通常のエラー処理コードがバイパスされていると思います。ドキュメントや他の場所で、これが意図された動作であることを示唆するものを見つけられなかったため、非同期ワークフローの実装のバグのように見えます。

ほとんどの場合、回避するのはかなり簡単だと思うので、少なくとも私にとっては大きな問題ではありませんが、すべての例外をキャプチャできる非同期例外処理メカニズムを完全に信頼できないことを意味するため、少し不安です.

編集：

少し考えた後、kvbに同意します。Null非同期は通常のコードには実際には存在すべきではなく、おそらくすべきではないことを行う場合（Unchecked.defaultOfを使用するなど）、またはリフレクションを使用して値を生成する場合にのみ生成される可能性があります（私の場合、それは関連するモックフレームワークでした） . したがって、これは実際にはバグではなく、エッジ ケースです。