pthreadの読み取り/書き込みロックでライターの枯渇を防ぐ方法
* nixシステム（Linuxなど）のPOSIXPthreadでの読み取り/書き込みロックに関していくつか質問があります。
読み取り/書き込みロックのデフォルトのバイアスは何ですか？つまり、書き込みよりも読み取りを優先しますか、またはその逆ですか？このデフォルトの動作を変更するためのAPIを提供しますか？.
Posix pthreadは、ライターの飢餓を防ぐためにpthread_rwlock_tを変更できるように、いくつかのAPIを提供しますか？私が読んだものから（私が間違っている場合は訂正してください）、デフォルトの実装はリーダースレッドに偏っているため、ライタースレッドは飢餓に直面する可能性があります。
DavidButenhof著のProgrammingwithPosixスレッドからrwlockのサンプル実装を読みました。
Posix pthreadsがライタースレッドの飢餓をどのように処理するか知りたいですか？書き込みの枯渇を防ぐ読み取り/書き込みロックの属性を設定できるAPIはありますか（私はそれについて聞いたことがありません）？または、ユーザーはこの問題を処理する必要がありますか？
答えが実装定義だと思うなら、Linuxでどのように行われるかの例を教えてください。それが私が探しているものだからです。
* nixシステムのソリューションが必要なだけであることに注意してください。失礼だとは思わないでください。ただし、Windows固有のコードを投稿しても意味がありません。
あなたの助けと忍耐に感謝します:)
これは確かに実装に依存します-したがって、Linuxについて具体的に質問したので、私のコメントは、最新のglibcで使用されているpthreadの現在のNPTL実装に言及しています。
ここには、関連しているが別個の2つの問題があります。まず、この状況があります：
- 現在保持されている読み取りロックがあり、ライターが待機しています。新しいスレッドが読み取りロックを取得しようとします。
ここでのデフォルトのアクションは、リーダーが続行できるようにすることです。つまり、ライター上で効果的に「キューをジャンプ」します。ただし、これをオーバーライドすることはできます。 pthread_rwlockattr_setkind_np()関数を使用してpthread_rwlock_init()に渡すattrにPTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NPフラグを設定すると、rwlockはリーダーをブロックします。上記の状況。
2番目の状況は次のとおりです。
- 最後の所有者がロックを解除し、リーダーとライターの両方が待機しています。
この状況では、NPTLは常にリーダーよりもライターをウェイクアップします。
まとめると、上記は、PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NPフラグを使用する場合、ライターが飢えているべきではないことを意味します（もちろん、ライターの連続ストリームがリーダーを飢えさせる可能性があります。C'est la vie）。ソースをチェックすることで、これをすべて確認できます（すべて非常に読みやすいです）1）in pthread_rwlock_rdlock.c および pthread_rwlock_unlock.c 。
PTHREAD_RWLOCK_PREFER_WRITER_NPもありますが、正しい効果があるように見えますない-おそらくバグ（またはそうでない-） 以下のジルによるコメントを参照してください。
1. ...または少なくとも、2010年にこの回答を書いたときのことです。NPTLの最新バージョンはかなり複雑で、分析をやり直していません。