Rubyのスレッドは、いつも厄介な問題だ。Ruby 1.8はユーザ空間スレッドを実装しているがパフォーマンス問題を抱えており、マルチコアを活用することもできない。
Ruby 1.9はRubyスレッドをすべてカーネルスレッドに対応付けるよう変更することで、Ruby 1.8のスレッドの非効率さをある程度取り除いている。しかし依然として、Rubyスレッドは同時に1つしか実行できない。
原因はGIL（グローバルインタプリタロック）にある。これはGVL（グローバルVMロック）と呼ばれることもある。すべてのRubyスレッドは、実行する前にGILを取得する必要があるためだ。Pythonのような言語と同様、Rubyもこうした実装になっている（約10年にわたり、意見が分かれている問題だ）。
この数年で、いくつかのRuby実装がこの問題を取り除いてきた。JRubyとIronRubyは、もはやGILを使っていない。
MacRubyもこれらの仲間入りをして、GILなしで動くようになった、とLaurent Sansonetti氏は説明している。
すべてのMacRubyスレッドはOSカーネルによってスケジューリングされ、何かする前にObjective-Cガベージコレクタ（自分自身のスレッドで動いている）に登録されます。
依然として、MacRubyランタイムには、すべてのスレッドにわたる共有状態があるが、1つのスレッドだけがアクティブになれるのではなく、共有データ構造へのアクセスを同期するようになっている。詳しくは次の通りだ。
コアオブジェクトには、共有データ構造にアクセスするときに使うロックが含まれています。共有データ構造には、例えば、LLVMキャッシュ、各種スタブキャッシュ、BridgeSupportキャッシュなどがあります。
それ以外はすべてVMクラスに移動しました。これは完全にロックフリーです。VMオブジェクトは要求時に、ランタイムにアクセスしようとするスレッドごとに1度だけ作られます。VMオブジェクトには、スレッド実行に特有のデータ構造が含まれています。例えば、現在のブロック、バインディング、例外などです。VMはコアを呼び出してコアロックを取得することもありますが（例えば、メソッドを定義するとき）、ほとんどの時間、同時に動かすことができます。
新しいスレッドの仕組みはMacRubyのexperimentalブランチで利用可能だ。これはMacRubyの次期バージョンとなるべく設計されている。このブランチには、MacRubyで作ったサンプルの（シンプルな）Webサーバも含まれている。
次期MacRubyの安定バージョンが新しいスレッドの仕組みとともにリリースされると、Ruby 1.8（ユーザ空間スレッド）とRuby 1.9.xに対して、GILのない平行スレッドを備えたRuby実装は3つになる。JRubyとMacRubyはいずれも、Ruby 1.9.x言語およびライブラリをサポートしている。
PythonにもRuby 1.9.xと同様のGIL問題があるのだが、Unladen Swallowプロジェクトは2010年までにGILをなくすと約束している（それができるかと、提供されたパッチが実際に公式のPythonにマージされるかは、別の問題だ。この10年間、GILをなくすパッチは宙に浮いたままだ）。
最後の注意：RubyであれPythonであれ、GILに関する議論をすると、こうした言語のスレッドは、平行処理に適したやり方ではないだけだ、という意見が出る。また、GILはCPUバウンドなコードにとってのみ問題であり、I/Oバウンドなコードでは問題ではない、という意見もある。I/OバウンドなコードではGILは適度に解放され、I/O操作中に他のスレッドが動けるためだ。その点を考慮して、Rubyでマルチコアを活用できるよう、あなたはCPUバウンドなコードをどのように実装しますか？それとも、あなたは複数のOSプロセスを作成・管理することで対処しますか？