問題タブ [omnithreadlibrary]

私は OmniThreadLibrary を発見し、それを使い始めました。たとえば、最大 20 個のタスクを起動し、残りのタスクをキューに送信しようとしています。

これを行うために、OmniThreadLibrary の00_Beepプロジェクトを変更しました。

それは機能しますが、タスクの数 (つまり、TASKS_COUNT) をたとえば 7000 に増やすと、例外が発生します。

TOmniCommunicationEndpoint.Send: Queue is full

見つけたものは何でも読みました (OTL ブログとフォーラム、サンプル プロジェクト、たくさんのグーグル検索など)。これを防ぐには、定期的にキューを空にする必要があるようです。

だから私はこれを試しましたが、うまくいきませんでした：

キューを空にしてこの例外を回避する方法に関するアドバイスはありますか?

キュー内のこのような多数のタスクはばかげていると言う人もいるかもしれませんが、それは仮説的な質問でも、アプリケーションを再設計するように指示するのも私の質問の範囲内ではないと言えば十分です。この時点で私は知る必要がありますOTL のキューイング システムの制限と、この制限を回避する方法。

前もって感謝します！

Delphi 2010 (優れた OmniThreadLibrary を使用) を使用してマルチスレッド クライアント アプリを開発していますが、あるスレッドから別のスレッドに常に交換しているため、デバッグに苦労しています。

現在のスレッドだけでなく、他のすべてのスレッドについても、現在の実行ポイントを見つけることが可能かどうか疑問に思います (ツールやプラグインを使用してもかまいません!)。

単純化した例/レポート:

私の目標は、ログを使用するだけでなく（またはあまり役に立たないスレッド12345が停止した）、Delphiが特定のブレークポイントで停止したときに他のスレッドが何をしているかを「見る」ことですが、ブレークポイントが停止したかのようにそれらを検査します。

私の質問が十分に明確であることを願っています。ここで真夜中を過ぎていることに注意してください。私の質問がばかげているように聞こえても、私を責めないでください!

I have tried to upload +100 files to azure with Delphi. However, the calls block the main thread, so I want to do this with a async call or with a background thread.

This is what I do now (like explained here):

However this block too (why? I don't understand).

優れたOmniThreadLibraryライブラリを使用して、スレッド化されたソースコードの解析を実装します。プログラムは、既存の解析を破棄し、ソースコードが変更されるたびに解析を再開する必要があります。

以下に示すコードスニペットを使用してこれを行いますが、正しい方法ですか？関数Terminated内のスレッドのプロパティを確認する必要がありますか？ThreadedParseHtml

前もって感謝します！

編集1FParserThread ：この質問を再度開いて申し訳ありませんが、十分な時間をかけてメソッドを呼び出して、それ自体で完了しないとメモリリークが発生することがわかりましTerminateた...メモリリークの原因について何か考えはありますか？ありがとう！

編集2 ：このブログ投稿を読んでくださいThreadedParse。コードのすべてのステップの後で問題が発生した場合Terminatedは中断するため、問題が何であるかはまだわかりません。

編集3：ロブの質問に答える：

1. OnTerminatedイベントハンドラー（ここには表示されていません）では、FParserThreadは「nil」に設定されているため、「FParserはそれ自体で完了します」とは、if FParserThread <> nil thenブロックが実行されないことを意味します。この場合、FParserThreadは、解析が完了したために終了します。

2. コードの背後にあるロジックは、これがコードエディターであり、コードを編集すると、新しいコード編集が発生したが前の解析が行われた場合に、ソースコードを内部ツリープレゼンテーションに解析するためのスレッドが開始されるというものです。編集されていない場合、プログラムは最初に前の解析スレッドを強制的に開始し、次に新しい解析スレッドを開始します。これはおそらく良いアプローチではありません...

編集4 ：この同様のSO質問を読んだ後、パラメーターなしで呼び出すようにコードを変更しましFParserThread.Terminateた。つまり、正しく理解していれば、そのステートメントはスレッドに終了を通知するだけであり、実際のスレッドタスク内でロジックを適用しました。Terminatedプロパティが。の場合は、スレッドの実行を終了しますTrue。

これで、 Tracetoolの助けを借りて、イベント（メモリをクリーンアップする場所）を呼び出しFParserThread.Terminateた後OnTaskMessage、再度起動されないことがわかりました。これがメモリリークの原因でした。

開始された単純な TTimer に問題があり、その OnTimer イベントがメイン アプリ スレッドで実行されます。コードは次のようになります。

単純なプロジェクト/デモでコードを実行すると、すべてが正常に機能しますが、私のアプリ (Omni Thread Library v3 を使用) では、タイマー イベントが発生しません。

私はそれが何もないと確信しています、私は何が間違っているのか理解できません!

私は三重にチェックしました：MyTimerコードで一度だけ割り当てられ、そのOnTimerイベントが正しく割り当てられているなど...

Delphi 2010 を使用しています

誰でもこれを修正する方法を知っていますか?

バックグラウンドでツリー構造に格納されたアイテムを再帰的に反復する必要があり、スレッド プールから複数のスレッド (「フォルダー」ノードごとに 1 つのスレッド) を使用してこのツリーを歩きたいとしましょう。OmniThreadLibrary によって提供されるいくつかの異なる低レベルおよび高レベルのアプローチを使用して、これを実装することができました。

ただし、スキャンが実際に完了したこと、つまり最後のリーフ ノードがすべて処理されたことを適切に検出する方法はまだわかっていません。

GlobalThreadPool.CountExecuting + GlobalThreadPool.CountQueued <= 0を使用しているかどうかを確認するネット上のさまざまな例を見つけましたIOmniTaskGroup.WaitForAll()。残念ながら、これらのアプローチはどれも私にはうまくいかないようです。チェックは、常にTrue、実行中のタスクがまだいくつかある場合など、あまりにも早く返されます。ただし、再帰を使用した例はなく、スレッドプールを使用しなかった例もありましたが、これはそもそも良い組み合わせではないのでしょうか?

これは、現時点でこれを実行しようとしている方法の（非常に）単純化されたサンプルコードスニペットです。

私が試した待機の実装例は次のとおりです ( About.com で見つかった例に基づく):

しかし、これは常に「ルートスレッド」が終了した直後に終了するようです。Sleep()-callsを使用して人為的な遅延を追加しても、常に終了が早すぎます。実行中のタスクのリストから削除された 1 つのタスクと、そのタスク内でスケジュールされ、キューに入れられたタスクのリストに追加されるタスクとの間に「ギャップ」が発生しているようです...

実際には、スキャンが完了するのを待つ代わりに、イベント ハンドラーを使用することを非常に好みます (また、Application.ProcessMessagesフォームのないアプリケーションでもこれが必要になるため、使用したくありません)。IOmniTaskControl.OnTerminatedを使用しますTOmniEventMonitorが、これらは完了したすべてのタスクに対して起動するため、現在のタスクが最後のタスクであるかどうかを何らかの方法で確認する必要があり、これも上記と同じ問題になります。

または、この問題を回避するタスクを作成するためのより良い方法はありますか?

作業の盗用は、たとえば、JavaプラットフォームのFork/Joinフレームワークで利用できます。（fork / joinフレームワークはスレッドプールよりも優れていますか？を参照してください）-OmniThreadLibraryで同様のことが可能ですか？

作業の盗用：実行することが不足しているワーカースレッドは、まだビジー状態にある他のスレッドからタスクを盗むことができます。

メインアプリケーションスレッドが他の作業スレッドを一時停止/再開できるようにしたいのですが、これが可能であると仮定すると、これを行う最良の方法は何ですか?

Windows XP (およびそれ以降) で動作する提案は大歓迎です!

PS。Delphi 2010とOmniThreadLibrary 3を使用しています

マルチスレッドを使用してDelphiアプリケーションを改善するためにOmnithreadを使用することを検討し始めました。1つ以上のワーカータスクの作成については、ドキュメントで十分に説明されているため、ボタンのクリックから呼び出す長いアクションをこのデモコード（Async、CreateTaskなど）に置き換えることができます。私が苦労しているのは、次のように動作する私の最も「厄介な」コードを置き換える方法です。

ハードウェアモジュールに対応する単一クラスインスタンスの概念があります。このクラスは、ハードウェアの現在の値と設定を公開する1つ以上のプロパティを公開します。プロパティは、読み取り専用または読み取り/書き込みの場合があります。これらのクラスインスタンスのそれぞれについて、ゼロからいくつかの表示フォームが表示される場合があります。表示フォームには、TTimerと、前述の公開されたプロパティのビルドリストがあります。このリストは、ラベルや編集コントロールなどの適切な名前のコントロールを照合するために繰り返され、RTTIメカニズムを使用して、コントロールとそのプロパティの間で値を取得および設定します。その結果、実際のハードウェアモジュールに優れたUIを提供し、複数のフォームを開くことができるよりも副作用があります。そのうちの1つでデータを変更すると、すぐ後に他のフォームにそのデータが表示されます。このプロパティの監視は、TTimerが300ミリ秒間隔でティックすることによって実行されます。ティックごとに、クラスのすべてのプロパティをスキャンし、フォームの一致するコントロールを更新します。タイマーは、開いているフォームの存続期間中実行されます。フォームは必要に応じて作成され、解放されます（これには、ハードウェアを検査するためのフォームが開いていない場合、監視タスクを実行できないため、アプリケーションを可能な限り高速に実行する必要があるという便利なパフォーマンスの最適化があります）。

UIスレッドでTTimerを使用するのではなく、スレッドを使用して公開されたプロパティにアクセスするためのより良い方法はありますか？それとも、同期の問題が利点を上回りますか？スレッド化が役立つ場合、ティックタイマーをエミュレートするなどの繰り返しタスクをどのように作成しますか？

私は TThread の子孫を作成して、長期にわたる DB 操作を行うことに慣れています。私の通常の構成は次のようになります。

次に、明らかにこのクラスを

そしてもちろん、私は通常 DBOp を別のコンポーネント var として設定して、スレッドを終了または待機できるようにします。

ここで、これらの TThread クラスを書き直して、OmniThreadLibrary で同様の構造を使用したいと考えています。どうすればいいですか？つまり、すべてのクラス コンポーネントとプロパティを定義するために使用する基本クラスは何ですか? - TOmniWorker の子孫である必要がありますか? では、Execute プロシージャはどこにありますか? - TObject の子孫である必要があり、OTLTaks は として作成されCreateTask(DBOp.Execute)ますか? - として作成された OTLTask のパラメータとして渡すのは TObject である必要がありCreateTask(anonymous method that reads the parameter and calls its Execute)ますか?

ヒントをありがとう。

編集: (明確化に関する gabrs のコメントに基づく)私のポイントは、OTL ソースのすべてのサンプル/テストは単純な使用法のみを示しているということです。基本的な「1 手順」のスレッドがほとんどです。私の場合、すべてスレッドで実行されるサブコンポーネントとサブルーチンを含むかなり複雑なクラスが必要です。そのようなクラスの祖先とそのデザインパターンを探しています。