update.Rubyのスレッド周りを追ってみた。効率が良いスレッドモデルは結論出ないんじゃないかと(物理的な環境、何を実装するか、性能以外の面でメンテナの問題とか)。「グリーンスレッド」Ruby1.8ではOSではなくて仮想マシン(VM)上で実装されたマルチスレッドシステムを採用した。これを「グリーンスレッド」という。カーネルでスレッドがサポートされていなくても動作する。OSに依存せずにマルチスレッドを実現する。ネイティブスレッドの性能を上回る。ネイティブスレッドより低コストで起動、並列化を行える。起動については、独自のアドレス空間を確保する必要がなく、わずかな量の仮想メモリを取得するだけ。並列化については、カーネルレベルとユーザレベルの切り替えが必要ないことなど。さまざまなOS間で移植が楽デメリットマルチコアやマルチプロセッサを全くいかせない複数のプロセッサに処理をわりあてるなど、OS標準の平行処理を利用する事ができない。PCのプロセッサは、動作周波数の引き上げが物理的な限界に近づくことによって、マルチコアやマルチプロセッサの波が訪れたがそれを生かせない他スレッドのブロックI/O処理を実行する場合、他の全てのスレッドをブロックする可能性がある。(ただし、グリーンスレッドがI/O関連でかならずブロックされるということでなく正しく非同期IO処理を実行すれば問題ない。コンテキストスイッチ(というかグリーンスレッドでのスレッド切り替えは重い)http://subtech.g.hatena.ne.jp/mala/20090920/1253447692Ruby1.9系〜「ネイティブスレッド」MRIにYARVが組み込まれ、これになった。いわゆる普通のスレッド処理。OSの実装を生かしたもの。グリーンスレッドより、I/Oやコンテキストスイッチの処理に関して、大きく上回る性能を持つ。Lock)とされる)で処理されているので素のネイティブスレッド処理の性能をそのまま生かすことはできない。GILとは、プロセス単位にスレッドセーフでないコードを他のスレッドと共有してしまうのを防ぐための排他ロック。VM単位でがっちりと大きなロックをしてしまうので、複数のスレッドをもつプロセスの平行性も制限してしまう。プロセスをマルチプロセッサのマシンで実行させても、ほとんど(全く)速度は向上しない。そのかわり、個別のデータごとのロック処理が必要ないためシングルスレッドのパフォーマンスについては良くなる。単純なパフォーマンスについては落ちるのでこれ採用した時に下記のような議論や意見などはいろいろあったみたく、このGILをはずしたいという意見はたびたびあがるらしい。単純にはずすと下記のような事がおこるので今にいたるという感じみたい。Rubyがそもそもスレッドセーフ実装じゃないSEGVおきるよ。これからもスレッドセーフな実装を続けるの大変すぎる。C拡張ライブラリ側でスレッドセーフなら、それを呼ぶときはGILをはずして実行しても良い。zlibではrb_thread_call_without_gvlをコールしてGVLをはずしている。C拡張ライブラリのほうだって、みんなスレッドセーフとは限らない速度向上シングルスレッドなら、そもそも今のほうが速いから直してもなー。遅いのって、ネットワークとかI/Oまわりでしょ?など。ネイティブスレッドはほぼ一つ。下記は参考なんでGILつかうの?http://qa.atmarkit.co.jp/q/2814C拡張ライブラリ(RubyからC実装で呼べるライブラリが今後もスレッドセーフと限らんし、そうだとしてもたぶんバグるだろう速度向上(全てのデータ構造に個別にロックを持つ必要がなくなる)同時に実行されるネイティブスレッドとしては1つただし、ビジースレッド状態になってもタイマー管理でスレッドは切り替えられる(rubyプロセスに対して、timerのスレッドが1つある。motsat@motsatFollow株式会社SmartHR社会の非合理を、ハックする。upLoginユーザーは見つかりませんでした。