Rubyのスレッド周りの話 - Qiita
Rubyのスレッド周りを追ってみた。 最も効率が良いスレッドモデルは結論出ないんじゃないかと（物理的な環境、何を実装するか、性能以外の面でメンテナの問題とか）。 Ruby1.8系 「グリーンスレッド」 Ruby1.8ではOSではなくて仮想マシン(VM)上で実装されたマルチスレッドシステムを採用した。 これを「グリーンスレッド」という。カーネルでスレッドがサポートされていなくても動作する。 つまり、OSに依存せずにマルチスレッドを実現する。 メリット スレッドの起動、並列化の性能 Linux のネイティブスレッドの性能を上回る。つまり、ネイティブスレッドより低コストで起動、並列化を行える。 起動については、独自のアドレス空間を確保する必要がなく、わずかな量の仮想メモリを取得するだけ。 並列化については、カーネルレベルとユーザレベルの切り替えが必要ないことなど。 さまざまなOS間で移植が楽 デ
グローバルインタプリタロック(GIL)とは
LL言語がマルチプロセッサ環境のメリットを捨ててまでグローバルインタプリタロックを採用している理由について調べてみた。 その為にはプロセスとスレッドについての前提知識がけっこう必要だったので、ついでにざっくり調べてみた。 LL言語がマルチプロセッサ環境のメリットを捨ててまでGILを実装している理由 結論を先に書くと、LL言語がマルチプロセッサ環境のメリットを捨ててまでGILを実装している一番の理由は、「スレッドセーフではないCで書かれたモジュールをたくさん使っているから」ということになるっぽい。 この結論に至るまでの色々な前提知識についても書いておく。 プロセスとスレッド プロセスとスレッドの特徴をざっくり対比させて書くとこんな感じになる。 ユーザースレッドとカーネルスレッド ユーザースレッド ユーザ空間で実装されたスレッド機構をユーザースレッドと呼ぶ。 1つのプロセス内の複数のスレッドは
グローバルインタプリタロック - Wikipedia
グローバルインタプリタロック（英: Global Interpreter Lock, GIL）とは、プログラミング言語のインタプリタのスレッドによって保持されるスレッドセーフでないコードを、他のスレッドと共有してしまうことを防ぐための排他 ロックである。インタプリタのひとつのプロセスごとに必ずひとつの GIL が存在する。 プログラミング言語においてグローバルインタプリタロックを採用した場合、複数のスレッドを持つインタプリタプロセスの並行性を制限してしまう。プロセスをマルチプロセッサのマシンで実行させた場合、ほとんどあるいはまったく速度の向上が見られない。 こうしたロックを採用する理由として、下記のものがある。 シングルスレッドのプログラムの速度向上（すべてのデータ構造に対して別々にロックを獲得・解放する必要がなくなる） 通例スレッドセーフではないC言語のライブラリとの結合が容易である。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
