プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

SUSの read write lock の規定がバグってるという話 このエントリーをはてなブックマークに追加

http://austingroupbugs.net/view.php?id=722

glibcは Open POSIX testcase通らないんだけど、規格がバグってんじゃねーのとイチャモンついてる。

pthread_rwlock_wrlock は

Implementations may favor writers over readers to avoid writer
starvation.



と、実装依存でどっちもでいいよと言っていて、それにしたがってglibcは pthread_rwlockattr_setkind_np という非標準関数でポリシーを選べるようにしてあるのだが、


pthread_rwlock_rdlock のほうを見ると

If the Thread Execution Scheduling option is supported, and the threads
involved in the lock are executing with the scheduling policies
SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the lock if
a writer holds the lock or if writers of higher or equal priority are
blocked on the lock; otherwise, the calling thread shall acquire the
lock.



と、SCHED_FIFO, SCHED_RR の時は、write 優先にしなさいとある。じゃあ、実質オプショナルじゃないじゃんということになるかといえばそう簡単ではなく

同じく pthread_rwlock_rdlock の記述に、

The calling thread acquires the read lock if a writer does not hold the
lock and there are no writers blocked on the lock.



とあるので、readlock を recursive にとるのは許さないといけないように読める。しかし、これは write 優先ポリシーと組み合わせるとデッドロックしてしまうので混ぜるな危険なのである。

なので、SCHED_FIFOの記述も shall じゃなくて may にするか、リカーシブな read lockに関して記述を追加するかしないと workしないよ。と。

関連記事


linux | 【2013-07-15(Mon) 18:44:05】 | Trackback:(0) | Comments:(0)
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。