僕個人としてはマルチスレッドを意識して書いた事が無いのでかなり有意義な話が多く感じ、読み始めてみました。
時間の関係で、全体を流した程度ですが実際に有意義な話は多く感じはしました。実際、GUI プログラミングではマルチスレッドを利用してプログラムを書く事になりますし、何かしらのデーモンを作る時にもスレッドを使う事がままあります。こと最近に至っては利用する場面も多く、ある程度の tips は知っておいた方が良いのだと思います。

本書で得られ (?:た|る) 事

全体を通して自分が何を得られたのか? 僕の知見は下記の通りです。

  • モニタとロック
  • immutable
  • Gurded lock
  • Balking
  • Future

モニタとロック

おそらくマルチプログラミングをがしがしやってる人にとっては常識何でしょうけど、モニタとロックを本書にて知りました。
まぁロックはファイル操作において排他処理する際に行なうので知ってたんですが、モニタ (という用語) を知らなかったです。スレッドの排他制御の事をモニタって言うんですね。

immutable

Ruby 界隈や、関数型界隈では割と声高に主張されている事なんですが、変更不可能なデータを使う (immutable に保つ) 事で信頼性を担保するって話です。これがマルチスレッドになってくると、コードの実行タイミングによっては意図しないデータを受け付ける事になるので専用のメソッド (synchronized) で守る必要が出てきます。そこで、immutable であればわざわざ守る必要も無いと云う話ですね。マルチスレッドにおいて関数型が実は手続き型よりも楽にプログラムが書けると云うのはこの辺が関係してるっぽいですよね。

Gurded lock

push と get のタイミングを合わせる為に wait をかけるパターン。client と server のクラスを待ち合わせさせる為に request queue クラスを使ってお互いのタイミングを合わせます。ポイントは queue の中身に request があるかどうかなので実装自体はシンプルに出来ます。synchronized でガードもかけてるので特に他に気をつけるポイントも無かったです。要はロックファイルと発想が一緒ですし。

Balking

条件によっては何もせずに実行をキャンセルするパターン。特定の場合に意義の無いコードの実行を取りやめる。この取りやめの条件を、本書ではガード条件と表現しています。管理するクラスにて実行フラグを設定し、各スレッドが、実行前にチェックする事で判断を行なう。シングルスレッドの場合だと、各インスタンスに持たせがちなフラグの情報を管理クラスにてフラグを管理する手法かと認識しました。

Future

実行の先送りパターン。実行予約を行なっておき、それぞれが各スレッドにて実行を行なう。こうする事で CPU の使用率をなるべく活かす様になり、プログラム自体の応答性も上がる様になります。実際、受け取って即処理じゃなく、受付と実行を分けてるので応答性に関して納得です。トークン発行して後で処理結果を発行するのと全く同じ事なんですよね。

まとめ

本当にざっくりと読んだ内容のまとめでしかないんですが、マルチスレッドにて注意すべき事って結構ファイル処理で考えるべき事柄と似てるんですよね。特に、データベースを使わないで、ファイルをデータの保存先に使用して CGI を実行する時に昔これやったわっていう内容です。ロックファイルとか、Gurded lock とか、他にも色々。CGI でのファイル処理もある意味マルチスレッドなので、こういう部分学ぶ良い機会になったんでしょうね。

雑感としては、購入して手元に残すまでは要らないけど、一読しておくのは良いのかもって所でした。そもそも僕自身がマルチスレッドプログラミングを現在別段必要としていないと云うのが大きいと思いますが。

今月のノルマはコレでなんとか達成ですね。初月からこけなくてよかったです。来月の読む本を考えます。