perlthrtut - Perl におけるスレッドのチュートリアル This tutorial describes the use of Perl interpreter threads (sometimes referred to as ithreads) that was first introduced in Perl 5.6.0. In this model, each thread runs in its own Perl interpreter, and any data sharing between threads must be explicit. The user-level interface for ithreads uses the threads class. このチュートリアルは、Perl 5.6.0 において導入された新しい Perl インタプリタ スレッド(iスレッド(ithreads)と呼ばれる)の特徴を説明するものです。 このモデルにおいては、それぞれのスレッドはそれ自身の Perl インタプリタで 実行され、スレッド間で共有するデータも明示的でなければなりません。 ithreads のユーザーレベルインターフェースは threads クラスを使います。 NOTE: There was another older Perl threading flavor called the 5.005 model that used the Threads class. This old model was known to have problems, is deprecated, and was removed for release 5.10. You are strongly encouraged to migrate any existing 5.005 threads code to the new model as soon as possible. 注意: Perl のバージョン 5.005 には、5.005 モデルと呼ばれる Threads クラスを使う別の古いスレッド機能がありました。 この古いモデルは問題があることが知られていて、非推奨で、バージョン5.10 で 削除されました。 できるだけ速やかに既存の5.005スレッドを新しいものに移行することが 強く勧められます。 You can see which (or neither) threading flavour you have by running perl -V and looking at the Platform section. If you have useithreads=define you have ithreads, if you have use5005threads=define you have 5.005 threads. If you have neither, you don't have any thread support built in. If you have both, you are in trouble. perl -V で Platform セクションを見れば、どちらのスレッド機能があるのか (あるいは無いのか)を知ることができます。 もし useithreads=define となって いればiスレッドをサポートしているし、use5005threads=define とあれば 5.005 スレッドです。 両方とも出ない場合、あなたの Perl はスレッドをサポートしていません。 両方ある場合は問題があります。 The threads and threads::shared modules are included in the core Perl distribution. Additionally, they are maintained as a separate modules on CPAN, so you can check there for any updates. threads と threads::shared のモジュールはコア Perl 配布に 含まれています。 さらに、CPAN では別個のモジュールとして保守されているので、更新については CPAN をチェックできます。 (ところでスレッドって何?) A thread is a flow of control through a program with a single execution point. スレッドとはプログラム内を通じて一つの実行点を持った制御のフローです。 Sounds an awful lot like a process, doesn't it? Well, it should. Threads are one of the pieces of a process. Every process has at least one thread and, up until now, every process running Perl had only one thread. With 5.8, though, you can create extra threads. We're going to show you how, when, and why. こういうと非常に多くの点でプロセスに似ているように聞こえるでしょう。 確かにその通りで、スレッドはひとつのプロセスにおける細かい部分の一つです。 全てのプロセスは少なくとも一つのスレッドを持ちます。 そしてこれまでは、Perl を走らせるプロセスは全てただ一つのスレッドを 持っていました。 しかし 5.8 になって、余分にスレッドをつくることができるようになりました。 それがいつどのように、いかにしてなされるのかをこれから示していきましょう。 (スレッドプログラムのモデル) There are three basic ways that you can structure a threaded program. Which model you choose depends on what you need your program to do. For many non-trivial threaded programs, you'll need to choose different models for different pieces of your program. スレッドプログラムを構築する 3 つの基本的な方法があります。 どのモデルを選ぶかはプログラムに何をやらせるかに依存します。 多くの重要なスレッドプログラムにおいては、プログラム中の異なる部分に 異なるモデルを選択する必要があるでしょう。 (ボス/ワーカー) The boss/worker model usually has one boss thread and one or more worker threads. The boss thread gathers or generates tasks that need to be done, then parcels those tasks out to the appropriate worker thread. ボス・ワーカーモデルでは通常、一つの ボス スレッドと、一つ以上の ワーカー スレッドを持ります。 ボススレッドは必要とされるタスクを集約ないし生成します。 それからそれらのタスクを適したワーカースレッドに分配します。 This model is common in GUI and server programs, where a main thread waits for some event and then passes that event to the appropriate worker threads for processing. Once the event has been passed on, the boss thread goes back to waiting for another event. このモデルは GUI とサーバプログラムに共通です。 そこではメインスレッドがイベント発生を待ち、処理のために適した ワーカースレッドにイベントを渡します。 ひとたびイベントが渡されると、ボススレッドは次のイベントのために待機します。 The boss thread does relatively little work. While tasks aren't necessarily performed faster than with any other method, it tends to have the best user-response times. ボススレッドは相対的に仕事量は少ないです。 タスクは他の方法を使ったものより必ずしも早く実行されるわけではないですが、 最もユーザーレスポンスタイムが良くなる傾向にあります。 (仕事仲間) In the work crew model, several threads are created that do essentially the same thing to different pieces of data. It closely mirrors classical parallel processing and vector processors, where a large array of processors do the exact same thing to many pieces of data. 仕事仲間モデルでは、データの様々な部分に対し本質的に同じ作業を行う いくつかのスレッドがつくられます。 これは、プロセッサの巨大な配列が多くのデータ片に対して全く同じことを行う 古典的な並列処理やベクトル処理とそっくりです。 This model is particularly useful if the system running the program will distribute multiple threads across different processors. It can also be useful in ray tracing or rendering engines, where the individual threads can pass on interim results to give the user visual feedback. プログラムを走らせているシステムが、異なるプロセスをまたいでマルチスレッドを 分配するような場合、このモデルは殊のほか便利です。 また、レイトレースやレンダリングエンジンといった、個々のスレッドが暫定的な 結果をユーザに対し視覚的にフィードバックするような場合にも便利でしょう。 (パイプライン) The pipeline model divides up a task into a series of steps, and passes the results of one step on to the thread processing the next. Each thread does one thing to each piece of data and passes the results to the next thread in line. パイプラインモデルはあるタスクを何段階の処理の連続へと分けます。 そして一つのステップの結果を次の処理を行うスレッドへと渡します。 それぞれのスレッドはデータの各部分に対し一つのことを行い、結果を次の スレッドへ渡します。 This model makes the most sense if you have multiple processors so two or more threads will be executing in parallel, though it can often make sense in other contexts as well. It tends to keep the individual tasks small and simple, as well as allowing some parts of the pipeline to block (on I/O or system calls, for example) while other parts keep going. If you're running different parts of the pipeline on different processors you may also take advantage of the caches on each processor. しばしば他の文脈でも同じぐらいの意味があるますが、二つ以上のスレッドが 並列に処理を行うようにあなたがマルチプロセッサを持っているならば、この モデルは最も意味があります。 それは、あるパイプラインの一部が進行中の間に、他のパイプラインの一部が (例えば I/O やシステムコールを)ブロックするのを 許可するのと同様、個々のタスクを小さく単純なものに留める傾向があります。 もし違うプロセッサ上で別々のパイプラインを走らせるなら、それぞれの プロセッサのキャッシュを利用するという利益を得ることができるでしょう。 This model is also handy for a form of recursive programming where, rather than having a subroutine call itself, it instead creates another thread. Prime and Fibonacci generators both map well to this form of the pipeline model. (A version of a prime number generator is presented later on.) このモデルはまた、自分自身を呼び出すサブルーチンを持つよりも、別の スレッドを生み出すような再起的プログラムの形態に利用しやすいです。 素数やフィボナッチ数列ジェネレーターは、どちらもこのパイプラインモデルの 形態にうまく位置付けられます(素数ジェネレーターの例は後で登場します)。 (Perlスレッドはどんなスレッドか?) If you have experience with other thread implementations, you might find that things aren't quite what you expect. It's very important to remember when dealing with Perl threads that Perl Threads Are Not X Threads for all values of X. They aren't POSIX threads, or DecThreads, or Java's Green threads, or Win32 threads. There are similarities, and the broad concepts are the same, but if you start looking for implementation details you're going to be either disappointed or confused. Possibly both. もしもあなたが他のスレッドの実装を経験したことがあるなら、事態は全く あなたの予想とは違うことがわかるでしょう。 Perl スレッドを扱う時には、あらゆる X に対して Perl スレッドは X スレッドではない ということを忘れてはなりません。 それらは POSIX スレッドではありません。 DecThread でもなければ Java のグリーンスレッドでないし、 Win32 スレッドでもありません。 類似点はあるし、広義の概念は同じです。 だが実装の詳細を調べだしたら、あなたは失望するか混乱するかの どちらかになるでしょう。 あるいはその両方かもしれません。 This is not to say that Perl threads are completely different from everything that's ever come before -- they're not. Perl's threading model owes a lot to other thread models, especially POSIX. Just as Perl is not C, though, Perl threads are not POSIX threads. So if you find yourself looking for mutexes, or thread priorities, it's time to step back a bit and think about what you want to do and how Perl can do it. これは、これまで登場してきたあらゆるスレッドと Perl スレッドが完全に 異なるということを言っているのではありません。 Perl スレッドは他のモデル、特に POSIX スレッドに多くを負っています。 ですが、Perl が C ではないように、Perl スレッドは POSIX スレッドでは ありません。 だから、もしあなたがミューテックスやスレッドプライオリティを 期待しているならば、ちょっと立ち戻って、自分が何をしたいのか、 Perl はいかにしてそれが可能なのかを考える時です。 However, it is important to remember that Perl threads cannot magically do things unless your operating system's threads allow it. So if your system blocks the entire process on sleep(), Perl usually will, as well. しかし、あなたのオペレーティングシステムのスレッドが許可しない限り、 Perl スレッドが魔法のように何かを行うことはできないことを覚えておきましょう。 だからもし、システムが sleep() でプロセスを丸ごとブロックするなら、通常 Perl も同様にそうするでしょう。 Perl Threads Are Different. Perl スレッドは別ものです。 (スレッドセーフなモジュール) The addition of threads has changed Perl's internals substantially. There are implications for people who write modules with XS code or external libraries. However, since Perl data is not shared among threads by default, Perl modules stand a high chance of being thread-safe or can be made thread-safe easily. Modules that are not tagged as thread-safe should be tested or code reviewed before being used in production code. スレッドの追加は Perl の内部的な実態を変化させてしまいました。 これには XS モジュールや外部ライブラリーを書いている人々も含まれます。 しかしながら、デフォルトではスレッド間で Perl のデータは共有されません。 そのため Perl モジュールはスレッドセーフであるという機会に恵まれていますし、 あるいは容易にスレッドセーフにすることができます。 スレッドセーフの札がついていないモジュールは製品版の前にテストされるか コードレビューを受けるべきです。 Not all modules that you might use are thread-safe, and you should always assume a module is unsafe unless the documentation says otherwise. This includes modules that are distributed as part of the core. Threads are a relatively new feature, and even some of the standard modules aren't thread-safe. あなたが使おうとしているモジュールの全てがスレッドセーフというわけでは ないですし、モジュールのドキュメントに安全であると書かれていないならば、 常に安全ではないものと仮定するべきです。 このことは、コアの一部として配布されているモジュールにもあてはまります。 スレッドは比較的新しい機構なので、標準モジュールの中にさえスレッドセーフで ないものがあります。 Even if a module is thread-safe, it doesn't mean that the module is optimized to work well with threads. A module could possibly be rewritten to utilize the new features in threaded Perl to increase performance in a threaded environment. 仮にあるモジュールがスレッドセーフであったとしても、そのモジュールが うまく働くように最適化されているということを意味するわけではありません。 できるだけスレッド環境でパフォーマンスが向上するように、スレッド化された Perl の新機構を利用するようモジュールを書き直したほうがよいです。 If you're using a module that's not thread-safe for some reason, you can protect yourself by using it from one, and only one thread at all. If you need multiple threads to access such a module, you can use semaphores and lots of programming discipline to control access to it. Semaphores are covered in /"Basic semaphores". もしもなんらかの理由でスレッドセーフではないモジュールを使っているならば、 ただ一つのスレッドからそれを使うことによって防ぐことができます。 そのようなモジュールにアクセスするマルチスレッドが必要ならば、セマフォや アクセスを制御するためのプログラミング原則を用いることができます。 セマフォは /"Basic semaphores" でカバーしています。 See also /"Thread-Safety of System Libraries". /"Thread-Safety of System Libraries" も参照してください。 (スレッドの基本) The threads module provides the basic functions you need to write threaded programs. In the following sections, we'll cover the basics, showing you what you need to do to create a threaded program. After that, we'll go over some of the features of the threads module that make threaded programming easier. threads モジュールは、あなたがスレッドプログラムを書くのに必要と なる基本的な機能を提供します。 次からのセクションでは、スレッドプログラムを作るのに必要なことを示しながら 基礎的なところをカバーしていきましょう。 その後で、スレッドプログラミングを容易にしてくれる threads モジュールの 機能をみることにします。 (基本的なスレッドのサポート) Thread support is a Perl compile-time option -- it's something that's turned on or off when Perl is built at your site, rather than when your programs are compiled. If your Perl wasn't compiled with thread support enabled, then any attempt to use threads will fail. スレッドのサポートは、あなたのプログラムがコンパイルされる時ではなく、 Perl のコンパイル時のオプションによります。 つまり、Perl をビルトするときに、サポートのオン・オフを行います。 スレッドがサポートされるように Perl がコンパイルされていないなら、スレッドを 使おうとしても失敗するでしょう。 Your programs can use the Config module to check whether threads are enabled. If your program can't run without them, you can say something like: スレッドが使用可能かどうかをチェックするために Config モジュールを 利用できます。 あなたのプログラムがスレッド無しには実行できないなら、次のように記述できます: A possibly-threaded program using a possibly-threaded module might have code like this: スレッドを利用するかもしれないモジュールを使うプログラムには、 次のようなコードをつけておくとよいでしょう: Since code that runs both with and without threads is usually pretty messy, it's best to isolate the thread-specific code in its own module. In our example above, that's what MyMod_threaded is, and it's only imported if we're running on a threaded Perl. スレッドの有無に関わらず走るようなコードは通常、非常に繁雑なものになるので、 スレッド専用のコードはモジュールとして分離しておくのがベストです。 上の例では、MyMod_threaded がそれで、スレッド可能な Perl 上で走るときだけ インポートされます。 (例に対する注意) In a real situation, care should be taken that all threads are finished executing before the program exits. That care has not been taken in these examples in the interest of simplicity. Running these examples as is will produce error messages, usually caused by the fact that there are still threads running when the program exits. You should not be alarmed by this. 実際の状況では、プログラムが終了する前に全てのスレッドが実行を終えることに 注意を払わなければなりません。 簡明さを重視しているのでここで取り上げる例においては、そのような注意を 払って いません。 これらの例を そのまま 実行すると、プログラムが終了する際にまだスレッドが 走っているという理由で常にエラーメッセージが出力されるでしょう。 この警告は気にしなくて良いです。 (スレッドの生成) The threads module provides the tools you need to create new threads. Like any other module, you need to tell Perl that you want to use it; use threads; imports all the pieces you need to create basic threads. threads モジュールは新たなスレッドを生成するのに必要なツールを提供します。 他のモジュール同様、それを使いたいと Perl に伝える必要があります; use threads; によって基本的なスレッドを生み出すのに必要な全ての部品が インポートされます。 The simplest, most straightforward way to create a thread is with create(): 最も単純で直接的なスレッドの生成方法は create() によるものです: create(\&sub1); ]]> The create() method takes a reference to a subroutine and creates a new thread that starts executing in the referenced subroutine. Control then passes both to the subroutine and the caller. create() メソッドはサブルーチンへのリファレンスを引数にとって新しい スレッドを生成します。 このスレッドはリファレンスされたサブルーチンの実行を開始します。 このとき制御はサブルーチンと呼び出し側との両方に渡されます。 If you need to, your program can pass parameters to the subroutine as part of the thread startup. Just include the list of parameters as part of the threads->create() call, like this: もし必要ならばスレッド開始時のサブルーチンにパラメータを渡せます。 以下のように、threads->create() の呼び出しにパラメータのリストを 含めます: 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)); ]]> ', join('<>', @InboundParameters), "<\n"); } ]]> The last example illustrates another feature of threads. You can spawn off several threads using the same subroutine. Each thread executes the same subroutine, but in a separate thread with a separate environment and potentially separate arguments. 最後の例はスレッドのもう一つの特徴を示しています。 同じサブルーチンを利用するいくつものスレッドを生成することができます。 それぞれのスレッドは同一のサブルーチンを実行するが、それぞれのスレッドは それぞれ別々の環境と引数をとることができます。 new() is a synonym for create(). new() は create() の言い換えです。 (スレッド終了の待機) Since threads are also subroutines, they can return values. To wait for a thread to exit and extract any values it might return, you can use the join() method: スレッドはサブルーチンでもあるので、値を返せます。 スレッドが終了して何らかの戻り値を得るのを待つために、join() を使えます: create(\&sub1); ]]> join(); print('Thread returned ', join(', ', @ReturnData), "\n"); ]]> In the example above, the join() method returns as soon as the thread ends. In addition to waiting for a thread to finish and gathering up any values that the thread might have returned, join() also performs any OS cleanup necessary for the thread. That cleanup might be important, especially for long-running programs that spawn lots of threads. If you don't want the return values and don't want to wait for the thread to finish, you should call the detach() method instead, as described next. 上の例では、スレッドが終了するとすぐに join() メソッドが戻ります。 スレッドの終了と、返すべき値を収集するための待機に加えて、join() は スレッドが必要とする OS レベルのクリーンナップを実行します。 このクリーンナップは重要です; 特に長時間にわたって実行されるプログラムが 大量のスレッドを生成する場合には。 もしも戻り値を必要とせず、スレッドの終了を待つ必要もなければ、かわりに 次に説明する detach() メソッドを呼び出すべきです。 NOTE: In the example above, the thread returns a list, thus necessitating that the thread creation call be made in list context (i.e., my ($thr)). See threads/"$thr-join()"> and threads/"THREAD CONTEXT" for more details on thread context and return values. 注意: 上記の例では、スレッドはリストを返すので、スレッド作成呼び出しは (my ($thr) のように)リストコンテキストで行われる必要があります。 スレッドのコンテキストと返り値に関する更なる詳細については threads/"$thr-join()"> と threads/"THREAD CONTEXT" を参照してください。 (スレッドを無視する) join() does three things: it waits for a thread to exit, cleans up after it, and returns any data the thread may have produced. But what if you're not interested in the thread's return values, and you don't really care when the thread finishes? All you want is for the thread to get cleaned up after when it's done. join() は三つのことを行います。 スレッド終了の待機、その後のクリーンナップ、そしてスレッドが生み出したで あろうデータを返すことです。 しかし、スレッドの返す値に関心がなく、いつスレッドが終了するのかを本当に 気にしない場合には? 必要なのは仕事がなされた後にスレッドがクリーンナップされることです。 In this case, you use the detach() method. Once a thread is detached, it'll run until it's finished; then Perl will clean up after it automatically. このような場合、detach() メソッドを使います。 ひとたびスレッドが detach されると、スレッドは終了するまで実行し続け、 そのあと Perl が自動的にクリーンナップを行います。 create(\&sub1); # Spawn the thread ]]> detach(); # Now we officially don't care any more ]]> Once a thread is detached, it may not be joined, and any return data that it might have produced (if it was done and waiting for a join) is lost. 一度あるスレッドが detach されたら、そのスレッドは join されないでしょう。 (join のために待機しても)スレッドが生成したであろうデータは失われます。 detach() can also be called as a class method to allow a thread to detach itself: detach() はスレッドが自分自身を detach するためにクラスメソッドとしても 呼び出されます: create(\&sub1); ]]> detach(); # Do more work } ]]> (プロセスとスレッドの終了) With threads one must be careful to make sure they all have a chance to run to completion, assuming that is what you want. スレッドを使う場合は、全てのスレッドが確実に完全に実行される(それが あなたの望むもののはずです)ように注意しなければなりません。 An action that terminates a process will terminate all running threads. die() and exit() have this property, and perl does an exit when the main thread exits, perhaps implicitly by falling off the end of your code, even if that's not what you want. プロセスを終了させる行動は実行中の 全ての スレッドを終了させます。 die() と exit() はこの性質を持ち、(あなたが望んでいないとしても) おそらくは暗黙のうちにコードの最後に到達することによってメインスレッドが 終了すると、perl は終了します。 As an example of this case, this code prints the message "Perl exited with active threads: 2 running and unjoined": この場合の例として、このコードは "Perl exited with active threads: 2 running and unjoined" というメッセージを 表示します: new(\&thrsub, "test1"); my $thr2 = threads->new(\&thrsub, "test2"); sub thrsub { my ($message) = @_; sleep 1; print "thread $message\n"; } ]]> But when the following lines are added at the end: しかし以下の行が最後に追加されると: join; $thr2->join; ]]> it prints two lines of output, a perhaps more useful outcome. 2 行の出力があり、おそらくより有用な成果となります。 (スレッドとデータ) Now that we've covered the basics of threads, it's time for our next topic: Data. Threading introduces a couple of complications to data access that non-threaded programs never need to worry about. これでスレッドの基本部分については見終わりました。 次の話題はデータです。 スレッドを扱うと、非スレッドプログラムが決して心配することのなかった データアクセスに対する二つの複雑さを導入することになります。 (共有データと非共有データ) The biggest difference between Perl ithreads and the old 5.005 style threading, or for that matter, to most other threading systems out there, is that by default, no data is shared. When a new Perl thread is created, all the data associated with the current thread is copied to the new thread, and is subsequently private to that new thread! This is similar in feel to what happens when a UNIX process forks, except that in this case, the data is just copied to a different part of memory within the same process rather than a real fork taking place. iスレッド と古い 5.005 型スレッドの間の(もっといえば、そこから外れる 多くのスレッドシステムにとっての)最大の違いは、デフォルトではデータが 共有されないという点です。 新しい Perl スレッドが生成されるとき、現在のスレッドに関連する全てのデータは 新しいスレッドにコピーされます。 続いてそのデータは新しいスレッド内でプライベートなものとなります! これは UNIX のプロセスが fork するときに起きることと似ています。 ただしこの場合、実際の fork ではメモリ上での置き換えが起こるのに対して、この データは同一プロセッサ内の違うメモリ部分にコピーされるだけであるという点が 除かれます。 To make use of threading, however, one usually wants the threads to share at least some data between themselves. This is done with the threads::shared module and the :shared attribute: しかしスレッド機能を利用するならば、通常はスレッド間で少なくともいくつかの データを共有したいものです。 これは threads::shared モジュールと :shared 属性によって行われます: create(sub { $foo++; $bar++; })->join(); ]]> In the case of a shared array, all the array's elements are shared, and for a shared hash, all the keys and values are shared. This places restrictions on what may be assigned to shared array and hash elements: only simple values or references to shared variables are allowed - this is so that a private variable can't accidentally become shared. A bad assignment will cause the thread to die. For example: 共有化された配列の場合は、配列の要素全てが共有化されます。 共有化されたハッシュの場合、全てのキーと値が共有されます。 共有化された配列やハッシュの要素に代入するものに対しては制限があります: 単純な値や共有化された変数へのリファレンスは可能です。 これは、プライベート変数が図らずも共有化されることがないからです。 不正な代入はスレッドを殺してしまうでしょう。 例えば: Note that a shared variable guarantees that if two or more threads try to modify it at the same time, the internal state of the variable will not become corrupted. However, there are no guarantees beyond this, as explained in the next section. 共有変数が、複数のスレッドが同時にその変数に変更を加えようとしても、 変数の内部状態は破壊されないことを保証していることに注意してください。 しかし次のセクションで説明するように、ここを超えてしまうと保証は なくなってしまいます。 (スレッドの落とし穴: 競合) While threads bring a new set of useful tools, they also bring a number of pitfalls. One pitfall is the race condition: スレッドは新しい便利なツールを一揃いもたらしてくれる一方で、たくさんの 落とし穴ももたらします。 その一つは競合条件です: create(\&sub1); my $thr2 = threads->create(\&sub2); ]]> join; $thr2->join; print("$a\n"); ]]> What do you think $a will be? The answer, unfortunately, is it depends. Both sub1() and sub2() access the global variable $a, once to read and once to write. Depending on factors ranging from your thread implementation's scheduling algorithm to the phase of the moon, $a can be 2 or 3. $a はどうなるでしょうか? 残念ながら、その答えは 場合によりけり です。 sub1() と sub2() はどちらも一度だけ読み込み、一度だけ書き込むために グローバル変数 $a にアクセスします。 あなたの使っているスレッド実装のスケジューリングアルゴリズムから月の 満ち欠けまでの種々の要因によって、$a は 2 にも 3 にもなりえます。 Race conditions are caused by unsynchronized access to shared data. Without explicit synchronization, there's no way to be sure that nothing has happened to the shared data between the time you access it and the time you update it. Even this simple code fragment has the possibility of error: 競合条件は共有データに対して非同期なアクセスを行うことによって生じます。 明示的に同期をとらない限り、アクセスして更新するまでの間に 共有データに何も起こらないことを確実にする方法はありません。 こんな単純なコードでさえ、エラーの可能性があります: create(sub { $b = $a; $a = $b + 1; }); my $thr2 = threads->create(sub { $c = $a; $a = $c + 1; }); $thr1->join; $thr2->join; ]]> Two threads both access $a. Each thread can potentially be interrupted at any point, or be executed in any order. At the end, $a could be 3 or 4, and both $b and $c could be 2 or 3. 二つのスレッドが $a にアクセスします。 それぞれのスレッドはいずれかの時点で割り込まれたり、いずれかの順番で 実行される可能性があります。 結局、$a は 3 か 4 に、$b と $c はともに 2 か 3 になるでしょう。 Even $a += 5 or $a++ are not guaranteed to be atomic. $a += 5 や $a++ でさえ、アトミックな演算であることを保証されません。 Whenever your program accesses data or resources that can be accessed by other threads, you must take steps to coordinate access or risk data inconsistency and race conditions. Note that Perl will protect its internals from your race conditions, but it won't protect you from you. 他のスレッドによってアクセスされる可能性のあるデータやリソースにあなたの プログラムがアクセスするときはいつでも、整合的なアクセスのための手順を 踏まなければなりません。 さもなければデータの一貫性が崩れたり、競合条件に陥るリスクを 負うことになります。 (同期と制御) Perl provides a number of mechanisms to coordinate the interactions between themselves and their data, to avoid race conditions and the like. Some of these are designed to resemble the common techniques used in thread libraries such as pthreads; others are Perl-specific. Often, the standard techniques are clumsy and difficult to get right (such as condition waits). Where possible, it is usually easier to use Perlish techniques such as queues, which remove some of the hard work involved. 競合条件やそれに似た状態を回避するために、スレッドとデータとの間の相互作用を 調整する多くのメカニズムを Perl は提供します。 それらのうちのあるものは、pthreads のようなスレッドライブラリにおいて 使われる共通のテクニックに似た設計がなされています。 またあるものは Perl に特化しています。 しばしば標準的なテクニックというものはぎこちないもので、正しく扱うには 難しいです。 可能なところでは通常、キューのような Perl 的テクニックはより簡単で、難しい 仕事のうちのあるものを取り除いてくれます。 (アクセス制御：lock()) The lock() function takes a shared variable and puts a lock on it. No other thread may lock the variable until the variable is unlocked by the thread holding the lock. Unlocking happens automatically when the locking thread exits the block that contains the call to the lock() function. Using lock() is straightforward: This example has several threads doing some calculations in parallel, and occasionally updating a running total: lock() 関数は共有変数を引数にとり、それにロックをかけます。 ロックを保持するスレッドによって変数のロックが解除されるまで、他のスレッドは ロックをかけることができません。 ロックしているスレッドが lock() 関数の呼び出しを含むブロックの外に出ると ロックは自動的に解除されます。 lock() の利用は率直なやり方です。 この例は、ある計算を並列的に処理し、時折その総計値を更新するいくつかの スレッドを伴っています: create(\&calc); my $thr2 = threads->create(\&calc); my $thr3 = threads->create(\&calc); $thr1->join(); $thr2->join(); $thr3->join(); print("total=$total\n"); ]]> lock() blocks the thread until the variable being locked is available. When lock() returns, your thread can be sure that no other thread can lock that variable until the block containing the lock exits. ロックされている変数が利用可能になるまで、lock() はそのスレッドを ブロックします。 lock() が戻ってくると、そのロックが存在しているブロックの外に出ない限り、 他のスレッドがその変数をロックできないことが確実になります。 It's important to note that locks don't prevent access to the variable in question, only lock attempts. This is in keeping with Perl's longstanding tradition of courteous programming, and the advisory file locking that flock() gives you. ロックは問題の変数にアクセスするのを阻止するのではなくて、ロックの試みを 阻止するということに注意することが重要です。 これは Perl の長年にわたる作法どおりのプログラミングの伝統と、flock() が 提供する勧告ロックとに調和するものです。 You may lock arrays and hashes as well as scalars. Locking an array, though, will not block subsequent locks on array elements, just lock attempts on the array itself. スカラ変数同様、配列やハッシュにもロックをかけるかもしれません。 しかし、配列へのロックは、配列の要素に対する二次的なロックを ブロックするのではなく、配列そのものへのロックの試みをブロックします。 Locks are recursive, which means it's okay for a thread to lock a variable more than once. The lock will last until the outermost lock() on the variable goes out of scope. For example: ロックは再帰的、つまりスレッドはある変数に対し何度もロックをかけて大丈夫です。 一番外側の lock() がスコープを抜けるまでロックは続きます。 例えば: Note that there is no unlock() function - the only way to unlock a variable is to allow it to go out of scope. unlock() 関数は無いことに注意してください。 変数のロックを解除する方法はスコープを抜けさせることだけです。 A lock can either be used to guard the data contained within the variable being locked, or it can be used to guard something else, like a section of code. In this latter case, the variable in question does not hold any useful data, and exists only for the purpose of being locked. In this respect, the variable behaves like the mutexes and basic semaphores of traditional thread libraries. ロックされている変数内に保持されているデータをガードするか、あるいは コードのセクションのようなものを守るために、ロックは用いられます。 後者の場合、問題の変数は役に立つデータを持たず、ロックの目的のためにだけ 存在します。 この点からすると、その変数は伝統的なスレッドライブラリにおける ミューテックスや基本的なセマフォのような振る舞いをするといえます。 (スレッドの落とし穴: デッドロック) Locks are a handy tool to synchronize access to data, and using them properly is the key to safe shared data. Unfortunately, locks aren't without their dangers, especially when multiple locks are involved. Consider the following code: ロックはデータに同期アクセスするための便利なツールです。 適切に使えば安全な共有データへの鍵となります。 残念なことに、ロックには危険が伴います。 特に複数のロックが関わるとそうなります。 次のコードを考えてみましょう: create(sub { lock($a); sleep(20); lock($b); }); my $thr2 = threads->create(sub { lock($b); sleep(20); lock($a); }); ]]> This program will probably hang until you kill it. The only way it won't hang is if one of the two threads acquires both locks first. A guaranteed-to-hang version is more complicated, but the principle is the same. このプログラムは恐らくあなたが kill するまで固まってしまうでしょう。 ハングさせないための唯一の方法は、どちらかのスレッドが先に両方のロックを 獲得することです。 ハングを保証する方法はもっと複雑ですが、原理はこれと同じです。 The first thread will grab a lock on $a, then, after a pause during which the second thread has probably had time to do some work, try to grab a lock on $b. Meanwhile, the second thread grabs a lock on $b, then later tries to grab a lock on $a. The second lock attempt for both threads will block, each waiting for the other to release its lock. 最初のスレッドが $a のロックを手にします。 それから二つ目のスレッドが何かやっている間に一時停止した後、$b への ロックを手に入れようと試みます。 ところが、その二つ目のスレッドは $b へのロックを手にします。 そしてその後 $a のロックを手に入れようとします。 それぞれのスレッドが、他方のスレッドのロックが開放されるの待つため、 二番目のロックへの試みはブロックしてしまいます。 This condition is called a deadlock, and it occurs whenever two or more threads are trying to get locks on resources that the others own. Each thread will block, waiting for the other to release a lock on a resource. That never happens, though, since the thread with the resource is itself waiting for a lock to be released. この状態をデッドロックと言います。 二つ以上のスレッドが他スレッドの所有するリソースをロックしようと 試みるときにはいつでも生じます。 他のスレッドがリソースへのロックを開放するのを待って、互いにスレッドが ブロックします。 しかし、リソースを持っているスレッドが自分自身のロックの開放を待つ場合は 生じません。 There are a number of ways to handle this sort of problem. The best way is to always have all threads acquire locks in the exact same order. If, for example, you lock variables $a, $b, and $c, always lock $a before $b, and $b before $c. It's also best to hold on to locks for as short a period of time to minimize the risks of deadlock. この種の問題を扱う方法はたくさんあります。 最もよい方法は、常に全てのスレッドが正確に同じ順番でロックを獲得するように することです。 例えば、$a、$b、$cをロックするなら、いつでも $b の前に $a を、 そして $c の前に $b をロックするようにします。 デッドロックの危険を最小にするために、短い時間だけロックを保持するのも良い手です。 The other synchronization primitives described below can suffer from similar problems. 下記で説明するような他のプリミティブな同期も同様な問題を抱える可能性があります。 (キュー: データの受け渡し) A queue is a special thread-safe object that lets you put data in one end and take it out the other without having to worry about synchronization issues. They're pretty straightforward, and look like this: キューとは、一方の端にデータを入れ、他方から取り出すことによって、 同期の問題を心配しなくてすむ、特別なスレッドセーフオブジェクトです。 これらは非常に素朴で、以下のようなものです: new(); my $thr = threads->create(sub { while (my $DataElement = $DataQueue->dequeue()) { print("Popped $DataElement off the queue\n"); } }); ]]> enqueue(12); $DataQueue->enqueue("A", "B", "C"); sleep(10); $DataQueue->enqueue(undef); $thr->join(); ]]> You create the queue with Thread::Queue->new(). Then you can add lists of scalars onto the end with enqueue(), and pop scalars off the front of it with dequeue(). A queue has no fixed size, and can grow as needed to hold everything pushed on to it. Thread::Queue->new() でキューを生成します。 それから enqueue() を使ってキューの 最後にスカラのリストを追加します。 そして dequeue() でキューの前方からスカラを取り出します。 キューのサイズは固定していません。 キューの中に押し込められたものを保持する必要に応じてサイズは成長します。 If a queue is empty, dequeue() blocks until another thread enqueues something. This makes queues ideal for event loops and other communications between threads. もしキューが空っぽの場合、他のスレッドが何かをキューの中に入れるまで、 dequeue() はブロックします。 そのため、イベントループやスレッド間でのコミュニケーションにとって、 キューは理想的です。 (セマフォ：データアクセスの同期) Semaphores are a kind of generic locking mechanism. In their most basic form, they behave very much like lockable scalars, except that they can't hold data, and that they must be explicitly unlocked. In their advanced form, they act like a kind of counter, and can allow multiple threads to have the lock at any one time. セマフォは包括的なロックメカニズムの一種です。 最も基本となる形態では、 セマフォはデータを持つことはできないし、明示的にロック解除されなければ ならないことを除くと、ロック可能なスカラそっくりに振る舞います。 発展的な形態においては、一種のカウンターのように動作し、いつでも複数の スレッドが ロック を持つことを可能にします。 (ベーシックなセマフォ) Semaphores have two methods, down() and up(): down() decrements the resource count, while up() increments it. Calls to down() will block if the semaphore's current count would decrement below zero. This program gives a quick demonstration: セマフォは二つのメソッド、down() と up() を持ちます。 down() はリソースのカウントを減少させ、up() の方は増加させます。 セマフォの現在のカウントが 0 を下回るようなら down() の呼び出しは ブロックします。 このプログラムは短い例です: new(); my $GlobalVariable :shared = 0; ]]> create(\&sample_sub, 1); $thr2 = threads->create(\&sample_sub, 2); $thr3 = threads->create(\&sample_sub, 3); ]]> down(); $LocalCopy = $GlobalVariable; print("$TryCount tries left for sub $SubNumber (\$GlobalVariable is $GlobalVariable)\n"); sleep(2); $LocalCopy++; $GlobalVariable = $LocalCopy; $semaphore->up(); } } ]]> join(); $thr2->join(); $thr3->join(); ]]> The three invocations of the subroutine all operate in sync. The semaphore, though, makes sure that only one thread is accessing the global variable at once. このサブルーチンに対する三つの呼び出しは同時に作用します。 しかし一度に一つのスレッドだけが、グローバル変数にアクセスすることを セマフォが保証します。 (高度なセマフォ) By default, semaphores behave like locks, letting only one thread down() them at a time. However, there are other uses for semaphores. デフォルトでは、セマフォはロックのように振舞います。 一度にただ一つのスレッドだけが down() できます。 しかし、セマフォには別の使い方があります。 Each semaphore has a counter attached to it. By default, semaphores are created with the counter set to one, down() decrements the counter by one, and up() increments by one. However, we can override any or all of these defaults simply by passing in different values: それぞれのセマフォは、関連付けられたカウンタを持ちます。 デフォルトでセマフォは生成時、カウンタに 1 がセットされます。 down() はカウンタから 1 を引き、up() は 1 を足します。 しかしこの規定値の一部ないしは全部を別の値でもって上書きできます: new(5); # Creates a semaphore with the counter set to five ]]> create(\&sub1); my $thr2 = threads->create(\&sub1); ]]> down(5); # Decrements the counter by five # Do stuff here $semaphore->up(5); # Increment the counter by five } ]]> detach(); $thr2->detach(); ]]> If down() attempts to decrement the counter below zero, it blocks until the counter is large enough. Note that while a semaphore can be created with a starting count of zero, any up() or down() always changes the counter by at least one, and so $semaphore->down(0) is the same as $semaphore->down(1). もしも down() がカウンタを 0 より小さい値に下げようとするなら、 カウンタが十分な大きさになるまでブロックします。 セマフォはカウンタの値を 0 にして生成することができる一方、up() や down() は常に、少なくとも 1 の変化をカウンタに対して行うことに 注意してください。 だから、$semaphore->down(0) は $semaphore->down(1) と同じです。 The question, of course, is why would you do something like this? Why create a semaphore with a starting count that's not one, or why decrement or increment it by more than one? The answer is resource availability. Many resources that you want to manage access for can be safely used by more than one thread at once. もちろん、問題はどうしてこんなことをするのかということです。 なぜセマフォを 1 ではなくて、0 から始めるように生成するのでしょうか? あるいは、なぜ 1 より大きい値で増減を行うのでしょうか？ その答えはリソースの利用可能性です。 あなたがアクセス管理をしたいリソースの多くは、同時に一つを超える数の スレッドによって安全に利用されます。 For example, let's take a GUI driven program. It has a semaphore that it uses to synchronize access to the display, so only one thread is ever drawing at once. Handy, but of course you don't want any thread to start drawing until things are properly set up. In this case, you can create a semaphore with a counter set to zero, and up it when things are ready for drawing. 例として GUI 駆動型のプログラムを取り上げてみましょう。 プログラムは、ディスプレイに同期アクセスするためにセマフォを持っています。 そうして一度にただ一つのスレッドだけが描画を行っています。 簡単な話ですが、もちろん、ちゃんと準備ができるまでどのスレッドにも描画を 始めてもらいたくはありません。 こんな場合に、カウンタを 0 にしてセマフォを生成するのです。 そして描画の準備ができたら、カウンタを増加させます。 Semaphores with counters greater than one are also useful for establishing quotas. Say, for example, that you have a number of threads that can do I/O at once. You don't want all the threads reading or writing at once though, since that can potentially swamp your I/O channels, or deplete your process' quota of filehandles. You can use a semaphore initialized to the number of concurrent I/O requests (or open files) that you want at any one time, and have your threads quietly block and unblock themselves. 1 より大きいカウンタを持つセマフォはクォータの確立にも役立ちます。 例えば、同時に I/O を使うスレッドがいくつもあるとします。 だが、全てのスレッドが同時に読み書きをするのは望みません。 そんなことをしたら I/O チャンネルを圧迫するかもしれないし、プロセスに 割り当てられたファイルハンドルを枯渇させてしまうかもしれないからです。 あなたがいつでも必要とし、スレッドに暗黙にブロック・アンブロックを させたいだけの同時 I/O リクエスト数(あるいはオープンファイル数)で 初期設定されたセマフォを利用すればよいです。 Larger increments or decrements are handy in those cases where a thread needs to check out or return a number of resources at once. あるスレッドが一度にたくさんのリソースを借りたり戻したりするような こういうケースでは、大きな数で増減を行うのが便利です。 (条件を待つ) The functions cond_wait() and cond_signal() can be used in conjunction with locks to notify co-operating threads that a resource has become available. They are very similar in use to the functions found in pthreads. However for most purposes, queues are simpler to use and more intuitive. See threads::shared for more details. 関数 cond_wait() と cond_signal() は、ロックが同時発生する時に、 リソースが利用可能になった協調型スレッドに通知を行うために用います。 これらは、pthreads にある関数とよく似ています。 しかしほとんどの目的において、キューの方がより単純で直感的です。 更なる詳細は threads::shared を参照してください。 (制御の明け渡し) There are times when you may find it useful to have a thread explicitly give up the CPU to another thread. You may be doing something processor-intensive and want to make sure that the user-interface thread gets called frequently. Regardless, there are times that you might want a thread to give up the processor. あるスレッドが明示的に他のスレッドへと CPU を譲り渡せられたら便利だと 思うことがあるでしょう。 あなたはプロセッサ集約的なことをしようとしているかもしれませんし、 ユーザーインターフェース担当のスレッドが呼び出されることを確認したいと 思うかもしれません。 とにかく、スレッドがプロセッサを明け渡せたら、ということがよくあります。 Perl's threading package provides the yield() function that does this. yield() is pretty straightforward, and works like this: Perl のスレッドパッケージはこれを実現する yield() 関数を提供しています。 yield() はとても素朴で、このように動作します: yield(); $foo = 50; while($foo--) { print("In thread $thread\n"); } } ]]> create(\&loop, 'first'); my $thr2 = threads->create(\&loop, 'second'); my $thr3 = threads->create(\&loop, 'third'); ]]> It is important to remember that yield() is only a hint to give up the CPU, it depends on your hardware, OS and threading libraries what actually happens. On many operating systems, yield() is a no-op. Therefore it is important to note that one should not build the scheduling of the threads around yield() calls. It might work on your platform but it won't work on another platform. yield() は CPU を明け渡すためのヒントでしかありません。 実際に何が起こるのかは、ハードウェアや OS、そしてスレッドライブラリに 依存しています。 多くのオペレーティングシステムにおいて、yield() は何も機能しません。 それゆえ、yield() を呼んでスレッドのスケジューリングをたてるべきでは ないことに注意することが重要です。 あなたのプラットフォームでは動作したとしても、別のプラットフォームでは 動かないかもしれません。 (一般的なスレッドユーティリティルーチン) We've covered the workhorse parts of Perl's threading package, and with these tools you should be well on your way to writing threaded code and packages. There are a few useful little pieces that didn't really fit in anyplace else. Perlのスレッドパッケージの働き部分をみてきました。 これらの道具を使い、あなたのやり方でスレッドコードとパッケージを 書いていくことができるはずです。 他の場所では実際にはフィットしないけれども、便利な小物も少しはあります。 (私はどのスレッドにいる?) The threads->self() class method provides your program with a way to get an object representing the thread it's currently in. You can use this object in the same way as the ones returned from thread creation. threads->self() クラスメソッドを使うと、現在のスレッドを表す オブジェクトを得ることができます。 スレッドを生成するときに返ってくるオブジェクトと同じように、この オブジェクトを使うことができます。 (スレッド ID) tid() is a thread object method that returns the thread ID of the thread the object represents. Thread IDs are integers, with the main thread in a program being 0. Currently Perl assigns a unique TID to every thread ever created in your program, assigning the first thread to be created a TID of 1, and increasing the TID by 1 for each new thread that's created. When used as a class method, threads->tid() can be used by a thread to get its own TID. tid() はオブジェクトが表すスレッドの ID を返すメソッドです。 スレッド ID は整数で、プログラム中のメインスレッドは 0 です。 現在の Perl は、プログラム中で生成された全てのスレッドに一意な ID を つけます。 最初に生成されたスレッドには 1 があてられ、新しいスレッドが作られる度に ID は 1 ずつ増えていきます。 クラスメソッドとして使われると、threads->tid() はスレッドが自身の TID を得るために使われます。 (このスレッドは同じものか?) The equal() method takes two thread objects and returns true if the objects represent the same thread, and false if they don't. equal() メソッドは二つのスレッドオブジェクトを引数にとり、オブジェクトが 同じスレッドを示していれば真を、そうでなければ偽を返します。 Thread objects also have an overloaded == comparison so that you can do comparison on them as you would with normal objects. スレッドオブジェクトは比較演算子 == をオーバーロードするので、普通の オブジェクトのようにそれらを比較することもできます。 (どのスレッドが実行されているのか?) threads->list() returns a list of thread objects, one for each thread that's currently running and not detached. Handy for a number of things, including cleaning up at the end of your program (from the main Perl thread, of course): threads->list() はスレッドオブジェクトのリストを返します。 それぞれは現在実行中で detach されていないスレッドです。 プログラムの終わりに(もちろん Perl のメインスレッドから) クリーンナップするのも含めていろいろな点で便利です: list()) { $thr->join(); } ]]> If some threads have not finished running when the main Perl thread ends, Perl will warn you about it and die, since it is impossible for Perl to clean up itself while other threads are running. もしメインスレッドが終了する時に、あるスレッドが実行を終了していなかったら、 Perl は警告を発し、die します。 これは、他のスレッドが実行中の間は Perl が自分自身をクリーンナップ できないためです。 NOTE: The main Perl thread (thread 0) is in a detached state, and so does not appear in the list returned by threads->list(). 注意: Perl のメインスレッド (スレッド 0) は detach された 状態にあるので、 threads->list() で返されるリストには現れません。 (完全な例) Confused yet? It's time for an example program to show some of the things we've covered. This program finds prime numbers using threads. まだ混乱していますか? では、サンプルプログラムを使ってこれまで見てきたことのいくつかを示す時です。 このプログラムはスレッドを使って素数を見つけだします。 new(); 11 for my $i ( 3 .. 1000 ) { 12 $stream->enqueue($i); 13 } 14 $stream->enqueue(undef); 15 16 threads->create(\&check_num, $stream, 2); 17 $kid->join(); 18 19 sub check_num { 20 my ($upstream, $cur_prime) = @_; 21 my $kid; 22 my $downstream = Thread::Queue->new(); 23 while (my $num = $upstream->dequeue()) { 24 next unless ($num % $cur_prime); 25 if ($kid) { 26 $downstream->enqueue($num); 27 } else { 28 print("Found prime $num\n"); 29 $kid = threads->create(\&check_num, $downstream, $num); 30 } 31 } 32 if ($kid) { 33 $downstream->enqueue(undef); 34 $kid->join(); 35 } 36 } ]]> This program uses the pipeline model to generate prime numbers. Each thread in the pipeline has an input queue that feeds numbers to be checked, a prime number that it's responsible for, and an output queue into which it funnels numbers that have failed the check. If the thread has a number that's failed its check and there's no child thread, then the thread must have found a new prime number. In that case, a new child thread is created for that prime and stuck on the end of the pipeline. このプログラムは素数を発生させるためにパイプラインモデルを利用しています。 パイプラインにおけるそれぞれのスレッドは、素数を見つけるために チェックされる数を渡す入力キューと、チェックに失敗した数をかき集めておく 出力キューとを持ちます。 チェックに失敗した数がスレッドにあり、かつ、子スレッドがない場合、その スレッドは新しい素数を見つけたことになります。 この場合、新しい子スレッドはその素数のために生成され、パイプラインの後ろに くっつけられます。 This probably sounds a bit more confusing than it really is, so let's go through this program piece by piece and see what it does. (For those of you who might be trying to remember exactly what a prime number is, it's a number that's only evenly divisible by itself and 1.) これは実際よりもわかりにくいかもしれません。 だからこのプログラムを部分部分に分けて、なにをしているのかを見てみましょう。 (素数とは正確には何だったかということを思い出そうされている方のためにいうと、 自分自身と 1 でのみ割り切れる数のことです。) The bulk of the work is done by the check_num() subroutine, which takes a reference to its input queue and a prime number that it's responsible for. After pulling in the input queue and the prime that the subroutine is checking (line 20), we create a new queue (line 22) and reserve a scalar for the thread that we're likely to create later (line 21). 作業の大半は check_num() ルーチンによってなされます。 このルーチンは入力キューへのリファレンスとスレッドが受け持つ素数を 引数にとります。 [引数を]入力キューとサブルーチンがチェックする素数[のローカル変数]に 入れた後(20 行目)、新しいキューを生成します(22 行目)。 そして、後で生成するかもしれないスレッドを入れるスカラ変数を 用意します(21 行目)。 The while loop from lines 23 to line 31 grabs a scalar off the input queue and checks against the prime this thread is responsible for. Line 24 checks to see if there's a remainder when we divide the number to be checked by our prime. If there is one, the number must not be evenly divisible by our prime, so we need to either pass it on to the next thread if we've created one (line 26) or create a new thread if we haven't. 23 行目から31 行目までの while ループで入力キューからスカラ値を 取り出し、このスレッドが受け持つ素数でチェックします。 24 行目では、チェックされる数に対する除算を行い、余りがあるかどうかを 調べます。 もしあれば、その数は素数では割れないということです。 そこでその数を、すでに生成してあるのであれば次のスレッドに渡しますし、 そうでなければ新しいスレッドを作ります。 The new thread creation is line 29. We pass on to it a reference to the queue we've created, and the prime number we've found. 29 行目で新しいスレッドの生成を行っています。 そのスレッドに、先に作ったキューへのリファレンスと発見された素数を渡します。 Finally, once the loop terminates (because we got a 0 or undef in the queue, which serves as a note to terminate), we pass on the notice to our child and wait for it to exit if we've created a child (lines 32 and 35). 最後に、(キューの中に 0 か undef があるかして)ループが終了すると、 子スレッドを作っていた場合には子スレッドに注意を促し[(undef を送る)]、 実行が終了するのを待ちます(32, 35 行目)。 Meanwhile, back in the main thread, we first create a queue (line 10) and queue up all the numbers from 3 to 1000 for checking (lines 11-13), plus a termination notice (line 14). Then we create the initial child threads (line 16), passing it the queue and the first prime: 2. Finally, we wait for the first child thread to terminate (line 17). Because a child won't terminate until its child has terminated, we know that we're done once we return from the join(). 一方、メインスレッドに戻ってみると、まずキューを生成し(10 行目)、 チェックするための 3 から 1000 までの全ての数をキューに入れ(11-13 行目)、 終了チェック用のマークを追加します(14 行目)。 それから最初の子スレッドを作って(16 行目)、キューと最初の素数である 2 を 渡します。 最後に、最初の子スレッドが終了するのを待ちます(17 行目)。 ある子スレッドの子スレッドが終了するまで、そのスレッドは終了しないので、 join() から戻ってきた時点で作業が終わったことになります。 That's how it works. It's pretty simple; as with many Perl programs, the explanation is much longer than the program. 以上が仕組みです。 とても単純です; 多くのPerlプログラムにとってそうであるように、 説明の方が当のプログラム以上にとても長くなります。 (様々なスレッドの実装) Some background on thread implementations from the operating system viewpoint. There are three basic categories of threads: user-mode threads, kernel threads, and multiprocessor kernel threads. オペレーティングシステムの観点からみた、スレッド実装についての背景です。 スレッドには三つの基本的なカテゴリーがあります: ユーザーモードスレッド、 カーネルスレッド、マルチプロセッサカーネルスレッドです。 User-mode threads are threads that live entirely within a program and its libraries. In this model, the OS knows nothing about threads. As far as it's concerned, your process is just a process. ユーザーモードスレッドとは、完全にプログラムとライブラリの中に存在する スレッドです。 このモデルにおいては、OS はスレッドについて何も関知しません。 OS からしてみる限り、あなたのプロセスはただのひとつのプロセスです。 This is the easiest way to implement threads, and the way most OSes start. The big disadvantage is that, since the OS knows nothing about threads, if one thread blocks they all do. Typical blocking activities include most system calls, most I/O, and things like sleep(). これは最も簡単なスレッドの実装であり、ほとんどの OS が最初にとった方法です。 この方法の大きな欠点は、OS がスレッドに関知していないために、 もしも一つのスレッドがブロックをしたら、全てのスレッドがブロックしてしまう ということです。 典型的なブロック行為には、ほとんどのシステムコール、ほとんどの I/O、そして sleep() のようなものが含まれます。 Kernel threads are the next step in thread evolution. The OS knows about kernel threads, and makes allowances for them. The main difference between a kernel thread and a user-mode thread is blocking. With kernel threads, things that block a single thread don't block other threads. This is not the case with user-mode threads, where the kernel blocks at the process level and not the thread level. カーネルスレッドは進化の第二段階です。 OS はカーネルスレッドについて知っていて、その許可を出します。 カーネルスレッドとユーザーモードスレッドの主要な違いは、 ブロッキングについてです。 カーネルスレッドでは、一つのスレッドをブロックした事で他のスレッドまで ブロックすることはありません。 これはユーザーモードスレッドにおいては成り立ちません。 ユーザーモードでは、カーネルがブロックするのはプロセスレベルであって、 スレッドレベルではないからです。 This is a big step forward, and can give a threaded program quite a performance boost over non-threaded programs. Threads that block performing I/O, for example, won't block threads that are doing other things. Each process still has only one thread running at once, though, regardless of how many CPUs a system might have. これは大きな前進であり、非スレッドプログラムに対し、スレッドプログラムが 大きなパフォーマンスの向上を得ることを可能にしています。 例えば、I/O の実行をブロックするスレッドは、他のことを行うスレッドを ブロックしないでしょう。 しかし、システムがいくつ CPU を備えているかに関係なく、それぞれのプロセスは いまだに一度に一つのスレッドしか走らせません。 Since kernel threading can interrupt a thread at any time, they will uncover some of the implicit locking assumptions you may make in your program. For example, something as simple as $a = $a + 2 can behave unpredictably with kernel threads if $a is visible to other threads, as another thread may have changed $a between the time it was fetched on the right hand side and the time the new value is stored. カーネルのスレッド制御がいつでも割り込めるので、あなたがプログラム中に つくった暗黙のロックの前提が白日の下にさらけ出してしまうでしょう。 例えば、$a = $a + 2のような単純なものでも、$a が他のスレッドから 見えるならば、右辺の値を取り出す時間と新しい値を格納する時間の間に、他の スレッドが $a を変えてしまって、あなたの予期しない振る舞いをする 可能性があります。 Multiprocessor kernel threads are the final step in thread support. With multiprocessor kernel threads on a machine with multiple CPUs, the OS may schedule two or more threads to run simultaneously on different CPUs. マルチプロセッサカーネルスレッドは、スレッドのサポートにおける最終段階です。 一台のマシンが複数の CPU を持っているマルチプロセッサカーネルスレッドでは、 OS は別々の CPU 上で同時に一つ以上のスレッドを走らせるようにスケジュール 管理をします。 This can give a serious performance boost to your threaded program, since more than one thread will be executing at the same time. As a tradeoff, though, any of those nagging synchronization issues that might not have shown with basic kernel threads will appear with a vengeance. 一つ以上のスレッドが同時に実行するので、これによりスレッドプログラムは 飛躍的なパフォーマンスの向上を得ることができます。 しかし、引き換えに、基本的なカーネルスレッドでは現れなかったであろう イライラするような同期性の問題が一気に姿を現します。 In addition to the different levels of OS involvement in threads, different OSes (and different thread implementations for a particular OS) allocate CPU cycles to threads in different ways. スレッドを備える OS の違いというレベルに加えて、それぞれの OS は(そして それぞれのスレッド実装は)それぞれの方法でもって CPU サイクルをスレッドに 割り当てます。 Cooperative multitasking systems have running threads give up control if one of two things happen. If a thread calls a yield function, it gives up control. It also gives up control if the thread does something that would cause it to block, such as perform I/O. In a cooperative multitasking implementation, one thread can starve all the others for CPU time if it so chooses. 次の二つのうちの一つが起こる場合、協調的マルチタスクシステムは実行中の スレッドに制御を明け渡させます。 あるスレッドがyield関数を呼び出すと、制御を明け渡します。 また、スレッドがI/Oの実行などのブロックを引き起こすような何かを行う場合も、 制御を明け渡します。 協調的マルチタスクシステムの実装においては、そのように選択するならば、 一つのスレッドが他の全てのスレッドの CPU 時間を食い尽くすことができます。 Preemptive multitasking systems interrupt threads at regular intervals while the system decides which thread should run next. In a preemptive multitasking system, one thread usually won't monopolize the CPU. プリエンティブなマルチタスクシステムは、次にどのスレッドを実行するか 決めながら、一定の間隔でスレッドに割り込みを入れます。 プリエンティブなマルチタスクシステムにおいて、通常一つのスレッドが CPU を 独占することはありません。 On some systems, there can be cooperative and preemptive threads running simultaneously. (Threads running with realtime priorities often behave cooperatively, for example, while threads running at normal priorities behave preemptively.) いくつかのシステムでは、協調的スレッドとプリエンティブなスレッドを同時に 実行することができます(例えば、通常のプライオリティを持ったスレッドが プリエンディブに振舞うのに対して、リアルタイムのプライオリティを持った スレッドはしばしば協調的に振舞います)。 Most modern operating systems support preemptive multitasking nowadays. 今では、ほとんどの近代的なOSでプリエンティブなマルチタスクを サポートしています。 (パフォーマンスの考慮) The main thing to bear in mind when comparing Perl's ithreads to other threading models is the fact that for each new thread created, a complete copy of all the variables and data of the parent thread has to be taken. Thus, thread creation can be quite expensive, both in terms of memory usage and time spent in creation. The ideal way to reduce these costs is to have a relatively short number of long-lived threads, all created fairly early on -- before the base thread has accumulated too much data. Of course, this may not always be possible, so compromises have to be made. However, after a thread has been created, its performance and extra memory usage should be little different than ordinary code. Perl の iスレッド と他のスレッドモデルを比較する際に忘れてならないのが、 新しいスレッドはみな、親スレッドの変数とデータを全て完全にコピーして 引き渡されるという事実です。 そのため、メモリ使用量と実行時間の両方の点で、スレッドの生成は非常に 高くつきます。 このコストを減らす理想的な方法は、長生きなスレッドを比較的少なめに 持つことです。 このスレッドは全て、ベースとなるスレッドが非常に多くのデータを蓄積する前に、 適切に早い段階で生成されます。 もちろん、これはいつも可能というわけではないでしょうから、妥協も必要です。 しかし、スレッドが生成された後は、そのパフォーマンスと追加のメモリ使用量は、 普通のコードのそれとほとんど違いはありません。 Also note that under the current implementation, shared variables use a little more memory and are a little slower than ordinary variables. また、現在の実装下では、共有変数は通常の変数に比べて少し余計にメモリを 使用し、スピードも少し遅いことにも注意してください。 (プロセススコープの変更) Note that while threads themselves are separate execution threads and Perl data is thread-private unless explicitly shared, the threads can affect process-scope state, affecting all the threads. スレッドそれ自身は別々に実行され、Perl のデータは明示的に共有化しない限りは スレッド内でプライベートなものです; その一方、スレッドは全てのスレッドに影響を与えながら、プロセススコープの 状態に影響を与えてしまうことに注意してください。 The most common example of this is changing the current working directory using chdir(). One thread calls chdir(), and the working directory of all the threads changes. この最も一般的な例は chdir() を使ったときに現在作業中のディレクトリが 変更されてしまうことです。 一つのスレッドが chdir() を呼ぶと、全てのスレッドの作業ディレクトリが 変更されます。 Even more drastic example of a process-scope change is chroot(): the root directory of all the threads changes, and no thread can undo it (as opposed to chdir()). さらに劇的なプロセススコープの変更例は chroot() です。 全部のスレッドのルートディレクトリが変更されます。 スレッドはそれを元に戻すことはできません(chdir() の場合は可能です)。 Further examples of process-scope changes include umask() and changing uids and gids. さらなるプロセススコープ変化の例は、umask() および uid や gid の変更です。 Thinking of mixing fork() and threads? Please lie down and wait until the feeling passes. Be aware that the semantics of fork() vary between platforms. For example, some UNIX systems copy all the current threads into the child process, while others only copy the thread that called fork(). You have been warned! fork() とスレッドを混在させたらどうなるかって? そんな気分が失せるまで、横になって休んでいてください。 fork() の動作はプラットフォームによって異なることに注意してください。 例えば、UNIX システムには現状の全てのスレッドを子プロセスに コピーするものもありますが、fork() を呼び出したスレッドのみを コピーするものもあります。 あなたは警告されました! Similarly, mixing signals and threads may be problematic. Implementations are platform-dependent, and even the POSIX semantics may not be what you expect (and Perl doesn't even give you the full POSIX API). For example, there is no way to guarantee that a signal sent to a multi-threaded Perl application will get intercepted by any particular thread. (However, a recently added feature does provide the capability to send signals between threads. See threads/"THREAD SIGNALLING for more details.) 同じように、シグナルとスレッドを混ぜるのもするべきではありあません。 実装はプラットフォーム依存だし、POSIX のセマンティクスでさえ、あなたの 期待通りにはならないかもしれません (そして Perl はフルセットの POSIX API を提供することさえできません)。 例えば、マルチスレッド Perl アプリケーションに送られたシグナルが、 特定のスレッドによって受信されることを保証する方法はありません。 (しかし、最近追加された機能はスレッド間でシグナルを送る能力を提供します。 更なる詳細については threads/"THREAD SIGNALLING を参照してください。) (システムライブラリにおけるスレッドの安全性) Whether various library calls are thread-safe is outside the control of Perl. Calls often suffering from not being thread-safe include: localtime(), gmtime(), functions fetching user, group and network information (such as getgrent(), gethostent(), getnetent() and so on), readdir(), rand(), and srand() -- in general, calls that depend on some global external state. 様々なライブラリの関数呼び出しがスレッドにとって安全かどうかということは、 Perlのコントロールの埒外です。 しばしばスレッドセーフではないものに よって問題の生じる呼び出しには以下のようなものです: localtime(), gmtime(), (getgrent(), gethostent(), getnetent() などのような)ユーザー、 グループ、ネットワークの情報を取り出す関数、readdir(), rand(), srand() -- 一般的に言って、グローバルな外部状況に依存する 呼び出しが含まれます。 If the system Perl is compiled in has thread-safe variants of such calls, they will be used. Beyond that, Perl is at the mercy of the thread-safety or -unsafety of the calls. Please consult your C library call documentation. Perl がコンパイルされたシステムが、そういった呼び出しのスレッドセーフな バージョンを持っているなら、そちらが使われます。 それを超えると、Perl は呼び出しがスレッドセーフかどうかのなすがままに なります。 C ライブラリのドキュメントをよく吟味してください。 On some platforms the thread-safe library interfaces may fail if the result buffer is too small (for example the user group databases may be rather large, and the reentrant interfaces may have to carry around a full snapshot of those databases). Perl will start with a small buffer, but keep retrying and growing the result buffer until the result fits. If this limitless growing sounds bad for security or memory consumption reasons you can recompile Perl with PERL_REENTRANT_MAXSIZE defined to the maximum number of bytes you will allow. いくつかのプラットフォームでは、結果バッファが小さすぎる場合に スレッドセーフなライブラリのインターフェースが失敗を起こすかもしれません (例えば、ユーザーグループのデータベースがかなり大きく、リエントラントな インターフェースがこれらのデータベースの完全なスナップショットを もたらさなければならないような場合)。 Perl は小さなバッファでスタートします。 しかし結果が適合するまで結果バッファの確保を再試行し、大きくしようとします。 この無制限な成長がセキュリティやメモリ消費の理由から好ましくないもので あるなら、PERL_REENTRANT_MAXSIZE であなたの許す最大バイト数を定義して Perl を再コンパイルできます。 (おわりに) A complete thread tutorial could fill a book (and has, many times), but with what we've covered in this introduction, you should be well on your way to becoming a threaded Perl expert. 完全なスレッドのチュートリアルをつくると一冊の本になってしまいます。 しかしこの導入でカバーしてきたことを使って、あなたなりの方法で スレッド Perl のエキスパートになっていってください。 Annotated POD for threads: http:#/annocpan.org/?mode=search&field=Module&name=threads'}http://annocpan.org/?mode=search&field=Module&name=threads Lastest version of threads on CPAN: http:#/search.cpan.org/search?module=threads'}http://search.cpan.org/search?module=threads Annotated POD for threads::shared: http:#/annocpan.org/?mode=search&field=Module&name=threads%3A%3Ashared'}http://annocpan.org/?mode=search&field=Module&name=threads%3A%3Ashared Lastest version of threads::shared on CPAN: http:#/search.cpan.org/search?module=threads%3A%3Ashared'}http://search.cpan.org/search?module=threads%3A%3Ashared Perl threads mailing list: http:#/lists.cpan.org/showlist.cgi?name=iThreads'}http://lists.cpan.org/showlist.cgi?name=iThreads (参考文献) Here's a short bibliography courtesy of J?gen Christoffel: 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). (OS関連のリファレンス) 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/'}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'}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, J?gen 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<gt> Slightly modified by Arthur Bergman to fit the new thread model/module. 新しいスレッドモデル・モジュールに対応するように Arthur Bergman によって 若干の修正がなされました。 Reworked slightly by J?g Walter <jwalt@cpan.org<gt> to be more concise about thread-safety of Perl code. Perl コードのスレッドセーフティについてより簡明になるよう Jorg Walter <jwalt@cpan.org<gt> によって改訂されました。 Rearranged slightly by Elizabeth Mattijsen <liz@dijkmat.nl<gt> to put less emphasis on yield(). Elizabeth Mattijsen <liz@dijkmat.nl<gt> によって、yield() を以前より 強調しないよう若干アレンジされました。 (著作権) 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.