perlthrtut - Perl におけるスレッドのチュートリアル
このチュートリアルは、Perl 5.6.0 において導入された新しい Perl インタプリタ スレッド(iスレッド(ithreads)と呼ばれる)の特徴を説明するものです。 このモデルにおいては、それぞれのスレッドはそれ自身の Perl インタプリタで 実行され、スレッド間で共有するデータも明示的でなければなりません。 ithreads のユーザーレベルインターフェースは threads クラスを使います。
注意: Perl のバージョン 5.005 には、5.005 モデルと呼ばれる Threads クラスを使う別の古いスレッド機能がありました。 この古いモデルは問題があることが知られていて、非推奨で、バージョン5.10 で 削除されました。 できるだけ速やかに既存の5.005スレッドを新しいものに移行することが 強く勧められます。
perl -V で Platform セクションを見れば、どちらのスレッド機能があるのか
(あるいは無いのか)を知ることができます。
もし useithreads=define となって
いればiスレッドをサポートしているし、use5005threads=define とあれば
5.005 スレッドです。
両方とも出ない場合、あなたの Perl はスレッドをサポートしていません。
両方ある場合は問題があります。
threads と threads::shared のモジュールはコア Perl 配布に 含まれています。 さらに、CPAN では別個のモジュールとして保守されているので、更新については CPAN をチェックできます。
スレッドとはプログラム内を通じて一つの実行点を持った制御のフローです。
こういうと非常に多くの点でプロセスに似ているように聞こえるでしょう。 確かにその通りで、スレッドはひとつのプロセスにおける細かい部分の一つです。 全てのプロセスは少なくとも一つのスレッドを持ちます。 そしてこれまでは、Perl を走らせるプロセスは全てただ一つのスレッドを 持っていました。 しかし 5.8 になって、余分にスレッドをつくることができるようになりました。 それがいつどのように、いかにしてなされるのかをこれから示していきましょう。
スレッドプログラムを構築する 3 つの基本的な方法があります。 どのモデルを選ぶかはプログラムに何をやらせるかに依存します。 多くの重要なスレッドプログラムにおいては、プログラム中の異なる部分に 異なるモデルを選択する必要があるでしょう。
ボス・ワーカーモデルでは通常、一つの ボス スレッドと、一つ以上の ワーカー スレッドを持ります。 ボススレッドは必要とされるタスクを集約ないし生成します。 それからそれらのタスクを適したワーカースレッドに分配します。
このモデルは GUI とサーバプログラムに共通です。 そこではメインスレッドがイベント発生を待ち、処理のために適した ワーカースレッドにイベントを渡します。 ひとたびイベントが渡されると、ボススレッドは次のイベントのために待機します。
ボススレッドは相対的に仕事量は少ないです。 タスクは他の方法を使ったものより必ずしも早く実行されるわけではないですが、 最もユーザーレスポンスタイムが良くなる傾向にあります。
仕事仲間モデルでは、データの様々な部分に対し本質的に同じ作業を行う いくつかのスレッドがつくられます。 これは、プロセッサの巨大な配列が多くのデータ片に対して全く同じことを行う 古典的な並列処理やベクトル処理とそっくりです。
プログラムを走らせているシステムが、異なるプロセスをまたいでマルチスレッドを 分配するような場合、このモデルは殊のほか便利です。 また、レイトレースやレンダリングエンジンといった、個々のスレッドが暫定的な 結果をユーザに対し視覚的にフィードバックするような場合にも便利でしょう。
パイプラインモデルはあるタスクを何段階の処理の連続へと分けます。 そして一つのステップの結果を次の処理を行うスレッドへと渡します。 それぞれのスレッドはデータの各部分に対し一つのことを行い、結果を次の スレッドへ渡します。
しばしば他の文脈でも同じぐらいの意味があるますが、二つ以上のスレッドが 並列に処理を行うようにあなたがマルチプロセッサを持っているならば、この モデルは最も意味があります。 それは、あるパイプラインの一部が進行中の間に、他のパイプラインの一部が (例えば I/O やシステムコールを)ブロックするのを 許可するのと同様、個々のタスクを小さく単純なものに留める傾向があります。 もし違うプロセッサ上で別々のパイプラインを走らせるなら、それぞれの プロセッサのキャッシュを利用するという利益を得ることができるでしょう。
このモデルはまた、自分自身を呼び出すサブルーチンを持つよりも、別の スレッドを生み出すような再起的プログラムの形態に利用しやすいです。 素数やフィボナッチ数列ジェネレーターは、どちらもこのパイプラインモデルの 形態にうまく位置付けられます(素数ジェネレーターの例は後で登場します)。
もしもあなたが他のスレッドの実装を経験したことがあるなら、事態は全く あなたの予想とは違うことがわかるでしょう。 Perl スレッドを扱う時には、あらゆる X に対して Perl スレッドは X スレッドではない ということを忘れてはなりません。 それらは POSIX スレッドではありません。 DecThread でもなければ Java のグリーンスレッドでないし、 Win32 スレッドでもありません。 類似点はあるし、広義の概念は同じです。 だが実装の詳細を調べだしたら、あなたは失望するか混乱するかの どちらかになるでしょう。 あるいはその両方かもしれません。
これは、これまで登場してきたあらゆるスレッドと Perl スレッドが完全に 異なるということを言っているのではありません。 Perl スレッドは他のモデル、特に POSIX スレッドに多くを負っています。 ですが、Perl が C ではないように、Perl スレッドは POSIX スレッドでは ありません。 だから、もしあなたがミューテックスやスレッドプライオリティを 期待しているならば、ちょっと立ち戻って、自分が何をしたいのか、 Perl はいかにしてそれが可能なのかを考える時です。
しかし、あなたのオペレーティングシステムのスレッドが許可しない限り、
Perl スレッドが魔法のように何かを行うことはできないことを覚えておきましょう。
だからもし、システムが sleep() でプロセスを丸ごとブロックするなら、通常
Perl も同様にそうするでしょう。
Perl スレッドは別ものです。
スレッドの追加は Perl の内部的な実態を変化させてしまいました。 これには XS モジュールや外部ライブラリーを書いている人々も含まれます。 しかしながら、デフォルトではスレッド間で Perl のデータは共有されません。 そのため Perl モジュールはスレッドセーフであるという機会に恵まれていますし、 あるいは容易にスレッドセーフにすることができます。 スレッドセーフの札がついていないモジュールは製品版の前にテストされるか コードレビューを受けるべきです。
あなたが使おうとしているモジュールの全てがスレッドセーフというわけでは ないですし、モジュールのドキュメントに安全であると書かれていないならば、 常に安全ではないものと仮定するべきです。 このことは、コアの一部として配布されているモジュールにもあてはまります。 スレッドは比較的新しい機構なので、標準モジュールの中にさえスレッドセーフで ないものがあります。
仮にあるモジュールがスレッドセーフであったとしても、そのモジュールが うまく働くように最適化されているということを意味するわけではありません。 できるだけスレッド環境でパフォーマンスが向上するように、スレッド化された Perl の新機構を利用するようモジュールを書き直したほうがよいです。
もしもなんらかの理由でスレッドセーフではないモジュールを使っているならば、 ただ一つのスレッドからそれを使うことによって防ぐことができます。 そのようなモジュールにアクセスするマルチスレッドが必要ならば、セマフォや アクセスを制御するためのプログラミング原則を用いることができます。 セマフォは ベーシックなセマフォ でカバーしています。
システムライブラリにおけるスレッドの安全性 も参照してください。
threads モジュールは、あなたがスレッドプログラムを書くのに必要と なる基本的な機能を提供します。 次からのセクションでは、スレッドプログラムを作るのに必要なことを示しながら 基礎的なところをカバーしていきましょう。 その後で、スレッドプログラミングを容易にしてくれる threads モジュールの 機能をみることにします。
スレッドのサポートは、あなたのプログラムがコンパイルされる時ではなく、 Perl のコンパイル時のオプションによります。 つまり、Perl をビルトするときに、サポートのオン・オフを行います。 スレッドがサポートされるように Perl がコンパイルされていないなら、スレッドを 使おうとしても失敗するでしょう。
スレッドが使用可能かどうかをチェックするために Config モジュールを 利用できます。 あなたのプログラムがスレッド無しには実行できないなら、次のように記述できます:
use Config;
$Config{useithreads} or die('Recompile Perl with threads to run this program.');
スレッドを利用するかもしれないモジュールを使うプログラムには、 次のようなコードをつけておくとよいでしょう:
use Config;
use MyMod;
BEGIN {
if ($Config{useithreads}) {
# We have threads
require MyMod_threaded;
import MyMod_threaded;
} else {
require MyMod_unthreaded;
import MyMod_unthreaded;
}
}
スレッドの有無に関わらず走るようなコードは通常、非常に繁雑なものになるので、
スレッド専用のコードはモジュールとして分離しておくのがベストです。
上の例では、MyMod_threaded がそれで、スレッド可能な Perl 上で走るときだけ
インポートされます。
実際の状況では、プログラムが終了する前に全てのスレッドが実行を終えることに 注意を払わなければなりません。 簡明さを重視しているのでここで取り上げる例においては、そのような注意を 払って いません。 これらの例を そのまま 実行すると、プログラムが終了する際にまだスレッドが 走っているという理由で常にエラーメッセージが出力されるでしょう。 この警告は気にしなくて良いです。
threads モジュールは新たなスレッドを生成するのに必要なツールを提供します。
他のモジュール同様、それを使いたいと Perl に伝える必要があります;
use threads; によって基本的なスレッドを生み出すのに必要な全ての部品が
インポートされます。
最も単純で直接的なスレッドの生成方法は create() によるものです:
use threads;
my $thr = threads->create(\&sub1);
sub sub1 {
print("In the thread\n");
}
create() メソッドはサブルーチンへのリファレンスを引数にとって新しい
スレッドを生成します。
このスレッドはリファレンスされたサブルーチンの実行を開始します。
このとき制御はサブルーチンと呼び出し側との両方に渡されます。
もし必要ならばスレッド開始時のサブルーチンにパラメータを渡せます。
以下のように、threads->create() の呼び出しにパラメータのリストを
含めます:
use threads;
my $Param3 = 'foo';
my $thr1 = threads->create(\&sub1, 'Param 1', 'Param 2', $Param3);
my @ParamList = (42, 'Hello', 3.14);
my $thr2 = threads->create(\&sub1, @ParamList);
my $thr3 = threads->create(\&sub1, qw(Param1 Param2 Param3));
sub sub1 {
my @InboundParameters = @_;
print("In the thread\n");
print('Got parameters >', join('<>', @InboundParameters), "<\n");
}
最後の例はスレッドのもう一つの特徴を示しています。 同じサブルーチンを利用するいくつものスレッドを生成することができます。 それぞれのスレッドは同一のサブルーチンを実行するが、それぞれのスレッドは それぞれ別々の環境と引数をとることができます。
new() は create() の言い換えです。
スレッドはサブルーチンでもあるので、値を返せます。
スレッドが終了して何らかの戻り値を得るのを待つために、join() を使えます:
use threads;
my ($thr) = threads->create(\&sub1);
my @ReturnData = $thr->join();
print('Thread returned ', join(', ', @ReturnData), "\n");
sub sub1 { return ('Fifty-six', 'foo', 2); }
上の例では、スレッドが終了するとすぐに join() メソッドが戻ります。
スレッドの終了と、返すべき値を収集するための待機に加えて、join() は
スレッドが必要とする OS レベルのクリーンナップを実行します。
このクリーンナップは重要です; 特に長時間にわたって実行されるプログラムが
大量のスレッドを生成する場合には。
もしも戻り値を必要とせず、スレッドの終了を待つ必要もなければ、かわりに
次に説明する detach() メソッドを呼び出すべきです。
注意: 上記の例では、スレッドはリストを返すので、スレッド作成呼び出しは
(my ($thr) のように)リストコンテキストで行われる必要があります。
スレッドのコンテキストと返り値に関する更なる詳細については
threads/"$thr-join()"> と threads/"THREAD CONTEXT" を参照してください。
join() は三つのことを行います。
スレッド終了の待機、その後のクリーンナップ、そしてスレッドが生み出したで
あろうデータを返すことです。
しかし、スレッドの返す値に関心がなく、いつスレッドが終了するのかを本当に
気にしない場合には?
必要なのは仕事がなされた後にスレッドがクリーンナップされることです。
このような場合、detach() メソッドを使います。
ひとたびスレッドが detach されると、スレッドは終了するまで実行し続け、
そのあと Perl が自動的にクリーンナップを行います。
use threads;
my $thr = threads->create(\&sub1); # Spawn the thread
$thr->detach(); # Now we officially don't care any more
sleep(15); # Let thread run for awhile
sub sub1 {
$a = 0;
while (1) {
$a++;
print("\$a is $a\n");
sleep(1);
}
}
一度あるスレッドが detach されたら、そのスレッドは join されないでしょう。 (join のために待機しても)スレッドが生成したであろうデータは失われます。
detach() はスレッドが自分自身を detach するためにクラスメソッドとしても
呼び出されます:
use threads;
my $thr = threads->create(\&sub1);
sub sub1 {
threads->detach();
# Do more work
}
スレッドを使う場合は、全てのスレッドが確実に完全に実行される(それが あなたの望むもののはずです)ように注意しなければなりません。
プロセスを終了させる行動は実行中の 全ての スレッドを終了させます。
die() と exit() はこの性質を持ち、(あなたが望んでいないとしても)
おそらくは暗黙のうちにコードの最後に到達することによってメインスレッドが
終了すると、perl は終了します。
この場合の例として、このコードは "Perl exited with active threads: 2 running and unjoined" というメッセージを 表示します:
use threads;
my $thr1 = threads->new(\&thrsub, "test1");
my $thr2 = threads->new(\&thrsub, "test2");
sub thrsub {
my ($message) = @_;
sleep 1;
print "thread $message\n";
}
しかし以下の行が最後に追加されると:
$thr1->join();
$thr2->join();
2 行の出力があり、おそらくより有用な成果となります。
これでスレッドの基本部分については見終わりました。 次の話題はデータです。 スレッドを扱うと、非スレッドプログラムが決して心配することのなかった データアクセスに対する二つの複雑さを導入することになります。
iスレッド と古い 5.005 型スレッドの間の(もっといえば、そこから外れる 多くのスレッドシステムにとっての)最大の違いは、デフォルトではデータが 共有されないという点です。 新しい Perl スレッドが生成されるとき、現在のスレッドに関連する全てのデータは 新しいスレッドにコピーされます。 続いてそのデータは新しいスレッド内でプライベートなものとなります! これは UNIX のプロセスが fork するときに起きることと似ています。 ただしこの場合、実際の fork ではメモリ上での置き換えが起こるのに対して、この データは同一プロセッサ内の違うメモリ部分にコピーされるだけであるという点が 除かれます。
しかしスレッド機能を利用するならば、通常はスレッド間で少なくともいくつかの
データを共有したいものです。
これは threads::shared モジュールと :shared 属性によって行われます:
use threads;
use threads::shared;
my $foo :shared = 1;
my $bar = 1;
threads->create(sub { $foo++; $bar++; })->join();
print("$foo\n"); # Prints 2 since $foo is shared
print("$bar\n"); # Prints 1 since $bar is not shared
共有化された配列の場合は、配列の要素全てが共有化されます。 共有化されたハッシュの場合、全てのキーと値が共有されます。 共有化された配列やハッシュの要素に代入するものに対しては制限があります: 単純な値や共有化された変数へのリファレンスは可能です。 これは、プライベート変数が図らずも共有化されることがないからです。 不正な代入はスレッドを殺してしまうでしょう。 例えば:
use threads;
use threads::shared;
my $var = 1;
my $svar :shared = 2;
my %hash :shared;
... create some threads ...
$hash{a} = 1; # どのスレッドからも exists($hash{a}) and $hash{a} == 1
$hash{a} = $var; # OK、値のコピー。効果は上に同じ。
$hash{a} = $svar; # OK、値のコピー。効果は上に同じ。
$hash{a} = \$svar; # OK、共有変数へのリファレンス。
$hash{a} = \$var; # これは die する
delete($hash{a}); # OK、どのスレッドからも !exists($hash{a})
共有変数が、複数のスレッドが同時にその変数に変更を加えようとしても、 変数の内部状態は破壊されないことを保証していることに注意してください。 しかし次のセクションで説明するように、ここを超えてしまうと保証は なくなってしまいます。
スレッドは新しい便利なツールを一揃いもたらしてくれる一方で、たくさんの 落とし穴ももたらします。 その一つは競合条件です:
use threads;
use threads::shared;
my $a :shared = 1;
my $thr1 = threads->create(\&sub1);
my $thr2 = threads->create(\&sub2);
$thr1->join();
$thr2->join();
print("$a\n");
sub sub1 { my $foo = $a; $a = $foo + 1; }
sub sub2 { my $bar = $a; $a = $bar + 1; }
$a はどうなるでしょうか?
残念ながら、その答えは 場合によりけり です。
sub1() と sub2() はどちらも一度だけ読み込み、一度だけ書き込むために
グローバル変数 $a にアクセスします。
あなたの使っているスレッド実装のスケジューリングアルゴリズムから月の
満ち欠けまでの種々の要因によって、$a は 2 にも 3 にもなりえます。
競合条件は共有データに対して非同期なアクセスを行うことによって生じます。 明示的に同期をとらない限り、アクセスして更新するまでの間に 共有データに何も起こらないことを確実にする方法はありません。 こんな単純なコードでさえ、エラーの可能性があります:
use threads;
my $a :shared = 2;
my $b :shared;
my $c :shared;
my $thr1 = threads->create(sub { $b = $a; $a = $b + 1; });
my $thr2 = threads->create(sub { $c = $a; $a = $c + 1; });
$thr1->join();
$thr2->join();
二つのスレッドが $a にアクセスします。
それぞれのスレッドはいずれかの時点で割り込まれたり、いずれかの順番で
実行される可能性があります。
結局、$a は 3 か 4 に、$b と $c はともに 2 か 3 になるでしょう。
$a += 5 や $a++ でさえ、アトミックな演算であることを保証されません。
他のスレッドによってアクセスされる可能性のあるデータやリソースにあなたの プログラムがアクセスするときはいつでも、整合的なアクセスのための手順を 踏まなければなりません。 さもなければデータの一貫性が崩れたり、競合条件に陥るリスクを 負うことになります。
競合条件やそれに似た状態を回避するために、スレッドとデータとの間の相互作用を
調整する多くのメカニズムを Perl は提供します。
それらのうちのあるものは、pthreads のようなスレッドライブラリにおいて
使われる共通のテクニックに似た設計がなされています。
またあるものは Perl に特化しています。
しばしば標準的なテクニックというものはぎこちないもので、正しく扱うには
難しいです。
可能なところでは通常、キューのような Perl 的テクニックはより簡単で、難しい
仕事のうちのあるものを取り除いてくれます。
lock() 関数は共有変数を引数にとり、それにロックをかけます。
ロックを保持するスレッドによって変数のロックが解除されるまで、他のスレッドは
ロックをかけることができません。
ロックしているスレッドが lock() 関数の呼び出しを含むブロックの外に出ると
ロックは自動的に解除されます。
lock() の利用は率直なやり方です。
この例は、ある計算を並列的に処理し、時折その総計値を更新するいくつかの
スレッドを伴っています:
use threads;
use threads::shared;
my $total :shared = 0;
sub calc {
while (1) {
my $result;
# (... do some calculations and set $result ...)
{
lock($total); # Block until we obtain the lock
$total += $result;
} # Lock implicitly released at end of scope
last if $result == 0;
}
}
my $thr1 = threads->create(\&calc);
my $thr2 = threads->create(\&calc);
my $thr3 = threads->create(\&calc);
$thr1->join();
$thr2->join();
$thr3->join();
print("total=$total\n");
ロックされている変数が利用可能になるまで、lock() はそのスレッドを
ブロックします。
lock() が戻ってくると、そのロックが存在しているブロックの外に出ない限り、
他のスレッドがその変数をロックできないことが確実になります。
ロックは問題の変数にアクセスするのを阻止するのではなくて、ロックの試みを 阻止するということに注意することが重要です。 これは Perl の長年にわたる作法どおりのプログラミングの伝統と、flock() が 提供する勧告ロックとに調和するものです。
スカラ変数同様、配列やハッシュにもロックをかけるかもしれません。 しかし、配列へのロックは、配列の要素に対する二次的なロックを ブロックするのではなく、配列そのものへのロックの試みをブロックします。
ロックは再帰的、つまりスレッドはある変数に対し何度もロックをかけて大丈夫です。
一番外側の lock() がスコープを抜けるまでロックは続きます。
例えば:
my $x :shared;
doit();
sub doit {
{
{
lock($x); # Wait for lock
lock($x); # NOOP - we already have the lock
{
lock($x); # NOOP
{
lock($x); # NOOP
lockit_some_more();
}
}
} # *** Implicit unlock here ***
}
}
sub lockit_some_more {
lock($x); # NOOP
} # Nothing happens here
unlock() 関数は無いことに注意してください。
変数のロックを解除する方法はスコープを抜けさせることだけです。
ロックされている変数内に保持されているデータをガードするか、あるいは コードのセクションのようなものを守るために、ロックは用いられます。 後者の場合、問題の変数は役に立つデータを持たず、ロックの目的のためにだけ 存在します。 この点からすると、その変数は伝統的なスレッドライブラリにおける ミューテックスや基本的なセマフォのような振る舞いをするといえます。
ロックはデータに同期アクセスするための便利なツールです。 適切に使えば安全な共有データへの鍵となります。 残念なことに、ロックには危険が伴います。 特に複数のロックが関わるとそうなります。 次のコードを考えてみましょう:
use threads;
my $a :shared = 4;
my $b :shared = 'foo';
my $thr1 = threads->create(sub {
lock($a);
sleep(20);
lock($b);
});
my $thr2 = threads->create(sub {
lock($b);
sleep(20);
lock($a);
});
このプログラムは恐らくあなたが kill するまで固まってしまうでしょう。 ハングさせないための唯一の方法は、どちらかのスレッドが先に両方のロックを 獲得することです。 ハングを保証する方法はもっと複雑ですが、原理はこれと同じです。
最初のスレッドが $a のロックを手にします。
それから二つ目のスレッドが何かやっている間に一時停止した後、$b への
ロックを手に入れようと試みます。
ところが、その二つ目のスレッドは $b へのロックを手にします。
そしてその後 $a のロックを手に入れようとします。
それぞれのスレッドが、他方のスレッドのロックが開放されるの待つため、
二番目のロックへの試みはブロックしてしまいます。
この状態をデッドロックと言います。 二つ以上のスレッドが他スレッドの所有するリソースをロックしようと 試みるときにはいつでも生じます。 他のスレッドがリソースへのロックを開放するのを待って、互いにスレッドが ブロックします。 しかし、リソースを持っているスレッドが自分自身のロックの開放を待つ場合は 生じません。
この種の問題を扱う方法はたくさんあります。
最もよい方法は、常に全てのスレッドが正確に同じ順番でロックを獲得するように
することです。
例えば、$a、$b、$cをロックするなら、いつでも $b の前に $a を、
そして $c の前に $b をロックするようにします。
デッドロックの危険を最小にするために、短い時間だけロックを保持するのも良い手です。
下記で説明するような他のプリミティブな同期も同様な問題を抱える可能性があります。
キューとは、一方の端にデータを入れ、他方から取り出すことによって、 同期の問題を心配しなくてすむ、特別なスレッドセーフオブジェクトです。 これらは非常に素朴で、以下のようなものです:
use threads;
use Thread::Queue;
my $DataQueue = Thread::Queue->new();
my $thr = threads->create(sub {
while (my $DataElement = $DataQueue->dequeue()) {
print("Popped $DataElement off the queue\n");
}
});
$DataQueue->enqueue(12);
$DataQueue->enqueue("A", "B", "C");
sleep(10);
$DataQueue->enqueue(undef);
$thr->join();
Thread::Queue->new() でキューを生成します。
それから enqueue() を使ってキューの
最後にスカラのリストを追加します。
そして dequeue() でキューの前方からスカラを取り出します。
キューのサイズは固定していません。
キューの中に押し込められたものを保持する必要に応じてサイズは成長します。
もしキューが空っぽの場合、他のスレッドが何かをキューの中に入れるまで、
dequeue() はブロックします。
そのため、イベントループやスレッド間でのコミュニケーションにとって、
キューは理想的です。
セマフォは包括的なロックメカニズムの一種です。 最も基本となる形態では、 セマフォはデータを持つことはできないし、明示的にロック解除されなければ ならないことを除くと、ロック可能なスカラそっくりに振る舞います。 発展的な形態においては、一種のカウンターのように動作し、いつでも複数の スレッドが ロック を持つことを可能にします。
セマフォは二つのメソッド、down() と up() を持ちます。
down() はリソースのカウントを減少させ、up() の方は増加させます。
セマフォの現在のカウントが 0 を下回るようなら down() の呼び出しは
ブロックします。
このプログラムは短い例です:
use threads;
use Thread::Semaphore;
my $semaphore = Thread::Semaphore->new();
my $GlobalVariable :shared = 0;
$thr1 = threads->create(\&sample_sub, 1);
$thr2 = threads->create(\&sample_sub, 2);
$thr3 = threads->create(\&sample_sub, 3);
sub sample_sub {
my $SubNumber = shift(@_);
my $TryCount = 10;
my $LocalCopy;
sleep(1);
while ($TryCount--) {
$semaphore->down();
$LocalCopy = $GlobalVariable;
print("$TryCount tries left for sub $SubNumber (\$GlobalVariable is $GlobalVariable)\n");
sleep(2);
$LocalCopy++;
$GlobalVariable = $LocalCopy;
$semaphore->up();
}
}
$thr1->join();
$thr2->join();
$thr3->join();
このサブルーチンに対する三つの呼び出しは同時に作用します。 しかし一度に一つのスレッドだけが、グローバル変数にアクセスすることを セマフォが保証します。
デフォルトでは、セマフォはロックのように振舞います。
一度にただ一つのスレッドだけが down() できます。
しかし、セマフォには別の使い方があります。
それぞれのセマフォは、関連付けられたカウンタを持ちます。
デフォルトでセマフォは生成時、カウンタに 1 がセットされます。
down() はカウンタから 1 を引き、up() は 1 を足します。
しかしこの規定値の一部ないしは全部を別の値でもって上書きできます:
use threads;
use Thread::Semaphore;
my $semaphore = Thread::Semaphore->new(5);
# Creates a semaphore with the counter set to five
my $thr1 = threads->create(\&sub1);
my $thr2 = threads->create(\&sub1);
sub sub1 {
$semaphore->down(5); # Decrements the counter by five
# Do stuff here
$semaphore->up(5); # Increment the counter by five
}
$thr1->detach();
$thr2->detach();
もしも down() がカウンタを 0 より小さい値に下げようとするなら、
カウンタが十分な大きさになるまでブロックします。
セマフォはカウンタの値を 0 にして生成することができる一方、up() や
down() は常に、少なくとも 1 の変化をカウンタに対して行うことに
注意してください。
だから、$semaphore->down(0) は $semaphore->down(1) と同じです。
もちろん、問題はどうしてこんなことをするのかということです。 なぜセマフォを 1 ではなくて、0 から始めるように生成するのでしょうか? あるいは、なぜ 1 より大きい値で増減を行うのでしょうか？ その答えはリソースの利用可能性です。 あなたがアクセス管理をしたいリソースの多くは、同時に一つを超える数の スレッドによって安全に利用されます。
例として GUI 駆動型のプログラムを取り上げてみましょう。 プログラムは、ディスプレイに同期アクセスするためにセマフォを持っています。 そうして一度にただ一つのスレッドだけが描画を行っています。 簡単な話ですが、もちろん、ちゃんと準備ができるまでどのスレッドにも描画を 始めてもらいたくはありません。 こんな場合に、カウンタを 0 にしてセマフォを生成するのです。 そして描画の準備ができたら、カウンタを増加させます。
1 より大きいカウンタを持つセマフォはクォータの確立にも役立ちます。 例えば、同時に I/O を使うスレッドがいくつもあるとします。 だが、全てのスレッドが同時に読み書きをするのは望みません。 そんなことをしたら I/O チャンネルを圧迫するかもしれないし、プロセスに 割り当てられたファイルハンドルを枯渇させてしまうかもしれないからです。 あなたがいつでも必要とし、スレッドに暗黙にブロック・アンブロックを させたいだけの同時 I/O リクエスト数(あるいはオープンファイル数)で 初期設定されたセマフォを利用すればよいです。
あるスレッドが一度にたくさんのリソースを借りたり戻したりするような こういうケースでは、大きな数で増減を行うのが便利です。
関数 cond_wait() と cond_signal() は、ロックが同時発生する時に、
リソースが利用可能になった協調型スレッドに通知を行うために用います。
これらは、pthreads にある関数とよく似ています。
しかしほとんどの目的において、キューの方がより単純で直感的です。
更なる詳細は threads::shared を参照してください。
あるスレッドが明示的に他のスレッドへと CPU を譲り渡せられたら便利だと 思うことがあるでしょう。 あなたはプロセッサ集約的なことをしようとしているかもしれませんし、 ユーザーインターフェース担当のスレッドが呼び出されることを確認したいと 思うかもしれません。 とにかく、スレッドがプロセッサを明け渡せたら、ということがよくあります。
Perl のスレッドパッケージはこれを実現する yield() 関数を提供しています。
yield() はとても素朴で、このように動作します:
use threads;
sub loop {
my $thread = shift;
my $foo = 50;
while($foo--) { print("In thread $thread\n"); }
threads->yield();
$foo = 50;
while($foo--) { print("In thread $thread\n"); }
}
my $thr1 = threads->create(\&loop, 'first');
my $thr2 = threads->create(\&loop, 'second');
my $thr3 = threads->create(\&loop, 'third');
yield() は CPU を明け渡すためのヒントでしかありません。
実際に何が起こるのかは、ハードウェアや OS、そしてスレッドライブラリに
依存しています。
多くのオペレーティングシステムにおいて、yield() は何も機能しません。
それゆえ、yield() を呼んでスレッドのスケジューリングをたてるべきでは
ないことに注意することが重要です。
あなたのプラットフォームでは動作したとしても、別のプラットフォームでは
動かないかもしれません。
Perlのスレッドパッケージの働き部分をみてきました。 これらの道具を使い、あなたのやり方でスレッドコードとパッケージを 書いていくことができるはずです。 他の場所では実際にはフィットしないけれども、便利な小物も少しはあります。
threads->self() クラスメソッドを使うと、現在のスレッドを表す
オブジェクトを得ることができます。
スレッドを生成するときに返ってくるオブジェクトと同じように、この
オブジェクトを使うことができます。
tid() はオブジェクトが表すスレッドの ID を返すメソッドです。
スレッド ID は整数で、プログラム中のメインスレッドは 0 です。
現在の Perl は、プログラム中で生成された全てのスレッドに一意な ID を
つけます。
最初に生成されたスレッドには 1 があてられ、新しいスレッドが作られる度に
ID は 1 ずつ増えていきます。
クラスメソッドとして使われると、threads->tid() はスレッドが自身の
TID を得るために使われます。
equal() メソッドは二つのスレッドオブジェクトを引数にとり、オブジェクトが
同じスレッドを示していれば真を、そうでなければ偽を返します。
スレッドオブジェクトは比較演算子 == をオーバーロードするので、普通の
オブジェクトのようにそれらを比較することもできます。
threads->list() はスレッドオブジェクトのリストを返します。
それぞれは現在実行中で detach されていないスレッドです。
プログラムの終わりに(もちろん Perl のメインスレッドから)
クリーンナップするのも含めていろいろな点で便利です:
# Loop through all the threads
foreach my $thr (threads->list()) {
$thr->join();
}
もしメインスレッドが終了する時に、あるスレッドが実行を終了していなかったら、 Perl は警告を発し、die します。 これは、他のスレッドが実行中の間は Perl が自分自身をクリーンナップ できないためです。
注意: Perl のメインスレッド (スレッド 0) は detach された 状態にあるので、
threads->list() で返されるリストには現れません。
まだ混乱していますか? では、サンプルプログラムを使ってこれまで見てきたことのいくつかを示す時です。 このプログラムはスレッドを使って素数を見つけだします。
1 #!/usr/bin/perl
2 # prime-pthread, courtesy of Tom Christiansen
3
4 use strict;
5 use warnings;
6
7 use threads;
8 use Thread::Queue;
9
10 sub check_num {
11 my ($upstream, $cur_prime) = @_;
12 my $kid;
13 my $downstream = Thread::Queue->new();
14 while (my $num = $upstream->dequeue()) {
15 next unless ($num % $cur_prime);
16 if ($kid) {
17 $downstream->enqueue($num);
18 } else {
19 print("Found prime: $num\n");
20 $kid = threads->create(\&check_num, $downstream, $num);
21 if (! $kid) {
22 warn("Sorry. Ran out of threads.\n");
23 last;
24 }
25 }
26 }
27 if ($kid) {
28 $downstream->enqueue(undef);
29 $kid->join();
30 }
31 }
32
33 my $stream = Thread::Queue->new(3..1000, undef);
34 check_num($stream, 2);
このプログラムは素数を発生させるためにパイプラインモデルを利用しています。 パイプラインにおけるそれぞれのスレッドは、素数を見つけるために チェックされる数を渡す入力キューと、チェックに失敗した数をかき集めておく 出力キューとを持ちます。 チェックに失敗した数がスレッドにあり、かつ、子スレッドがない場合、その スレッドは新しい素数を見つけたことになります。 この場合、新しい子スレッドはその素数のために生成され、パイプラインの後ろに くっつけられます。
これは実際よりもわかりにくいかもしれません。 だからこのプログラムを部分部分に分けて、なにをしているのかを見てみましょう。 (素数とは正確には何だったかということを思い出そうされている方のためにいうと、 自分自身と 1 でのみ割り切れる数のことです。)
作業の大半は check_num() ルーチンによってなされます。
このルーチンは入力キューへのリファレンスとスレッドが受け持つ素数を
引数にとります。
[引数を]入力キューとサブルーチンがチェックする素数[のローカル変数]に
入れた後(11 行目)、新しいキューを生成します(13 行目)。
そして、後で生成するかもしれないスレッドを入れるスカラ変数を
用意します(12 行目)。
14 行目から 26 行目までの while ループで入力キューからスカラ値を 取り出し、このスレッドが受け持つ素数でチェックします。 15 行目では、チェックされる数に対する除算を行い、余りがあるかどうかを 調べます。 もしあれば、その数は素数では割れないということなので、 その数を、すでに生成してあるのであれば (17 行目) 次のスレッドに渡しますし、 そうでなければ新しいスレッドを作ります。
20 行目で新しいスレッドの生成を行っています。 そのスレッドに、先に作ったキューへのリファレンスと発見された素数を渡します。 21 行目から 24 行目で、新しいスレッドが作成されたことを確認して、 もし作成されていないなら、キューの残りの番号に関するチェックを 中止します。
最後に、(キューの中に 0 か undef があるかして)ループが終了すると、
子スレッドを作っていた場合には子スレッドに注意を促し[(undef を送る)]、
実行が終了するのを待ちます(27, 30 行目)。
一方、メインスレッドに戻ってみると、まずキューを生成し(33 行目)、
チェックするための 3 から 1000 までの全ての数と終端マークを
キューに入れます。
それからボールを転がすために必要なことは、キューと最初の素数を
check_num() サブルーチンに渡すことです (line 34)。
以上が仕組みです。 とても単純です; 多くのPerlプログラムにとってそうであるように、 説明の方が当のプログラム以上にとても長くなります。
オペレーティングシステムの観点からみた、スレッド実装についての背景です。 スレッドには三つの基本的なカテゴリーがあります: ユーザーモードスレッド、 カーネルスレッド、マルチプロセッサカーネルスレッドです。
ユーザーモードスレッドとは、完全にプログラムとライブラリの中に存在する スレッドです。 このモデルにおいては、OS はスレッドについて何も関知しません。 OS からしてみる限り、あなたのプロセスはただのひとつのプロセスです。
これは最も簡単なスレッドの実装であり、ほとんどの OS が最初にとった方法です。
この方法の大きな欠点は、OS がスレッドに関知していないために、
もしも一つのスレッドがブロックをしたら、全てのスレッドがブロックしてしまう
ということです。
典型的なブロック行為には、ほとんどのシステムコール、ほとんどの
I/O、そして sleep() のようなものが含まれます。
カーネルスレッドは進化の第二段階です。 OS はカーネルスレッドについて知っていて、その許可を出します。 カーネルスレッドとユーザーモードスレッドの主要な違いは、 ブロッキングについてです。 カーネルスレッドでは、一つのスレッドをブロックした事で他のスレッドまで ブロックすることはありません。 これはユーザーモードスレッドにおいては成り立ちません。 ユーザーモードでは、カーネルがブロックするのはプロセスレベルであって、 スレッドレベルではないからです。
これは大きな前進であり、非スレッドプログラムに対し、スレッドプログラムが 大きなパフォーマンスの向上を得ることを可能にしています。 例えば、I/O の実行をブロックするスレッドは、他のことを行うスレッドを ブロックしないでしょう。 しかし、システムがいくつ CPU を備えているかに関係なく、それぞれのプロセスは いまだに一度に一つのスレッドしか走らせません。
カーネルのスレッド制御がいつでも割り込めるので、あなたがプログラム中に
つくった暗黙のロックの前提が白日の下にさらけ出してしまうでしょう。
例えば、$a = $a + 2のような単純なものでも、$a が他のスレッドから
見えるならば、右辺の値を取り出す時間と新しい値を格納する時間の間に、他の
スレッドが $a を変えてしまって、あなたの予期しない振る舞いをする
可能性があります。
マルチプロセッサカーネルスレッドは、スレッドのサポートにおける最終段階です。 一台のマシンが複数の CPU を持っているマルチプロセッサカーネルスレッドでは、 OS は別々の CPU 上で同時に一つ以上のスレッドを走らせるようにスケジュール 管理をします。
一つ以上のスレッドが同時に実行するので、これによりスレッドプログラムは 飛躍的なパフォーマンスの向上を得ることができます。 しかし、引き換えに、基本的なカーネルスレッドでは現れなかったであろう イライラするような同期性の問題が一気に姿を現します。
スレッドを備える OS の違いというレベルに加えて、それぞれの OS は(そして それぞれのスレッド実装は)それぞれの方法でもって CPU サイクルをスレッドに 割り当てます。
次の二つのうちの一つが起こる場合、協調的マルチタスクシステムは実行中の スレッドに制御を明け渡させます。 あるスレッドがyield関数を呼び出すと、制御を明け渡します。 また、スレッドがI/Oの実行などのブロックを引き起こすような何かを行う場合も、 制御を明け渡します。 協調的マルチタスクシステムの実装においては、そのように選択するならば、 一つのスレッドが他の全てのスレッドの CPU 時間を食い尽くすことができます。
プリエンティブなマルチタスクシステムは、次にどのスレッドを実行するか 決めながら、一定の間隔でスレッドに割り込みを入れます。 プリエンティブなマルチタスクシステムにおいて、通常一つのスレッドが CPU を 独占することはありません。
いくつかのシステムでは、協調的スレッドとプリエンティブなスレッドを同時に 実行することができます(例えば、通常のプライオリティを持ったスレッドが プリエンディブに振舞うのに対して、リアルタイムのプライオリティを持った スレッドはしばしば協調的に振舞います)。
今では、ほとんどの近代的なOSでプリエンティブなマルチタスクを サポートしています。
Perl の iスレッド と他のスレッドモデルを比較する際に忘れてならないのが、 新しいスレッドはみな、親スレッドの変数とデータを全て完全にコピーして 引き渡されるという事実です。 そのため、メモリ使用量と実行時間の両方の点で、スレッドの生成は非常に 高くつきます。 このコストを減らす理想的な方法は、長生きなスレッドを比較的少なめに 持つことです。 このスレッドは全て、ベースとなるスレッドが非常に多くのデータを蓄積する前に、 適切に早い段階で生成されます。 もちろん、これはいつも可能というわけではないでしょうから、妥協も必要です。 しかし、スレッドが生成された後は、そのパフォーマンスと追加のメモリ使用量は、 普通のコードのそれとほとんど違いはありません。
また、現在の実装下では、共有変数は通常の変数に比べて少し余計にメモリを 使用し、スピードも少し遅いことにも注意してください。
スレッドそれ自身は別々に実行され、Perl のデータは明示的に共有化しない限りは スレッド内でプライベートなものです; その一方、スレッドは全てのスレッドに影響を与えながら、プロセススコープの 状態に影響を与えてしまうことに注意してください。
この最も一般的な例は chdir() を使ったときに現在作業中のディレクトリが
変更されてしまうことです。
一つのスレッドが chdir() を呼ぶと、全てのスレッドの作業ディレクトリが
変更されます。
さらに劇的なプロセススコープの変更例は chroot() です。
全部のスレッドのルートディレクトリが変更されます。
スレッドはそれを元に戻すことはできません(chdir() の場合は可能です)。
さらなるプロセススコープ変化の例は、umask() および uid や gid の変更です。
fork() とスレッドを混在させたらどうなるかって?
そんな気分が失せるまで、横になって休んでいてください。
fork() の動作はプラットフォームによって異なることに注意してください。
例えば、UNIX システムには現状の全てのスレッドを子プロセスに
コピーするものもありますが、fork() を呼び出したスレッドのみを
コピーするものもあります。
あなたは警告されました!
同じように、シグナルとスレッドを混ぜるのもするべきではありあません。 実装はプラットフォーム依存だし、POSIX のセマンティクスでさえ、あなたの 期待通りにはならないかもしれません (そして Perl はフルセットの POSIX API を提供することさえできません)。 例えば、マルチスレッド Perl アプリケーションに送られたシグナルが、 特定のスレッドによって受信されることを保証する方法はありません。 (しかし、最近追加された機能はスレッド間でシグナルを送る能力を提供します。 更なる詳細については threads/"THREAD SIGNALLING を参照してください。)
様々なライブラリの関数呼び出しがスレッドにとって安全かどうかということは、
Perlのコントロールの埒外です。
しばしばスレッドセーフではないものに
よって問題の生じる呼び出しには以下のようなものです:
localtime(), gmtime(),
(getgrent(), gethostent(), getnetent() などのような)ユーザー、
グループ、ネットワークの情報を取り出す関数、readdir(),
rand(), srand() -- 一般的に言って、グローバルな外部状況に依存する
呼び出しが含まれます。
Perl がコンパイルされたシステムが、そういった呼び出しのスレッドセーフな バージョンを持っているなら、そちらが使われます。 それを超えると、Perl は呼び出しがスレッドセーフかどうかのなすがままに なります。 C ライブラリのドキュメントをよく吟味してください。
いくつかのプラットフォームでは、結果バッファが小さすぎる場合に
スレッドセーフなライブラリのインターフェースが失敗を起こすかもしれません
(例えば、ユーザーグループのデータベースがかなり大きく、リエントラントな
インターフェースがこれらのデータベースの完全なスナップショットを
もたらさなければならないような場合)。
Perl は小さなバッファでスタートします。
しかし結果が適合するまで結果バッファの確保を再試行し、大きくしようとします。
この無制限な成長がセキュリティやメモリ消費の理由から好ましくないもので
あるなら、PERL_REENTRANT_MAXSIZE であなたの許す最大バイト数を定義して
Perl を再コンパイルできます。
完全なスレッドのチュートリアルをつくると一冊の本になってしまいます。 しかしこの導入でカバーしてきたことを使って、あなたなりの方法で スレッド Perl のエキスパートになっていってください。
Annotated POD for threads: http://annocpan.org/
Lastest version of threads on CPAN: http://search.cpan.org/search
Annotated POD for threads::shared: http://annocpan.org/
Lastest version of threads::shared on CPAN: http://search.cpan.org/search
Perl threads mailing list: http://lists.cpan.org/showlist.cgi
Jurgen Christoffel の提供による簡潔な参考文献集：
Birrell, Andrew D. An Introduction to Programming with Threads. Digital Equipment Corporation, 1989, DEC-SRC Research Report #35 online as http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-035.html (highly recommended)
Robbins, Kay. A., and Steven Robbins. Practical Unix Programming: A Guide to Concurrency, Communication, and Multithreading. Prentice-Hall, 1996.
Lewis, Bill, and Daniel J. Berg. Multithreaded Programming with Pthreads. Prentice Hall, 1997, ISBN 0-13-443698-9 (a well-written introduction to threads).
Nelson, Greg (editor). Systems Programming with Modula-3. Prentice Hall, 1991, ISBN 0-13-590464-1.
Nichols, Bradford, Dick Buttlar, and Jacqueline Proulx Farrell. Pthreads Programming. O'Reilly & Associates, 1996, ISBN 156592-115-1 (covers POSIX threads).
Boykin, Joseph, David Kirschen, Alan Langerman, and Susan LoVerso. Programming under Mach. Addison-Wesley, 1994, ISBN 0-201-52739-1.
Tanenbaum, Andrew S. Distributed Operating Systems. Prentice Hall, 1995, ISBN 0-13-219908-4 (great textbook).
Silberschatz, Abraham, and Peter B. Galvin. Operating System Concepts, 4th ed. Addison-Wesley, 1995, ISBN 0-201-59292-4
Arnold, Ken and James Gosling. The Java Programming Language, 2nd ed. Addison-Wesley, 1998, ISBN 0-201-31006-6.
comp.programming.threads FAQ, http://www.serpentine.com/~bos/threads-faq/
Le Sergent, T. and B. Berthomieu. "Incremental MultiThreaded Garbage Collection on Virtually Shared Memory Architectures" in Memory Management: Proc. of the International Workshop IWMM 92, St. Malo, France, September 1992, Yves Bekkers and Jacques Cohen, eds. Springer, 1992, ISBN 3540-55940-X (real-life thread applications).
Artur Bergman, "Where Wizards Fear To Tread", June 11, 2002, http://www.perl.com/pub/a/2002/06/11/threads.html
Thanks (in no particular order) to Chaim Frenkel, Steve Fink, Gurusamy Sarathy, Ilya Zakharevich, Benjamin Sugars, Jurgen Christoffel, Joshua Pritikin, and Alan Burlison, for their help in reality-checking and polishing this article. Big thanks to Tom Christiansen for his rewrite of the prime number generator.
Dan Sugalski <dan@sidhe.org
新しいスレッドモデル・モジュールに対応するように Arthur Bergman によって 若干の修正がなされました。
Perl コードのスレッドセーフティについてより簡明になるよう
Jorg Walter <jwalt@cpan.org
Elizabeth Mattijsen <liz@dijkmat.nl
The original version of this article originally appeared in The Perl Journal #10, and is copyright 1998 The Perl Journal. It appears courtesy of Jon Orwant and The Perl Journal. This document may be distributed under the same terms as Perl itself.