問題タブ [future]

フューチャーをキャンセルせずに中断する方法はありますか？

java doc API：

boolean cancel（boolean mayInterruptIfRunning）

このタスクの実行をキャンセルしようとします。タスクがすでに完了している場合、すでにキャンセルされている場合、またはその他の理由でキャンセルできなかった場合、この試行は失敗します。成功し、cancelが呼び出されたときにこのタスクが開始されていない場合、このタスクは実行されません。タスクがすでに開始されている場合、mayInterruptIfRunningパラメーターは、タスクを停止するためにこのタスクを実行しているスレッドを中断する必要があるかどうかを決定します。

割り込みをキャプチャするには、割り込み例外を適切にキャッチするか、Runnable / Callableメソッド内のisInterrupted（）メソッドを確認する必要があります。

しかし、Futureインターフェースを使用して実行中のFutureを中断する方法はありません

すべてのスレッドがエグゼキュータサービスプールにあるため、誰もthread.interrupt（）を実行できません。フューチャーがキャンセルされたとき、またはスレッドプールが終了したときにのみ割り込みが発生すると想定されているのはそのためですか？

Futureインターフェースに割り込みメソッドがない理由を理解しようとしています。どんな助けでも大歓迎です

以下が正しい実装になるのだろうか

Javadoc によると、future.get()スレッドごとに実行が完了するのを待ちます。これは、(私が理解しているように) それぞれの将来について、結果を個別に受け取るのを待つことを意味します。その利益はどこから来るのですか、それとも私はそれを正しくしていませんか?

NHibernate を使用して、データベースのほぼ全体のグラフをロードする必要があります (本当の理由から、信じてください)。エンティティはそれほど多くありませんが、グラフは複雑です。

私のグラフは次のようになります。

• エンティティA
• | |
• --> エンティティ B
• | |
• --> リスト
  • | |
  • --> エンティティ D
  • | |
  • --> リスト
    • | |
    • --> エンティティF

うーん... わかります。

可能な限り少ないクエリとラウンドトリップですべてをロードし、N + 1 をまったく選択しないようにしたいと考えています。また、グラフとして保持したいので、後で簡単にループできます。

私の最良の選択肢は何ですか？NHibernateUtil.Initialize()? Fetch()/FetchMany()? 将来/マルチクエリ?

ちょっと迷ったけど、複数回に分けてやらなきゃいけないんじゃないかな。しかし、何が最も効率的でしょうか？

おまけ: すべてのエンティティに IsPublished プロパティがあります。すべてのエンティティまたは公開されているエンティティのみをロードできるようにしたい。

編集

最後に私はこれを試しました：

私のグラフがどのように見えるかを考えると、それはまったく問題ないと思います。また、同じレベルに複数のコレクションがありません。これは、私が知る限り、デカルト積を誘発するものです。

尋ねた人にとって、それは再帰の問題ではありません。それ以外の場合は、SQL Server CTE を使用します。また、エンティティを更新していません。単純に読むだけです（オフラインアプリの場合）。

しかし、私は「ボーナス」の質問については無知です。EF がフィルターに基づいて部分的なコレクションを読み込めることは知っていますが、NH ではそれができないようです。

オブジェクトからの状態変化に関する通知が明確に定義された順序でスロットに到達するようにするために、boost::signals2 シグナルのマルチスレッド呼び出しをシリアル化したいと考えています。

バックグラウンド

マルチスレッド プログラムに内部状態を持つオブジェクトがあります。内部状態の一部はプログラムの他の部分にとって興味深いものであり、オブジェクトは次のような boost::signals2 シグナルを使用して状態の変化を公開します。

問題

OnEvent ハンドラーの同時呼び出しが複数ある場合、実際に変更が行われた順序とは別の順序で状態の変更がリスナーに通知される可能性があります。状態自体は上記のようなミューテックスによって保護されているため、実際の状態は明確に定義されています。ただし、デッドロックが発生する可能性があるため、シグナルの呼び出し全体でミューテックスを保持することはできません。これは、シグナルの実際の呼び出しが任意の順序で発生する可能性があることを意味しますが、状態の変化が実際に発生したのと同じ順序で呼び出す必要があります。

この問題を処理する 1 つの方法は、状態をシグナルから削除し、状態が変化したことをリスナーに通知することです。その後、オブジェクトの状態を照会し、信号が発生したときのオブジェクトの状態またはそれ以降の状態を取得します。私のシナリオでは、リスナーはすべての状態変更について通知を受ける必要があるため、この方法はここでは機能しません。

私の次のアプローチは、次のようなものになります。

私は上記のコードを試していないので、バグやコンパイル エラーが散らばっている可能性がありますが、私が求めているものを推測できるはずです。私の直感によると、この種の問題に遭遇したのは私が初めてではなく、試行錯誤したコードを自分で使用することを好みます... :) だから私の質問は本当に:

boost::signals2 シグナルのシリアル化された呼び出しを実現する既存の方法はありますか (signals2 ライブラリや一般的なパターンに組み込まれているなど)?

次のコードは、操作によってチェック例外ExecutionExceptionがスローされ、Clojure がそれを でラップしているケースを示していますRuntimeException。

Clojure がこれを行うのはなぜですか? これは正常ですか？この場合、Clojure は Java とは異なることを行っているようです。Exceptionこの場合、失敗の原因となった実際の例外を処理する慣用的な方法は何ですか?

タイムアウトが 0 の 'Future.get' が待機しないことを明確にするドキュメントを誰か教えてもらえますか?

の API ドキュメントはjava.util.concurrent.Future、 の動作を明示していませんfuture.get(0, unit)。単独で、「必要に応じて最大で指定された時間まで待機します...」というステートメントは、この呼び出しがまったく待機しないことを意味しますが、(無限待機) の長年の動作を考えると、Object.wait(0)依存するのは緊張します。の「待機なし」動作future.get(0, unit)

いくつかの JDK 提供のクラス (viz.) のソースをスキャンすると、タイムアウトが 0 の場合、この特定の実装が待機しないFutureTaskことがわかります。Future

言えるようになりたい

しかし、それを無限の待機として実装する Future については神経質になっているため、代わりに、期待どおりに機能するように明示的にコーディングしました。

ネストされた先物を単一の先物に「フラット化」するために使用するヘルパー関数があります。

編集：提案されているように、「fold」の名前を「flatten」に変更しました。

Boostライブラリの先物を使用しています：

これは次のように使用されます。

問題は、これは「ネストされた」未来をに変換した場合にのみ機能することshared_futureです。それを回避するための良い方法はありますか？私が欲しいのは次のようなものです：

第二に、メソッドの名前が少しわかりません。何か意見はありますか？

に を設定するset_wait_callbackと、boost::unique_future一度だけ実行されることが保証されますか?

ソースコードを見ると、次のことがわかったので、少し疑わしいです。

コールバックが呼び出されている間、ミューテックスのどこdo_callbackが実際にロック解除されていますか?私の理解では、複数のスレッドが関数を呼び出すと、コールバックが複数回呼び出される可能性がありますwaitか?

コールバックを複数回呼び出すことはできますか? それは設計によるものですか？または、何か不足していますか？

私が少し驚いた理由は、C++11 標準ではasync(std::launch::deferred, ...)(set_wait_callback従兄弟である)、単一の呼び出し保証があるように見えるからです。

§30.6.8

関数が完了するまで、共有状態は準備できません。 この共有状態を参照する非同期戻りオブジェクトでの時間指定のない待機関数 (30.6.4) への最初の呼び出しは、待機関数を呼び出したスレッドで遅延関数を呼び出すものとします。