0

多くの異なるスレッドが割り当てを要求できる共有メモリ プールがあります。これから割り当てを要求すると、すべてのスレッドで大量に発生しますが、スレッドの量は少なく、多くの場合、実行中のスレッドは 1 つだけです。これを処理する次の方法のどれが優れているかわかりません。

最終的には両方を実装して、どちらがより好ましい結果をもたらすかを確認する必要があるかもしれません...また、この共有リソースを使用するコードを実際にはまだ作成していないため、この時点で #2 を考えても時期尚早の最適化になるのではないかと心配しています。しかし、この問題は非常に興味深いので、他の作業から気をそらし続けています。

1) ミューテックスを作成し、割り当てを取得する前にスレッドにロックを試行させ、ロックを解除します。

2) 各スレッドに要求スロットを登録させます。割り当てが必要な場合は、要求をスロットに入れ、(while (result == NULL) { usleep() }) 要求スロットが結果を待つのをブロックします。1 つのスレッドがリクエスト スロットを継続的に反復し、割り当てを行い、リクエスト スロット内の結果に割り当てます。

番号 1 は単純な解決策ですが、タイミングが適切であれば、1 つのスレッドがロックを独占する可能性があります。2 つ目はより複雑ですが、リソースからプルするときにスレッド間の公平性を保証します。ただし、要求元のスレッドは引き続きブロックされ、多数のスレッドが存在する場合、実行する要求が見つかるまで、実際の割り当てを行わずに反復がサイクルを焼き尽くす可能性があります。

注: pthread を使用する Linux 上の C

4

1 に答える 1

6

解決策 2 は偽物です。これは醜いハックであり、メモリの同期を保証しません。

解決策 1 を使用すると思いますが、最初に「メモリ プール」について言及したという事実には少し懐疑的です。メモリを割り当てようとしているだけですか、それとも管理している他のリソースがありますか (たとえば、特別な種類のメモリ内のスロット、メモリ マップ ファイル、ビデオ メモリ内のテクスチャなど)?

メモリを割り当てているだけなら、時期尚早の最適化について心配するのは完全に正しいです。全体の問題は時期尚早の最適化であり、システムmallocはメモリプールと同じかそれ以上に機能します。malloc(または、一部のビデオ ゲーム コンソールのように病理学的に壊れた数少ないシステムの 1 つでコードが実行される場合は、それらの既知の壊れたシステムにのみ代替品をドロップしてください。)

管理する必要がある特別なリソースが本当にある場合は、解決策 1 から始めて、それがどのように機能するかを確認してください。問題が発生した場合は、リソース マネージャーがスロットを割り当てることができるときに通知する条件変数を使用して改善できることがわかるかもしれませんが、これが必要になるとは思えません。

于 2011-08-07T20:36:33.067 に答える