[ruby-dev:40060] Re: Linuxで bm_vm3_thread_mutex.rb が刺さってしまい実行が完了しない

>> last_thread 0で10秒なところから、自分的にはデッドロックチェックありでも15秒以下に
>> したいなーとか思って悩んでいるのですが、まだ良い案がありません。
>
> もうちょっと自分で意図を補足しますと、Fedoraはext/opensslのコンパイル通らない問題で、実質trunkのサポートプラットフォームからすでに外れてしまっている状況なので、筋の良くないfixを急いで入れるよりも根本解決するべく、もっと分析を進めた方が前向きかなぁと
>

そろそろ苦情が来そうですが、もうちょっと分析したので記録のために書きます。
thread.cのmutexの実装をよくよく見るとGVLを離している期間があまりにも短すぎてmutex->lockを
導入してる意味がほとんどないように見えます。またいくつかの箇所でGVLとmutex->lockを同時につかんだり、
GVLを離した直後にmutex->lock or th->interrupted_lock
をつかんでいたりと、「逆に性能に悪影響があるのではないか？」と思える箇所があったので、添付ののパッチ(0001-Remove-mutex-lock-and-th-interrupt_lock)で実験してみました。

一言で言うと mutex->lock と th->interrupt_lock を廃止し、GVLを真のジャイアントロックにする。というパッチです。

bm_vm3_thread_mutex.rb に関しては１０回の平均値が以下のような数値になっており、今までのどの測定よりもいい数値になっています。

1.340147932  seconds time elapsed   ( +-   1.406% )

また、他のベンチの数値も remove-mutex-lock.txt に５回平均の比較表を添付しましたが、ほぼ差がないようです。
そろそろささださんを召喚するべきかな？元々のmutex->lockの導入意図とか知りたいし。

ps ちょっと意図が理解できないsched_yield()がいくつかあるので、今後整理したいです。現状のLinuxのスケジューラだとsched_yield()はほぼNOPに近い動きをするので、意図通り動いていない可能性があります。