6

私はCで共有ライブラリを書いています。C関数はスレッドセーフではないことを知っています。

私のライブラリルーチンは次のようになります。

struct lib_handle {
....
};

int lib_init(lib_handle **handle);
int lib_process(lib_handle *handle);
....
....

すべてのメソッドはlib_handleオブジェクトへのポインタを取ります。すべての状態はこの構造内に格納されます。グローバル変数は使用されません。

各スレッドが独自のlib_handleインスタンスを作成する場合、複数のスレッドがライブラリ関数を使用できると思います。各スレッドには独自のハンドルがあるため、everythibgは機能するはずです。

私はまだこの仮定を検証していません。皆さんがこの設計についてどう思っているのか疑問に思っています。各スレッドに独自のハンドルがある場合、ライブラリをスレッドセーフと見なすことができますか?

どんな助けでも素晴らしいでしょう!

4

3 に答える 3

4

これにより、ライブラリのデータ/状態がスレッドセーフになります。

ただし、ライブラリが他のライブラリのスレッドセーフな関数を使用していることも確認する必要がありstrtok_rますstrtok

于 2012-08-17T05:27:57.510 に答える
1

スレッドは共有メモリ空間で動作します。安全でないオブジェクトは、複数のスレッドから同時にアクセスできるオブジェクトです。したがって、スレッドごとに 1 つの lib_handle オブジェクトがあれば、問題はありません。

于 2012-08-17T05:36:04.747 に答える
0

各スレッドにプライベートlib_handleオブジェクトがある場合、ライブラリは完全にスレッドセーフである必要があります。複数のスレッドにlib_handleオブジェクトを共有させる場合でも、ライブラリを正しく使用していれば、ライブラリを使用している人はスレッドセーフなプログラムを作成できます(つまり、ライブラリは、グローバル変数などを使用した場合のように、本質的にスレッドセーフではありません)。

この操作モード(共有lib_handle)が興味深い場合は、lib_handleの状態のみを読み取る関数とlib_handleの状態を操作する関数を明確に分離する必要があります。前者には読み取りロックが必要であり、後者には書き込みロックが必要です(呼び出し元のスコープがこれを処理する必要があります)。

価値のあるものとして、私はあなたが説明するパターンをかなり多く使用し、それが好きです。

于 2012-08-17T08:06:16.323 に答える