Rubyの並列並行処理のこれまでとこれから
https://techlife.cookpad.com/entry/2023/08/31/152511
2023-08時点でのRubyの並列並行処理のまとめ
Ruby 1.8まで
M:1モデル（世間的には1:N）
ユーザーレベルスレッドと呼ばれる仕組み
OSなどが提供するネイティブスレッド（PthreadやWindows APIのスレッド）1つで複数のRubyスレッド（Thread.new{}で作るやつ）を管理
1つのネイティブスレッドで複数（M個）の Rubyスレッドを管理するので、M:1 モデル
Rubyスレッドの切り替え
1. I/Oや sleep、Mutex などで待ちが入るタイミング
select（に類する）システムコールで準備できたかを定期的に確認しながら管理
2. 一定時間（タイムスライス）が経過したときのタイミング
Ruby 1.9 Thread
1:1モデル
1つのネイティブスレッドに1つのRubyスレッド
GVLが導入され、Rubyスレッドは同時に1つしか動かないことが保証される
並行処理は行えるが並列処理は行えない
スケジューリングはネイティブスレッド任せ
Ruby 1.9 Fiber
ユーザレベルスレッドの利点を残すために導入された
Ruby 1.8 のユーザレベルスレッドとほぼ同様ですが、タイムスライスがなく、I/O などで自動的にスイッチすることがない
Ruby 3.0 の Fiber scheduler
I/O 等のブロッキング処理をトリガーにフックを呼び出す仕組み
Fiber scheduler
自分で Fiber をスケジュールする処理を記述するための仕組み
実際には、自分で記述するのではなく実装している gem を使うことが多いはず
Ruby 3.0 の Ractor
1:1スレッド
Ractor内にRubyスレッドを1つ作り、1ネイティブスレッドを要求する
他言語の戦略のうち、Erlang, Elixirのアプローチを採用
領域を完全に分けてしまう: Unix などのプロセス、Racket（のPlace）
すべてのデータを Immutable にして、Immutable なデータしか共有できないようにする: Erlang, Elixir（のProcess）
型でいい感じになんとかする: Rust
データを共有する方法を標準化する: Java, Golang（Goroutine）
実行時にやばそうなところを検知して修正する: Valgrind, Thread sanitiser, ...
Unixなどのプロセスに近いが、共有可能な部分は共有するしMutableなデータでもロックを必須とするなら共有可能にした
共有可能オブジェクトの制限が厳しく、ふつうのRubyプログラムはたいてい動かない
各Ractorが独自のVMロックを取得しているので、真の並列処理ができ、CPU負荷が高い処理でもマルチコア活用ができる
Ruby 3.3.0からM:Nスレッド導入
1:1モデルの欠点として、生成が遅いし生成できる数が少ない
M:Nスレッド
RubyスレッドM個にたいしてネイティブスレッドがN個
N=コア数
ユーザーレベルスレッドで問題となっていたブロック問題
ブロックする可能性のある処理の実行中は1:1スレッドにしておく
準備のできたRubyスレッドを実行するためのネイティブスレッドを1つ余分に追加することで、他のRubyスレッドに処理がうつるようにする
M:Nスケジューラは、切り替わらなくなるかもしれない、といった危険のなくなった、そしてタイムスライスで切り替わる（プリエンプションがある）組み込みの Fiber schedulerみたいなもの、というとらえ方もできると思います。
Goroutinesとの類似
よく似ているが違いもある
goroutineはどれも順不同で実行可能
Rubyスレッドは同じRactorに所属していると同時に動かない（GVLをもつRubyスレッドしか動かせない）
Thread Local Storageに依存した作りになったコードを使うと破綻する
3.3.0時点の挙動
RUBY_MN_THREADS=1 という環境変数でメインRactorでのM:Nスレッド対応を指定出来るようにする
https://bugs.ruby-lang.org/issues/19842
Ractor性能改善
Ractorが遅い最も大きな理由はGC
GCするために全てを止める必要があり、止めた状態で唯一のネイティブスレッド上でGCが実行されるようになっている
Ractor単位で並列にGCするRactor local GCを検討している