3

目的

移植性が最大の関心事である小さなライブラリを書いています。これは、ほとんど準拠したC90（ISO / IEC 9899：1990）環境のみを想定するように設計されています...それ以上のものはありません。ライブラリによって提供される一連の関数はすべて、内部データ構造で動作（読み取り/書き込み）します。私は他のいくつかの設計の代替案を検討しましたが、ライブラリが達成しようとしていることに対して他に実行可能なものはないようです。

質問

スレッドセーフを確保するために使用できるポータブルなアルゴリズム、テクニック、または呪文はありますか？関数を再入可能にすることには関心がありません。さらに、アルゴリズム/テクニック/呪文が移植可能である場合、私は速度や（おそらく）リソースの浪費については心配していません。理想的には、ライブラリ（GNU Pthなど）やシステム固有の操作（アトミックテストアンドセットなど）に依存したくありません。

Lamportのパン屋のアルゴリズムを変更することを検討しましたが、スレッド自体で機能するのではなく、スレッドによって呼び出される関数の内部で機能するように変更する方法がわかりません。

どんな助けでも大歓迎です。

4

4 に答える 4

1

OS /ハードウェアのサポートがなければ、少なくともアトミックCASがなければ、実用的なことは何もできません。ただし、さまざまなプラットフォームを共通のインターフェイスに抽象化するポータブルライブラリがあります。

http://www.gnu.org/software/pth/related.html

于 2009-08-02T19:49:28.610 に答える
1

最近では、ほぼすべてのシステム (Windows を含む) で libpthread を実行できます。

于 2009-08-02T19:57:15.037 に答える
0

関数は、見方に応じて、スレッドセーフにならないか、本質的にスレッドセーフになります。また、スレッド化/ロックは本質的にプラットフォーム固有です。実際、スレッドの問題を処理するのはライブラリのユーザー次第です。

于 2009-08-02T19:45:25.873 に答える
0

ランポートのパン屋のアルゴリズムはおそらく機能するでしょう。残念ながら、それでも実際的な問題があります。具体的には、多くのCPUが順不同のメモリ操作を実装します。コードを完全に正しい命令シーケンスにコンパイルした場合でも、CPUは、コードを実行するときに、パフォーマンスを向上させるためにその場で命令を並べ替えることを決定する場合があります。これを回避する唯一の方法は、システムおよびCPUに非常に固有のメモリバリアを使用することです。

ここでは、実際には2つの選択肢しかありません。（1）ライブラリをスレッドセーフに保ち、ドキュメントでユーザーにそのことを認識させるか、（2）プラットフォーム固有のミューテックスを使用します。オプション2は、多種多様なプラットフォーム用のミューテックスを実装し、統一された抽象的なインターフェイスを提供する別のライブラリを使用することで簡単にできます。

于 2009-08-02T19:53:19.850 に答える