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しないよ。と。

Tweet

関連記事

• lock elision はいったね (2013/07/22)
• SUSの read write lock の規定がバグってるという話 (2013/07/15)
• readdir_r は使ってはいけないという話 (2013/06/18)