ちょっと古い話題だけど、glibc 2.18に lock elision入ることが確定しましたね。lock elisionとはHaswellから搭載されるHTM(Hardware Transaction Memory) をつかって、pthread_mutex_* の並列度を劇的にあげようというパッチ。

ワーストケースでは逆に何十倍も遅くなるとか非互換ありでしかもPOSIX違反やんけなどと指摘されつつもIntelの強力なプッシュによりデフォルトでONになった。

ロック性能とか気になる人はチェックしとくといいよ。

関連記事

• ioctl の man page が fix された (2013/11/18)
• lock elision はいったね (2013/07/22)
• SUSの read write lock の規定がバグってるという話 (2013/07/15)

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

関連記事

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