多くの読者がいる場合にpthread_rwlockを使用する効率

Question

pthread_rwlock_unlock関数のマニュアルページを見ているうちに、呼び出しスレッドがrwlockの所有権を持っていないとfuncがEPERMを返すことに気付きました。

複数のスレッドがロックを取得できるため、特定のrwlockの所有者IDを格納するためのリンクや配列などのデータ構造が必要です。ここで

は、質問が来る：

は、rwlockが読み取り操作がはるかに頻繁に書き込み操作よりも時の効率を達成するように設計されていますが、異なる多数のスレッドが、私が呼び出すたびに読み込みロックをそこに着いている場合pthread_rwlock_unlock（）を呼び出すと、呼び出し元のスレッドが有効な所有者であることを気象情報から見つけるのに時間がかかります。このシナリオの時間複雑...

おかげでたくさんの男:)実装はEPERMを返すために必要とされないことを

Answer 1

n.mは良好な回答を提供しています。ロック所有権を保持するための構造体の仮定は、タグ付けしたLinux実装では間違っており、countメソッドn.mと似ています。触れる。

は、ここでは、カウントフィールドを見ることができます

struct 
    { 
    int __lock; 
    unsigned int __nr_readers; 
    unsigned int __readers_wakeup; 
    unsigned int __writer_wakeup; 
    unsigned int __nr_readers_queued; 
    unsigned int __nr_writers_queued; 
    int __writer; 
    int __shared; 
    unsigned int __flags; 
    } __data; 

/usr/include/bits/pthreadtypes.hからpthread_rwlock_tタイプの編集されたバージョンです。また pthread_rwlock_unlock.cはEPERMを返しません。ほとんどの作業は、ライターの所有者を pthread_rwlock_wrlock.cと pthread_rwlock_rdlock.cにチェックすることを中心に行われます。

これを小さなプログラムでテストして、ロックを宣言して初期化し、ロックを解除することができます。

時間の複雑さは、この実装では一定に近いようですが、あなたが思っていたかもしれない、あるいはそこにいたいと思っていたいくつかの機能に救済することによって得られます。

Answer 2

注意は何ですか。他の人のロックを解除した結果は、規格で規定されているように未定義です。

ロックが所有スレッドのリストの代わりに使用回数だけを格納する場合は、O（1）を達成するのは簡単です。実装がロックの所有権のチェックを主張する場合、スレッドは所有するロックを覚えておくことができます。そのようなロックの数は、通常は小さくする必要があります。そうでない場合でも、通常はLIFOの順序で複数のロックが取得されるため、一般的なケースはスレッド内の所有ロックのスタックによってカバーされます。