外部アドオン用の Lua スクリプトを使用する C++ アプリケーションを開発しています。アドオンは完全にイベント駆動型です。ハンドラは、スクリプトがロードされるときにホスト アプリケーションに登録され、イベントが発生するとホストがハンドラを呼び出します。
私がやりたいことは、各 Lua スクリプトを独自のスレッドで実行して、スクリプトがホスト アプリケーションをロックしないようにすることです。私の現在の意図は、Lua コードを実行するために新しいスレッドをスピンオフし、コードが完了するとスレッドが独自に終了できるようにすることです。マルチスレッドイベントディスパッチの形式として新しいスレッドをスピンオフすることの潜在的な落とし穴は何ですか?
ここにいくつかあります：
一般的に言えば、イベント駆動型API に実行する新しいスレッドを与えることは、悪い決断だと思います。イベントが発生するまで何もすることがないのに、スレッドが実行されているのはなぜですか? すべてのアドオンに対して1 つのスレッドを生成し、そのスレッドからのすべてのイベント伝播を管理することを検討してください。実装が非常に簡単になり、バグが発生したときに戦うチャンスがあります.
新しいスレッドを作成して頻繁に破棄することは、あまり良い考えではありません。1 つには、メモリを消費しすぎないようにこれをバインドする方法が必要です (たとえば、スタック スペースを考えてください)。または、スレッドが時間の競合のために多くのプリエンプションが発生するポイントに到達する必要があります。 CPU。第二に、新しいスレッドの作成と破棄に関連する多くの作業が無駄になります。(これはオペレーティング システムによって異なります。スレッドの作成が安価な OS もあれば、高価な OS もあります。)
実装しようとしているのは作業キューのようです。これに関する適切なウィキペディアの記事は見つかりませんでしたが、次の記事に近いです: Thread pool pattern。
これを実装する方法と、使用できるさまざまな同時キュー アルゴリズムについて、何時間も話し続けることができます。しかし、アイデアは、キューを空にする N 個のスレッドを作成し、キューに入れられたアイテムに応じて何らかの作業を行うというものです。通常、キューにアイテムがない間、スレッドがセマフォで待機するようにすることもできます。ワーカースレッドはこのセマフォをデクリメントし、エンキューアはそれをインクリメントします。ワーカー スレッドがビジーでリソースを消費しすぎている間にエンキューがキューに入れすぎないようにするために、「利用可能なキュー スロットの数」セマフォでエンキューを待機させることもできます。これらは単なる例であり、詳細はあなた次第です。君は'
私の 2 セント: ホスト アプリケーションによって生成されたイベントの数と速度に応じて、私が見ることができる主な問題は、パフォーマンスの面です。スレッドの作成と破棄にはコストがかかります [パフォーマンスに関して] 一度生成された各スレッドは、他のスレッドとリソースを共有する必要がないため、競合はありません。すべてのスレッドが CPU の 1 つのコアに割り当てられていて、ロード バランシングがない場合、1 つの CPU を簡単に過負荷にして、[マルチコア システム上の] 他の CPU をアンロードできます。いくつかのスレッド アフィニティ + 負荷分散ポリシーを検討します。
他の問題は、リソース [読み取りメモリ] の点である可能性があります。各 LUA スレッドが消費するメモリの量は?
LUA スレッドでのメモリ リークにも十分注意してください。イベントが頻繁に発生し、スレッドが頻繁に作成/破棄されてメモリ リークが発生する場合は、ホスト メモリをすぐに消費する可能性があります;)