難しい問題をコンパイラレベルで弾くことができるRustの並行処理　データ共有の有無から見る、2つのサンプルコード

鈴木氏の自己紹介と、今日話すこと

鈴木文太氏（以下、鈴木）：よろしくお願いします。「Rustにおける並行処理」について発表していきたいと思います。私はGO株式会社の鈴木文太と申します。2021年6月に入社して、今はタクシー事業者向けの管理画面の開発などをやっています。

今回話すことについてですが、まずプロセスと並行・並列処理の基本について少しお話ししたあとに、スレッド間でデータ共有がない場合のRustのコードと、スレッド間でデータ共有がある場合のRustのコードを示して、Rustで並行処理を扱う際のメリットやデメリットについて話したあとに、まとめみたいな感じでやっていこうかなと思っています。

並行処理の難しいところ

鈴木：（プロセスと並行・並列処理の基本については）森下さん（森下篤氏）が最初のほうにわかりやすく書いてくれたので、このあたりはスキップして……。

よく「難しい」と言われる並行処理について、何が難しいのかということですが、代表的な問題としては、具体的にプロセス間でのデータ共有が難しくて、デッドロックがやはり有名な問題かなと思います。

デッドロックというのは、プロセスとかスレッドがお互いのリソースの解放を待ち続けて処理がロックしてしまい、それぞれの処理が進行しなくなる状態で、RDB（Relational Database）とかでも見聞きすることが多いかもしれません。

データ共有がないパターンの並行処理、データ共有があるパターンの並行処理

鈴木：（スライドを示して）データ共有がないパターンのRustのコードですが、thread::spawnで新しくスレッドを立てて2秒待つというコードと、もう1個立てて1秒待つというコードを実行した結果が下に書いてあります。こちらの"Hello from thread 2"が先にコンソールに出力されます。これに関しては特に説明する必要もなくて、生のスレッドをそのまま使っている感じです。

データ共有があるパターンの並行処理ですが、いろいろやり方はあると思いますけれども、今回はRustが標準ライブラリで提供しているチャネルを使ってのスレッド間通信について話をしようと思います。

Rustのチャネルについてですが、簡単に言えば「スレッド安全なキューのようなもの」と思ってもらっていいかなと思います。スレッド安全というのは、データ競合などの未定義動作を起こさないという意味ですね。

チャネルの使い方のコードです。mpscというところからチャネルを作って、新しくスレッドをスポーンして、その中でsendメソッドでチャネルに"World!"という文字列を入れて、元のメインスレッドでrecvメソッドでデータを受け取ってプリントすると、"Hello, World!"と出るよという話です。

先ほどのスライドに貼っていたのですが、mpscクレートについてです。Rustでは、stdライブラリからmpscをインポートすることによって、チャネルを使うことができるということです。

mpscはmulti-producer、single-consumerの略で、以下の特徴があります。multi-producerは、チャネルにsendするsenderを複数個作成することが可能です。それに対してconsumerのデータを受け取るreceiverは1個しか作成できない性質があります。

これだとreceiverが1つしか作れないため、困ることがあることもあるという感じです。

具体的な例で、Webアプリなどでログへの書き込みがどんどんチャネルに溜まっていき、receiverの処理が間に合わない時があるとして、そういう場合にmulti-producerなら一応複数作るということもできるということで、スレッド安全にして複数のスレッドからデータを読むようにする場合のサンプルコードを紹介します。

そのためにはMutexとArcというものを使うので、その説明をしようと思います。

Mutexについてです。複数のスレッドstd::syncからインポートできて、複数のスレッドからアクセスされると困るデータを保護するために、ロックの仕組みを提供する機能があります。

ArcはAtomic Reference Countの略で、複数のスレッド間でデータを共有するための所有権を管理するための仕組みを提供できます。MutexとArcは一緒に使うことが多い気がします。

サンプルコードです。（スライドを示して）stdとmpscがチャネルを作るところまでは一緒です。Arc::new(Mutex::new(receiver))というところで、右側に簡単な図を書いたのですが、mpscからインポートできるreceiverは、ロックやアトミック参照カウントが基本的には使えないので、mutex::newでラップすることにより排他ロック機能を使えるようにして、Arc::newでmutexをラップすることにより、アトミック参照カウントを使えるようにします。

1個目のfor文の中ですが、Arc::cloneでクローンすることにより、参照カウントを増やします。これによってどのスレッドに所有権があるかが、コンパイラ側にわかりやすくなります。

スレッドをspawnしてrx.lock。これはMutexの機能で、recvでロックを取ってからデータを受け取ることができます。下のほうはsenderです。これは複数送れるので、特に説明はいいかなと思います。

Rustで並行処理を扱う際のメリット・デメリット

鈴木：Rustで並行処理を扱う際のメリットやデメリットについてです。メリットは先ほどのMutexとかArcの話が少し複雑だったと思いますが、あれがあるおかげで、コンパイルが通った時点で、スレッドの安全性とスレッド整数性がかなり担保されているので安心感があり、それでいて速度も最高レベルになります。Rustによく言われることなのですが、ゼロコスト抽象化というところですね。

デメリットといえば、ArcやMutexなど、ロックや参照カウント周りの幅広い知識がけっこう必要かなと思いました。

Rustの並行処理は難しい問題をコンパイラレベルで弾けるのが便利

鈴木：所感です。スライドを作っていて思ったのですが、データ競合などの難しい問題をコンパイラレベルで弾けるのが、やはりかなり便利かなと思いました。他の言語でデータ競合のバグが発生してしまった場合、再現とか修正がかなり大変になりがちです。

でもRustの場合は、発生可能性がある場合、だいたいコンパイルエラーになるので安心感があるかなと思いますね。

あと、入門してから時間が経って、あらためて調べて思ったのですが、最近は日本語のわかりやすい資料が増えてきていて、Rustの学習コストは以前と比べたら下がってきているのかなと思いました。

今回の発表のまとめです。データを共有する時と共有しない時のRustの並行処理の書き方を軽く説明したのと、標準のライブラリを普通に使うだけでは実現できないので、応用的なチャネルを使う方法を1個説明しました。

あとはRustで並行処理を扱う際のメリットやデメリット、それから所感というか感想を発表しました。まだ時間はあるのですが、Rustの発表は以上になります。

質疑応答

司会者：鈴木さん、ありがとうございました。質問がいくつか来ていますね。読み上げますね。「いいね」が2個ついている「単語としてはGo編と共通のチャネルが出てきましたが、RustのチャネルとGoのチャネルは概念としてはどの程度が共通なのでしょうか？」という質問はいかがでしょう？

鈴木：概念としては同じものですが、文法上の表現方法などはGoとRustではいろいろと違うと思いますね。

司会者：はい。あといろいろと来ていますが、もう1個ぐらいチョイスしてもらえると。

鈴木：「複数プロセス複数スレッドの場合でも同じように上手いことやってくれますか？」という質問です。そうですね。（どの程度OS側の機能を使ってデータを共有するかにもよると思いますが）複数プロセス複数スレッドの場合でも同じようにやってくれると思います。コンパイルが通るのであれば、データ競合は起きないと思います。

司会者：ありがとうございます。以上で鈴木さんのパートを終了したいと思います。鈴木さん、ありがとうございました。