QA@IT
«回答へ戻る

シングルスレッド性能は2.じゃなくて3.

440
 2. 現在、そして将来の C 拡張ライブラリは (きっと) スレッドセーフには作られない(し、作ったつもりでもバグってるに決まってる)
 3. 上記の対策でロックを随所に入れると、シングルスレッド性能が落ちる
 
-上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 2. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。
+上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 3. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。
 
 結局、akr さんの仰られているとおり、単純になくすとレースコンディションってレベルではすまず SEGV してしまうし、頑張ってなくしても C 拡張ライブラリがあるからそこで SEGV するだろうって話になるので、 C 拡張ライブラリとの親和性をとてもとても重視している CRuby というプロダクトのデザイン上の決定としては、GVL を外すという判断はあまり簡単ではありません。

すでに回答がついてるのと、まつもとさんや、ささださんが既に詳細に書かれていますが、

理由は大きく3つありまして、

  1. 現在の CRuby が (C レベルで) スレッドセーフではない
  2. 現在、そして将来の C 拡張ライブラリは (きっと) スレッドセーフには作られない(し、作ったつもりでもバグってるに決まってる)
  3. 上記の対策でロックを随所に入れると、シングルスレッド性能が落ちる

上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 3. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。

結局、akr さんの仰られているとおり、単純になくすとレースコンディションってレベルではすまず SEGV してしまうし、頑張ってなくしても C 拡張ライブラリがあるからそこで SEGV するだろうって話になるので、 C 拡張ライブラリとの親和性をとてもとても重視している CRuby というプロダクトのデザイン上の決定としては、GVL を外すという判断はあまり簡単ではありません。

すでに回答がついてるのと、[まつもとさん](http://www.rubyist.net/~matz/20070913.html)や、[ささださん](http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview38.html)が既に詳細に書かれていますが、

理由は大きく3つありまして、
1. 現在の CRuby が (C レベルで) スレッドセーフではない
2. 現在、そして将来の C 拡張ライブラリは (きっと) スレッドセーフには作られない(し、作ったつもりでもバグってるに決まってる)
3. 上記の対策でロックを随所に入れると、シングルスレッド性能が落ちる

上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 3. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。

結局、akr さんの仰られているとおり、単純になくすとレースコンディションってレベルではすまず SEGV してしまうし、頑張ってなくしても C 拡張ライブラリがあるからそこで SEGV するだろうって話になるので、 C 拡張ライブラリとの親和性をとてもとても重視している CRuby というプロダクトのデザイン上の決定としては、GVL を外すという判断はあまり簡単ではありません。

回答を投稿

すでに回答がついてるのと、まつもとさんや、ささださんが既に詳細に書かれていますが、

理由は大きく3つありまして、

  1. 現在の CRuby が (C レベルで) スレッドセーフではない
  2. 現在、そして将来の C 拡張ライブラリは (きっと) スレッドセーフには作られない(し、作ったつもりでもバグってるに決まってる)
  3. 上記の対策でロックを随所に入れると、シングルスレッド性能が落ちる

上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 2. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。

結局、akr さんの仰られているとおり、単純になくすとレースコンディションってレベルではすまず SEGV してしまうし、頑張ってなくしても C 拡張ライブラリがあるからそこで SEGV するだろうって話になるので、 C 拡張ライブラリとの親和性をとてもとても重視している CRuby というプロダクトのデザイン上の決定としては、GVL を外すという判断はあまり簡単ではありません。

すでに回答がついてるのと、[まつもとさん](http://www.rubyist.net/~matz/20070913.html)や、[ささださん](http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview38.html)が既に詳細に書かれていますが、

理由は大きく3つありまして、
1. 現在の CRuby が (C レベルで) スレッドセーフではない
2. 現在、そして将来の C 拡張ライブラリは (きっと) スレッドセーフには作られない(し、作ったつもりでもバグってるに決まってる)
3. 上記の対策でロックを随所に入れると、シングルスレッド性能が落ちる

上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 2. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。

結局、akr さんの仰られているとおり、単純になくすとレースコンディションってレベルではすまず SEGV してしまうし、頑張ってなくしても C 拡張ライブラリがあるからそこで SEGV するだろうって話になるので、 C 拡張ライブラリとの親和性をとてもとても重視している CRuby というプロダクトのデザイン上の決定としては、GVL を外すという判断はあまり簡単ではありません。