SevenZipRuby 作成メモ 3 - マルチスレッド

7z ファイルを読み書きする Ruby gem ライブラリである seven_zip_ruby の作成メモその 3 です。
ひとまずこれでメモは終了し、久し振りに mruby の世界へ戻ろうと思います。

最後のメモはマルチスレッドや GVL (Global VM Lock) についてです。

概要

SevenZipRuby では、LZMA や BZIP2 圧縮の 7z ファイルを作る場合、デフォルトでマルチスレッドによる圧縮をサポートしています。
今回は、このマルチスレッドへの対応について、メモしておきます。

また rb_thread_call_without_gvl の使い方についても書いておきます。
ただし、(他の記事もそうですが) 今回の記事はあまり正しいかどうか、あまり自信がありません。

Ruby のマルチスレッド処理と GVL (Global VM Lock)

Ruby には Thread クラスがあり、手軽にマルチスレッドプログラミングを楽しむことができます。
ただし、MRI (CRuby) では複数の CPU Core がある環境で複数のスレッドを作成したとしても、同時に実行されるスレッドは高々一つになります。
これは GVL というグローバルな Mutex があり、これを取得しているスレッドしか動作しないように実装されているためです。

CPython でも同様な実装らしく GIL (Global Interpreter Lock) というものがあります。
詳しくは Wikipedia の GIL の項目などを見てください。

さて、GVL は、現状スレッドセーフに書かれていない CRuby の各関数や SevenZipRuby のような拡張機能が、マルチスレッド環境下で (そこそこに) 動くように守ってくれています。
GVL があることで、C の拡張機能を書いたときに、特定の Ruby の C API を呼んだときなど、こちらが明示的に指定した箇所でしかスレッドの切り替えが起こらないようになっています。
例えば、以下のような C 拡張機能のコードでは、スレッドの切り替えが起こりません。

この例の場合、Hoge#test の実行中は、"check" の出力が止まります。
これは、Ruby の C 拡張関数の実行中は GVL は取得されたままで解放されることがないため、他のスレッドが実行されたりしないためです。

ところで、VC++ 2010 などで試す場合、上の test 関数を以下のように定義すると、"check" が 0.1s ごとに出力されます。

これは、Ruby 側に細工があり、上記の例では Sleep 関数は Windows API ではなく、適切に GVL を解放してから待ちに入る rb_w32_Sleep が代わりに呼ばれるためです。
SleepEx であれば、このようなことは起こらないので、試す場合はこちらを使うとよいでしょう。

`rb_thread_call_without_gvl` による GVL の解放

先に挙げた SleepEx の例で、"check" が 0.1s ごとに出力されるようにするには、rb_thread_call_without_gvl を利用します。

この関数は、引数で指定した関数を、GVL を解放した状態で呼んでくれます。
そのため、上述した test 関数を以下のように書くと、"check" が 0.1s ごとに出力されるようになります。

このように書くことで、slow_func は GVL を解放した状態で実行されます。

ただし、注意点として、GVL を解放した状態では、ほぼすべての Ruby 関係の API を呼ぶことはできない というものがあります。
上記の slow_func の中では、例えば rb_gv_get でグローバル変数にアクセスしたりはできません。そのため、重い数値計算など、時間がかかる処理に限定して行うとよいでしょう。

ちなみに、Windows では Sleep は rb_w32_Sleep になるので、上の例で SleepEx の代わりに Sleep を呼んでしまうと、GVL の扱いがおかしくなり、SEGV することになります。

7z.dll の呼び出し

以前に書いたように、7z.dll は内部で独自にスレッドを作成します。
そのため、以下のような方針で拡張機能を作ることにりました。

7z.dll が作ったスレッド内で呼び出される Ruby のコールバック関数は、そこで直接処理しない
その処理をするために、別途 Ruby のスレッドを作り、イベントループのような動作をさせる
Ruby スレッドが 7z.dll のイベント待ちをする際は、条件変数で CPU を消費しないようにして待つ

イベントループの作成

概念的には、以下のようなループで 7z.dll のコールバック処理を行います。

この rubyEventLoop は Ruby のスレッドとして rb_thread_create から実行されます。
この中では、g_action_mutex で g_action をガードしながら、g_action_cond_var の知らせを wait_for_event で待ちます。

イベント登録側は以下のようになります。

実際にはエラー処理などがありますが、概要としては以上のように Ruby 用のスレッドを用意して 7z.dll の処理を行っています。

イベント待ち

イベント待ちの部分では、適切に GVL を解放した上で Mutex の wait を呼ぶ必要があります。
上記の例の wait_for_event では、以下のように待つ必要があります。

このように GVL を解放して Mutex の wait を呼ばないと、wait を呼んだ途端に他の Ruby スレッドが GVL を取得することができなくなってしまうので、ハングします。

というわけで、マルチスレッドの場合は GVL をきちんと考慮して書く必要があります。

私自身もあまり深く分かっているわけではないですが、半年後ぐらいには seven_zip_ruby の実装を忘れてしまいそうなので、メモしておきました。

覚え書き

SyntaxHighlighter

2013年12月27日金曜日