argra****@users*****
argra****@users*****
2008年 5月 31日 (土) 02:34:53 JST
Index: docs/perl/5.10.0/perlthrtut.pod
diff -u /dev/null docs/perl/5.10.0/perlthrtut.pod:1.1
--- /dev/null Sat May 31 02:34:53 2008
+++ docs/perl/5.10.0/perlthrtut.pod Sat May 31 02:34:52 2008
@@ -0,0 +1,2597 @@
+
+=encoding euc-jp
+
+=head1 NAME
+
+=begin original
+
+perlthrtut - Tutorial on threads in Perl
+
+=end original
+
+perlthrtut - Perl におけるスレッドのチュートリアル
+
+=head1 DESCRIPTION
+
+=begin original
+
+This tutorial describes the use of Perl interpreter threads (sometimes
+referred to as I<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 I<ithreads>
+uses the L<threads> class.
+
+=end original
+
+このチュートリアルは、Perl 5.6.0 において導入された新しい Perl インタプリタ
+スレッド(B<iスレッド>(B<ithreads>)と呼ばれる)の特徴を説明するものです。
+このモデルにおいては、それぞれのスレッドはそれ自身の Perl インタプリタで
+実行され、スレッド間で共有するデータも明示的でなければなりません。
+The user-level interface for I<ithreads>
+uses the L<threads> class.
+(TBT)
+
+=begin original
+
+B<NOTE>: There was another older Perl threading flavor called the 5.005 model
+that used the L<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.
+
+=end original
+
+B<注意>: Perl のバージョン 5.005 には、5.005 モデルと呼ばれる
+L<Threads> クラスを使う別の古いスレッド機能がありました。
+この古いモデルは問題があることが知られていて、非推奨で、バージョン5.10 で
+削除されました。
+できるだけ速やかに既存の5.005スレッドを新しいものに移行することが
+強く勧められます。
+
+=begin original
+
+You can see which (or neither) threading flavour you have by
+running C<perl -V> and looking at the C<Platform> section.
+If you have C<useithreads=define> you have ithreads, if you
+have C<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.
+
+=end original
+
+C<perl -V> で C<Platform> セクションを見れば、どちらのスレッド機能があるのか
+(あるいは無いのか)を知ることができます。
+もし C<useithreads=define> となって
+いればiスレッドをサポートしているし、C<use5005threads=define> とあれば
+5.005 スレッドです。
+両方とも出ない場合、あなたの Perl はスレッドをサポートしていません。
+両方ある場合は問題があります。
+
+=begin original
+
+The L<threads> and L<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.
+
+=end original
+
+The L<threads> and L<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.
+(TBT)
+
+=head1 What Is A Thread Anyway?
+
+(スレッドとは何か?)
+
+=begin original
+
+A thread is a flow of control through a program with a single
+execution point.
+
+=end original
+
+スレッドとはプログラム内を通じて一つの実行点を持った制御のフローです。
+
+=begin original
+
+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.
+
+=end original
+
+こういうと非常に多くの点でプロセスに似ているように聞こえるでしょう。
+確かにその通りで、スレッドはひとつのプロセスにおける細かい部分の一つです。
+全てのプロセスは少なくとも一つのスレッドを持ちます。
+そしてこれまでは、Perl を走らせるプロセスは全てただ一つのスレッドを
+持っていました。
+しかし 5.8 になって、余分にスレッドをつくることができるようになりました。
+それがいつどのように、いかにしてなされるのかをこれから示していきましょう。
+
+=head1 Threaded Program Models
+
+(スレッドプログラムのモデル)
+
+=begin original
+
+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.
+
+=end original
+
+スレッドプログラムを構築する 3 つの基本的な方法があります。
+どのモデルを選ぶかはプログラムに何をやらせるかに依存します。
+多くの重要なスレッドプログラムにおいては、プログラム中の異なる部分に
+異なるモデルを選択する必要があるでしょう。
+
+=head2 Boss/Worker
+
+(ボス/ワーカー)
+
+=begin original
+
+The boss/worker model usually has one I<boss> thread and one or more
+I<worker> threads. The boss thread gathers or generates tasks that need
+to be done, then parcels those tasks out to the appropriate worker
+thread.
+
+=end original
+
+ボス・ワーカーモデルでは通常、一つの I<ボス> スレッドと、一つ以上の
+I<ワーカー> スレッドを持ります。
+ボススレッドは必要とされるタスクを集約ないし生成します。
+それからそれらのタスクを適したワーカースレッドに分配します。
+
+=begin original
+
+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.
+
+=end original
+
+このモデルは GUI とサーバプログラムに共通です。
+そこではメインスレッドがイベント発生を待ち、処理のために適した
+ワーカースレッドにイベントを渡します。
+ひとたびイベントが渡されると、ボススレッドは次のイベントのために待機します。
+
+=begin original
+
+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.
+
+=end original
+
+ボススレッドは相対的に仕事量は少ないです。
+タスクは他の方法を使ったものより必ずしも早く実行されるわけではないですが、
+最もユーザーレスポンスタイムが良くなる傾向にあります。
+
+=head2 Work Crew
+
+(仕事仲間)
+
+=begin original
+
+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.
+
+=end original
+
+仕事仲間モデルでは、データの様々な部分に対し本質的に同じ作業を行う
+いくつかのスレッドがつくられます。
+これは、プロセッサの巨大な配列が多くのデータ片に対して全く同じことを行う
+古典的な並列処理やベクトル処理とそっくりです。
+
+=begin original
+
+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.
+
+=end original
+
+プログラムを走らせているシステムが、異なるプロセスをまたいでマルチスレッドを
+分配するような場合、このモデルは殊のほか便利です。
+また、レイトレースやレンダリングエンジンといった、個々のスレッドが暫定的な
+結果をユーザに対し視覚的にフィードバックするような場合にも便利でしょう。
+
+=head2 Pipeline
+
+(パイプライン)
+
+=begin original
+
+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.
+
+=end original
+
+パイプラインモデルはあるタスクを何段階の処理の連続へと分けます。
+そして一つのステップの結果を次の処理を行うスレッドへと渡します。
+それぞれのスレッドはデータの各部分に対し一つのことを行い、結果を次の
+スレッドへ渡します。
+
+=begin original
+
+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.
+
+=end original
+
+しばしば他の文脈でも同じぐらいの意味があるますが、二つ以上のスレッドが
+並列に処理を行うようにあなたがマルチプロセッサを持っているならば、この
+モデルは最も意味があります。
+それは、あるパイプラインの一部が進行中の間に、他のパイプラインの一部が
+(例えば I/O やシステムコールを)ブロックするのを
+許可するのと同様、個々のタスクを小さく単純なものに留める傾向があります。
+もし違うプロセッサ上で別々のパイプラインを走らせるなら、それぞれの
+プロセッサのキャッシュを利用するという利益を得ることができるでしょう。
+
+=begin original
+
+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.)
+
+=end original
+
+このモデルはまた、自分自身を呼び出すサブルーチンを持つよりも、別の
+スレッドを生み出すような再起的プログラムの形態に利用しやすいです。
+素数やフィボナッチ数列ジェネレーターは、どちらもこのパイプラインモデルの
+形態にうまく位置付けられます(素数ジェネレーターの例は後で登場します)。
+
+=head1 What kind of threads are Perl threads?
+
+(Perlスレッドはどんなスレッドか?)
+
+=begin original
+
+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 I<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.
+
+=end original
+
+もしもあなたが他のスレッドの実装を経験したことがあるなら、事態は全く
+あなたの予想とは違うことがわかるでしょう。
+Perl スレッドを扱う時には、あらゆる X に対して
+I<Perl スレッドは X スレッドではない> ということを忘れてはなりません。
+それらは POSIX スレッドではありません。
+DecThread でもなければ Java のグリーンスレッドでないし、
+Win32 スレッドでもありません。
+類似点はあるし、広義の概念は同じです。
+だが実装の詳細を調べだしたら、あなたは失望するか混乱するかの
+どちらかになるでしょう。
+あるいはその両方かもしれません。
+
+=begin original
+
+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.
+
+=end original
+
+これは、これまで登場してきたあらゆるスレッドと Perl スレッドが完全に
+異なるということを言っているのではありません。
+Perl スレッドは他のモデル、特に POSIX スレッドに多くを負っています。
+ですが、Perl が C ではないように、Perl スレッドは POSIX スレッドでは
+ありません。
+だから、もしあなたがミューテックスやスレッドプライオリティを
+期待しているならば、ちょっと立ち戻って、自分が何をしたいのか、
+Perl はいかにしてそれが可能なのかを考える時です。
+
+=begin original
+
+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 C<sleep()>, Perl usually will, as well.
+
+=end original
+
+しかし、あなたのオペレーティングシステムのスレッドが許可しない限り、
+Perl スレッドが魔法のように何かを行うことはできないことを覚えておきましょう。
+だからもし、システムが C<sleep()> でプロセスを丸ごとブロックするなら、通常
+Perl も同様にそうするでしょう。
+
+=begin original
+
+B<Perl Threads Are Different.>
+
+=end original
+
+B<Perl スレッドは別ものです>。
+
+=head1 Thread-Safe Modules
+
+(スレッドセーフなモジュール)
+
+=begin original
+
+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.
+
+=end original
+
+スレッドの追加は Perl の内部的な実態を変化させてしまいました。
+これには XS モジュールや外部ライブラリーを書いている人々も含まれます。
+しかしながら、デフォルトではスレッド間で Perl のデータは共有されません。
+そのため Perl モジュールはスレッドセーフであるという機会に恵まれていますし、
+あるいは容易にスレッドセーフにすることができます。
+スレッドセーフの札がついていないモジュールは製品版の前にテストされるか
+コードレビューを受けるべきです。
+
+=begin original
+
+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.
+
+=end original
+
+あなたが使おうとしているモジュールの全てがスレッドセーフというわけでは
+ないですし、モジュールのドキュメントに安全であると書かれていないならば、
+常に安全ではないものと仮定するべきです。
+このことは、コアの一部として配布されているモジュールにもあてはまります。
+スレッドは比較的新しい機構なので、標準モジュールの中にさえスレッドセーフで
+ないものがあります。
+
+=begin original
+
+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.
+
+=end original
+
+仮にあるモジュールがスレッドセーフであったとしても、そのモジュールが
+うまく働くように最適化されているということを意味するわけではありません。
+できるだけスレッド環境でパフォーマンスが向上するように、スレッド化された
+Perl の新機構を利用するようモジュールを書き直したほうがよいです。
+
+=begin original
+
+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 L</"Basic semaphores">.
+
+=end original
+
+もしもなんらかの理由でスレッドセーフではないモジュールを使っているならば、
+ただ一つのスレッドからそれを使うことによって防ぐことができます。
+そのようなモジュールにアクセスするマルチスレッドが必要ならば、セマフォや
+アクセスを制御するためのプログラミング原則を用いることができます。
+セマフォは L</"Basic semaphores"> でカバーしています。
+
+=begin original
+
+See also L</"Thread-Safety of System Libraries">.
+
+=end original
+
+L</"Thread-Safety of System Libraries"> も参照してください。
+
+=head1 Thread Basics
+
+(スレッドの基本)
+
+=begin original
+
+The L<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 L<threads> module that
+make threaded programming easier.
+
+=end original
+
+L<threads> モジュールは、あなたがスレッドプログラムを書くのに必要と
+なる基本的な機能を提供します。
+次からのセクションでは、スレッドプログラムを作るのに必要なことを示しながら
+基礎的なところをカバーしていきましょう。
+その後で、スレッドプログラミングを容易にしてくれる L<threads> モジュールの
+機能をみることにします。
+
+=head2 Basic Thread Support
+
+(基本的なスレッドのサポート)
+
+=begin original
+
+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.
+
+=end original
+
+スレッドのサポートは、あなたのプログラムがコンパイルされる時ではなく、
+Perl のコンパイル時のオプションによります。
+つまり、Perl をビルトするときに、サポートのオン・オフを行います。
+スレッドがサポートされるように Perl がコンパイルされていないなら、スレッドを
+使おうとしても失敗するでしょう。
+
+=begin original
+
+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:
+
+=end original
+
+スレッドが使用可能かどうかをチェックするために Config モジュールを
+利用できます。
+あなたのプログラムがスレッド無しには実行できないなら、次のように記述できます:
+
+ use Config;
+ $Config{useithreads} or die('Recompile Perl with threads to run this program.');
+
+=begin original
+
+A possibly-threaded program using a possibly-threaded module might
+have code like this:
+
+=end original
+
+スレッドを利用するかもしれないモジュールを使うプログラムには、
+次のようなコードをつけておくとよいでしょう:
+
+ use Config;
+ use MyMod;
+
+ BEGIN {
+ if ($Config{useithreads}) {
+ # We have threads
+ require MyMod_threaded;
+ import MyMod_threaded;
+ } else {
+ require MyMod_unthreaded;
+ import MyMod_unthreaded;
+ }
+ }
+
+=begin original
+
+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 C<MyMod_threaded> is, and it's
+only imported if we're running on a threaded Perl.
+
+=end original
+
+スレッドの有無に関わらず走るようなコードは通常、非常に繁雑なものになるので、
+スレッド専用のコードはモジュールとして分離しておくのがベストです。
+上の例では、C<MyMod_threaded> がそれで、スレッド可能な Perl 上で走るときだけ
+インポートされます。
+
+=head2 A Note about the Examples
+
+(例に対する注意)
+
+=begin original
+
+In a real situation, care should be taken that all threads are finished
+executing before the program exits. That care has B<not> been taken in these
+examples in the interest of simplicity. Running these examples I<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.
+
+=end original
+
+実際の状況では、プログラムが終了する前に全てのスレッドが実行を終えることに
+注意を払わなければなりません。
+簡明さを重視しているのでここで取り上げる例においては、そのような注意を
+払って B<いません>。
+これらの例を I<そのまま> 実行すると、プログラムが終了する際にまだスレッドが
+走っているという理由で常にエラーメッセージが出力されるでしょう。
+この警告は気にしなくて良いです。
+
+=head2 Creating Threads
+
+(スレッドの生成)
+
+=begin original
+
+The L<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; C<use threads;> imports all the pieces you need to create basic
+threads.
+
+=end original
+
+L<threads> モジュールは新たなスレッドを生成するのに必要なツールを提供します。
+他のモジュール同様、それを使いたいと Perl に伝える必要があります;
+C<use threads;> によって基本的なスレッドを生み出すのに必要な全ての部品が
+インポートされます。
+
+=begin original
+
+The simplest, most straightforward way to create a thread is with C<create()>:
+
+=end original
+
+最も単純で直接的なスレッドの生成方法は C<create()> によるものです:
+
+ use threads;
+
+ my $thr = threads->create(\&sub1);
+
+ sub sub1 {
+ print("In the thread\n");
+ }
+
+=begin original
+
+The C<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.
+
+=end original
+
+C<create()> メソッドはサブルーチンへのリファレンスを引数にとって新しい
+スレッドを生成します。
+このスレッドはリファレンスされたサブルーチンの実行を開始します。
+このとき制御はサブルーチンと呼び出し側との両方に渡されます。
+
+=begin original
+
+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 C<threads-E<gt>create()> call, like this:
+
+=end original
+
+もし必要ならばスレッド開始時のサブルーチンにパラメータを渡せます。
+以下のように、C<threads-E<gt>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");
+ }
+
+=begin original
+
+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.
+
+=end original
+
+最後の例はスレッドのもう一つの特徴を示しています。
+同じサブルーチンを利用するいくつものスレッドを生成することができます。
+それぞれのスレッドは同一のサブルーチンを実行するが、それぞれのスレッドは
+それぞれ別々の環境と引数をとることができます。
+
+=begin original
+
+C<new()> is a synonym for C<create()>.
+
+=end original
+
+C<new()> は C<create()> の言い換えです。
+
+=head2 Waiting For A Thread To Exit
+
+(スレッド終了の待機)
+
+=begin original
+
+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 C<join()> method:
+
+=end original
+
+スレッドはサブルーチンでもあるので、値を返せます。
+スレッドが終了して何らかの戻り値を得るのを待つために、C<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); }
+
+=begin original
+
+In the example above, the C<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, C<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 C<detach()> method
+instead, as described next.
+
+=end original
+
+上の例では、スレッドが終了するとすぐに C<join()> メソッドが戻ります。
+スレッドの終了と、返すべき値を収集するための待機に加えて、C<join()> は
+スレッドが必要とする OS レベルのクリーンナップを実行します。
+このクリーンナップは重要です; 特に長時間にわたって実行されるプログラムが
+大量のスレッドを生成する場合には。
+もしも戻り値を必要とせず、スレッドの終了を待つ必要もなければ、かわりに
+次に説明する C<detach()> メソッドを呼び出すべきです。
+
+=begin original
+
+NOTE: In the example above, the thread returns a list, thus necessitating
+that the thread creation call be made in list context (i.e., C<my ($thr)>).
+See L<threads/"$thr->join()"> and L<threads/"THREAD CONTEXT"> for more
+details on thread context and return values.
+
+=end original
+
+NOTE: In the example above, the thread returns a list, thus necessitating
+that the thread creation call be made in list context (i.e., C<my ($thr)>).
+See L<threads/"$thr->join()"> and L<threads/"THREAD CONTEXT"> for more
+details on thread context and return values.
+(TBT)
+
+=head2 Ignoring A Thread
+
+(スレッドを無視する)
+
+=begin original
+
+C<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.
+
+=end original
+
+C<join()> は三つのことを行います。
+スレッド終了の待機、その後のクリーンナップ、そしてスレッドが生み出したで
+あろうデータを返すことです。
+しかし、スレッドの返す値に関心がなく、いつスレッドが終了するのかを本当に
+気にしない場合には?
+必要なのは仕事がなされた後にスレッドがクリーンナップされることです。
+
+=begin original
+
+In this case, you use the C<detach()> method. Once a thread is detached,
+it'll run until it's finished; then Perl will clean up after it
+automatically.
+
+=end original
+
+このような場合、C<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);
+ }
+ }
+
+=begin original
+
+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.
+
+=end original
+
+一度あるスレッドが detach されたら、そのスレッドは join されないでしょう。
+(join のために待機しても)スレッドが生成したであろうデータは失われます。
+
+=begin original
+
+C<detach()> can also be called as a class method to allow a thread to
+detach itself:
+
+=end original
+
+C<detach()> can also be called as a class method to allow a thread to
+detach itself:
+(TBT)
+
+ use threads;
+
+ my $thr = threads->create(\&sub1);
+
+ sub sub1 {
+ threads->detach();
+ # Do more work
+ }
+
+=head2 Process and Thread Termination
+
+=begin original
+
+With threads one must be careful to make sure they all have a chance to
+run to completion, assuming that is what you want.
+
+=end original
+
+With threads one must be careful to make sure they all have a chance to
+run to completion, assuming that is what you want.
+(TBT)
+
+=begin original
+
+An action that terminates a process will terminate I<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.
+
+=end original
+
+An action that terminates a process will terminate I<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.
+(TBT)
+
+=begin original
+
+As an example of this case, this code prints the message
+"Perl exited with active threads: 2 running and unjoined":
+
+=end original
+
+As an example of this case, this code prints the message
+"Perl exited with active threads: 2 running and unjoined":
+(TBT)
+
+ use threads;
+ my $thr1 = threads->new(\&thrsub, "test1");
+ my $thr2 = threads->new(\&thrsub, "test2");
+ sub thrsub {
+ my ($message) = @_;
+ sleep 1;
+ print "thread $message\n";
+ }
+
+=begin original
+
+But when the following lines are added at the end:
+
+=end original
+
+But when the following lines are added at the end:
+(TBT)
+
+ $thr1->join;
+ $thr2->join;
+
+=begin original
+
+it prints two lines of output, a perhaps more useful outcome.
+
+=end original
+
+it prints two lines of output, a perhaps more useful outcome.
+(TBT)
+
+=head1 Threads And Data
+
+(スレッドとデータ)
+
+=begin original
+
+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.
+
+=end original
+
+これでスレッドの基本部分については見終わりました。
+次の話題はデータです。
+スレッドを扱うと、非スレッドプログラムが決して心配することのなかった
+データアクセスに対する二つの複雑さを導入することになります。
+
+=head2 Shared And Unshared Data
+
+(共有データと非共有データ)
+
+=begin original
+
+The biggest difference between Perl I<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.
+
+=end original
+
+I<iスレッド> と古い 5.005 型スレッドの間の(もっといえば、そこから外れる
+多くのスレッドシステムにとっての)最大の違いは、デフォルトではデータが
+共有されないという点です。
+新しい Perl スレッドが生成されるとき、現在のスレッドに関連する全てのデータは
+新しいスレッドにコピーされます。
+続いてそのデータは新しいスレッド内でプライベートなものとなります!
+これは UNIX のプロセスが fork するときに起きることと似ています。
+ただしこの場合、実際の fork ではメモリ上での置き換えが起こるのに対して、この
+データは同一プロセッサ内の違うメモリ部分にコピーされるだけであるという点が
+除かれます。
+
+=begin original
+
+To make use of threading, however, one usually wants the threads to share
+at least some data between themselves. This is done with the
+L<threads::shared> module and the C<:shared> attribute:
+
+=end original
+
+しかしスレッド機能を利用するならば、通常はスレッド間で少なくともいくつかの
+データを共有したいものです。
+これは L<threads::shared> モジュールと C<: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
+
+=begin original
+
+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:
+
+=end original
+
+共有化された配列の場合は、配列の要素全てが共有化されます。
+共有化されたハッシュの場合、全てのキーと値が共有されます。
+共有化された配列やハッシュの要素に代入するものに対しては制限があります:
+単純な値や共有化された変数へのリファレンスは可能です。
+これは、プライベート変数が図らずも共有化されることがないからです。
+不正な代入はスレッドを殺してしまうでしょう。
+例えば:
+
+ use threads;
+ use threads::shared;
+
+ my $var = 1;
+ my $svar :shared = 2;
+ my %hash :shared;
+
+ ... create some threads ...
+
+=begin original
+
+ $hash{a} = 1; # All threads see exists($hash{a}) and $hash{a} == 1
+ $hash{a} = $var; # okay - copy-by-value: same effect as previous
+ $hash{a} = $svar; # okay - copy-by-value: same effect as previous
+ $hash{a} = \$svar; # okay - a reference to a shared variable
+ $hash{a} = \$var; # This will die
+ delete($hash{a}); # okay - all threads will see !exists($hash{a})
+
+=end original
+
+ $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})
+
+=begin original
+
+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.
+
+=end original
+
+共有変数が、複数のスレッドが同時にその変数に変更を加えようとしても、
+変数の内部状態は破壊されないことを保証していることに注意してください。
+しかし次のセクションで説明するように、ここを超えてしまうと保証は
+なくなってしまいます。
+
+=head2 Thread Pitfalls: Races
+
+(スレッドの落とし穴: 競合)
+
+=begin original
+
+While threads bring a new set of useful tools, they also bring a
+number of pitfalls. One pitfall is the race condition:
+
+=end original
+
+スレッドは新しい便利なツールを一揃いもたらしてくれる一方で、たくさんの
+落とし穴ももたらします。
+その一つは競合条件です:
+
+ 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; }
+
+=begin original
+
+What do you think C<$a> will be? The answer, unfortunately, is I<it
+depends>. Both C<sub1()> and C<sub2()> access the global variable C<$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,
+C<$a> can be 2 or 3.
+
+=end original
+
+C<$a> はどうなるでしょうか?
+残念ながら、その答えは I<場合によりけり> です。
+C<sub1()> と C<sub2()> はどちらも一度だけ読み込み、一度だけ書き込むために
+グローバル変数 C<$a> にアクセスします。
+あなたの使っているスレッド実装のスケジューリングアルゴリズムから月の
+満ち欠けまでの種々の要因によって、C<$a> は 2 にも 3 にもなりえます。
+
+=begin original
+
+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:
+
+=end original
+
+競合条件は共有データに対して非同期なアクセスを行うことによって生じます。
+明示的に同期をとらない限り、アクセスして更新するまでの間に
+共有データに何も起こらないことを確実にする方法はありません。
+こんな単純なコードでさえ、エラーの可能性があります:
+
+ 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;
+
+=begin original
+
+Two threads both access C<$a>. Each thread can potentially be interrupted
+at any point, or be executed in any order. At the end, C<$a> could be 3
+or 4, and both C<$b> and C<$c> could be 2 or 3.
+
+=end original
+
+二つのスレッドが C<$a> にアクセスします。
+それぞれのスレッドはいずれかの時点で割り込まれたり、いずれかの順番で
+実行される可能性があります。
+結局、C<$a> は 3 か 4 に、C<$b> と C<$c> はともに 2 か 3 になるでしょう。
+
+=begin original
+
+Even C<$a += 5> or C<$a++> are not guaranteed to be atomic.
+
+=end original
+
+C<$a += 5> や C<$a++> でさえ、アトミックな演算であることを保証されません。
+
+=begin original
+
+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.
+
+=end original
+
+他のスレッドによってアクセスされる可能性のあるデータやリソースにあなたの
+プログラムがアクセスするときはいつでも、整合的なアクセスのための手順を
+踏まなければなりません。
+さもなければデータの一貫性が崩れたり、競合条件に陥るリスクを
+負うことになります。
+
+=head1 Synchronization and control
+
+(同期と制御)
+
+=begin original
+
+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 C<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.
+
+=end original
+
+競合条件やそれに似た状態を回避するために、スレッドとデータとの間の相互作用を
+調整する多くのメカニズムを Perl は提供します。
+それらのうちのあるものは、C<pthreads> のようなスレッドライブラリにおいて
+使われる共通のテクニックに似た設計がなされています。
+またあるものは Perl に特化しています。
+しばしば標準的なテクニックというものはぎこちないもので、正しく扱うには
+難しいです。
+可能なところでは通常、キューのような Perl 的テクニックはより簡単で、難しい
+仕事のうちのあるものを取り除いてくれます。
+
+=head2 Controlling access: lock()
+
+(アクセス制御：lock())
+
+=begin original
+
+The C<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
+C<lock()> function. Using C<lock()> is straightforward: This example has
+several threads doing some calculations in parallel, and occasionally
+updating a running total:
+
+=end original
+
+C<lock()> 関数は共有変数を引数にとり、それにロックをかけます。
+ロックを保持するスレッドによって変数のロックが解除されるまで、他のスレッドは
+ロックをかけることができません。
+ロックしているスレッドが C<lock()> 関数の呼び出しを含むブロックの外に出ると
+ロックは自動的に解除されます。
+C<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");
+
+=begin original
+
+C<lock()> blocks the thread until the variable being locked is
+available. When C<lock()> returns, your thread can be sure that no other
+thread can lock that variable until the block containing the
+lock exits.
+
+=end original
+
+ロックされている変数が利用可能になるまで、C<lock()> はそのスレッドを
+ブロックします。
+C<lock()> が戻ってくると、そのロックが存在しているブロックの外に出ない限り、
+他のスレッドがその変数をロックできないことが確実になります。
+
+=begin original
+
+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 C<flock()> gives you.
+
+=end original
+
+ロックは問題の変数にアクセスするのを阻止するのではなくて、ロックの試みを
+阻止するということに注意することが重要です。
+これは Perl の長年にわたる作法どおりのプログラミングの伝統と、flock() が
+提供する勧告ロックとに調和するものです。
+
+=begin original
+
+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.
+
+=end original
+
+スカラー変数同様、配列やハッシュにもロックをかけるかもしれません。
+しかし、配列へのロックは、配列の要素に対する二次的なロックを
+ブロックするのではなく、配列そのものへのロックの試みをブロックします。
+
+=begin original
+
+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
+C<lock()> on the variable goes out of scope. For example:
+
+=end original
+
+ロックは再帰的、つまりスレッドはある変数に対し何度もロックをかけて大丈夫です。
+一番外側の C<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
+
+=begin original
+
+Note that there is no C<unlock()> function - the only way to unlock a
+variable is to allow it to go out of scope.
+
+=end original
+
+C<unlock()> 関数は無いことに注意してください。
+変数のロックを解除する方法はスコープを抜けさせることだけです。
+
+=begin original
+
+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.
+
+=end original
+
+ロックされている変数内に保持されているデータをガードするか、あるいは
+コードのセクションのようなものを守るために、ロックは用いられます。
+後者の場合、問題の変数は役に立つデータを持たず、ロックの目的のためにだけ
+存在します。
+この点からすると、その変数は伝統的なスレッドライブラリにおける
+ミューテックスや基本的なセマフォのような振る舞いをするといえます。
+
+=head2 A Thread Pitfall: Deadlocks
+
+(スレッドの落とし穴: デッドロック)
+
+=begin original
+
+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:
+
+=end original
+
+ロックはデータに同期アクセスするための便利なツールです。
+適切に使えば安全な共有データへの鍵となります。
+残念なことに、ロックには危険が伴います。
+特に複数のロックが関わるとそうなります。
+次のコードを考えてみましょう:
+
+ 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);
+ });
+
+=begin original
+
+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.
+
+=end original
+
+このプログラムは恐らくあなたが kill するまで固まってしまうでしょう。
+ハングさせないための唯一の方法は、どちらかのスレッドが先に両方のロックを
+獲得することです。
+ハングを保証する方法はもっと複雑ですが、原理はこれと同じです。
+
+=begin original
+
+The first thread will grab a lock on C<$a>, then, after a pause during which
+the second thread has probably had time to do some work, try to grab a
+lock on C<$b>. Meanwhile, the second thread grabs a lock on C<$b>, then later
+tries to grab a lock on C<$a>. The second lock attempt for both threads will
+block, each waiting for the other to release its lock.
+
+=end original
+
+最初のスレッドが C<$a> のロックを手にします。
+それから二つ目のスレッドが何かやっている間に一時停止した後、C<$b> への
+ロックを手に入れようと試みます。
+ところが、その二つ目のスレッドは C<$b> へのロックを手にします。
+そしてその後 C<$a> のロックを手に入れようとします。
+それぞれのスレッドが、他方のスレッドのロックが開放されるの待つため、
+二番目のロックへの試みはブロックしてしまいます。
+
+=begin original
+
+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.
+
+=end original
+
+この状態をデッドロックと言います。
+二つ以上のスレッドが他スレッドの所有するリソースをロックしようと
+試みるときにはいつでも生じます。
+他のスレッドがリソースへのロックを開放するのを待って、互いにスレッドが
+ブロックします。
+しかし、リソースを持っているスレッドが自分自身のロックの開放を待つ場合は
+生じません。
+
+=begin original
+
+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 C<$a>, C<$b>, and C<$c>, always lock
+C<$a> before C<$b>, and C<$b> before C<$c>. It's also best to hold on to locks for
+as short a period of time to minimize the risks of deadlock.
+
+=end original
+
+この種の問題を扱う方法はたくさんあります。
+最もよい方法は、常に全てのスレッドが正確に同じ順番でロックを獲得するように
+することです。
+例えば、C<$a>、C<$b>、C<$c>をロックするなら、いつでも C<$b> の前に C<$a> を、
+そして C<$c> の前に C<$b> をロックするようにします。
+デッドロックの危険を最小にするために、短い時間だけロックを保持するのも良い手です。
+
+=begin original
+
+The other synchronization primitives described below can suffer from
+similar problems.
+
+=end original
+
+下記で説明するような他のプリミティブな同期も同様な問題を抱える可能性があります。
+
+=head2 Queues: Passing Data Around
+
+(キュー: データの受け渡し)
+
+=begin original
+
+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:
+
+=end original
+
+キューとは、一方の端にデータを入れ、他方から取り出すことによって、
+同期の問題を心配しなくてすむ、特別なスレッドセーフオブジェクトです。
+これらは非常に素朴で、以下のようなものです:
+
+ 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();
+
+=begin original
+
+You create the queue with C<Thread::Queue-E<gt>new()>. Then you can
+add lists of scalars onto the end with C<enqueue()>, and pop scalars off
+the front of it with C<dequeue()>. A queue has no fixed size, and can grow
+as needed to hold everything pushed on to it.
+
+=end original
+
+C<Thread::Queue-E<gt>new()> でキューを生成します。
+それから C<enqueue()> を使ってキューの
+最後にスカラーのリストを追加します。
+そして C<dequeue()> でキューの前方からスカラーを取り出します。
+キューのサイズは固定していません。
+キューの中に押し込められたものを保持する必要に応じてサイズは成長します。
+
+=begin original
+
+If a queue is empty, C<dequeue()> blocks until another thread enqueues
+something. This makes queues ideal for event loops and other
+communications between threads.
+
+=end original
+
+もしキューが空っぽの場合、他のスレッドが何かをキューの中に入れるまで、
+C<dequeue()> はブロックします。
+そのため、イベントループやスレッド間でのコミュニケーションにとって、
+キューは理想的です。
+
+=head2 Semaphores: Synchronizing Data Access
+
+(セマフォ：データアクセスの同期)
+
+=begin original
+
+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 I<lock> at any one time.
+
+=end original
+
+セマフォは包括的なロックメカニズムの一種です。
+最も基本となる形態では、
+セマフォはデータを持つことはできないし、明示的にロック解除されなければ
+ならないことを除くと、ロック可能なスカラーそっくりに振る舞います。
+発展的な形態においては、一種のカウンターのように動作し、いつでも複数の
+スレッドが I<ロック> を持つことを可能にします。
+
+=head2 Basic semaphores
+
+(ベーシックなセマフォ)
+
+=begin original
+
+Semaphores have two methods, C<down()> and C<up()>: C<down()> decrements the resource
+count, while C<up()> increments it. Calls to C<down()> will block if the
+semaphore's current count would decrement below zero. This program
+gives a quick demonstration:
+
+=end original
+
+セマフォは二つのメソッド、C<down()> と C<up()> を持ちます。
+C<down()> はリソースのカウントを減少させ、C<up()> の方は増加させます。
+セマフォの現在のカウントが 0 を下回るようなら C<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();
+
+=begin original
+
+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.
+
+=end original
+
+このサブルーチンに対する三つの呼び出しは同時に作用します。
+しかし一度に一つのスレッドだけが、グローバル変数にアクセスすることを
+セマフォが保証します。
+
+=head2 Advanced Semaphores
+
+(高度なセマフォ)
+
+=begin original
+
+By default, semaphores behave like locks, letting only one thread
+C<down()> them at a time. However, there are other uses for semaphores.
+
+=end original
+
+デフォルトでは、セマフォはロックのように振舞います。
+一度にただ一つのスレッドだけが C<down()> できます。
+しかし、セマフォには別の使い方があります。
+
+=begin original
+
+Each semaphore has a counter attached to it. By default, semaphores are
+created with the counter set to one, C<down()> decrements the counter by
+one, and C<up()> increments by one. However, we can override any or all
+of these defaults simply by passing in different values:
+
+=end original
+
+それぞれのセマフォは、関連付けられたカウンタを持ちます。
+デフォルトでセマフォは生成時、カウンタに 1 がセットされます。
+C<down()> はカウンタから 1 を引き、C<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();
+
+=begin original
+
+If C<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 C<up()> or C<down()> always changes the
+counter by at least one, and so C<< $semaphore->down(0) >> is the same as
+C<< $semaphore->down(1) >>.
+
+=end original
+
+もしも C<down()> がカウンタを 0 より小さい値に下げようとするなら、
+カウンタが十分な大きさになるまでブロックします。
+セマフォはカウンタの値を 0 にして生成することができる一方、C<up()> や
+C<down()> は常に、少なくとも 1 の変化をカウンタに対して行うことに
+注意してください。
+だから、C<< $semaphore->down(0) >> は C<< $semaphore->down(1) >> と同じです。
+
+=begin original
+
+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.
+
+=end original
+
+もちろん、問題はどうしてこんなことをするのかということです。
+なぜセマフォを 1 ではなくて、0 から始めるように生成するのでしょうか?
+あるいは、なぜ 1 より大きい値で増減を行うのでしょうか？
+その答えはリソースの利用可能性です。
+あなたがアクセス管理をしたいリソースの多くは、同時に一つを超える数の
+スレッドによって安全に利用されます。
+
+=begin original
+
+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.
+
+=end original
+
+例として GUI 駆動型のプログラムを取り上げてみましょう。
+プログラムは、ディスプレイに同期アクセスするためにセマフォを持っています。
+そうして一度にただ一つのスレッドだけが描画を行っています。
+簡単な話ですが、もちろん、ちゃんと準備ができるまでどのスレッドにも描画を
+始めてもらいたくはありません。
+こんな場合に、カウンタを 0 にしてセマフォを生成するのです。
+そして描画の準備ができたら、カウンタを増加させます。
+
+=begin original
+
+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.
+
+=end original
+
+1 より大きいカウンタを持つセマフォはクォータの確立にも役立ちます。
+例えば、同時に I/O を使うスレッドがいくつもあるとします。
+だが、全てのスレッドが同時に読み書きをするのは望みません。
+そんなことをしたら I/O チャンネルを圧迫するかもしれないし、プロセスに
+割り当てられたファイルハンドルを枯渇させてしまうかもしれないからです。
+あなたがいつでも必要とし、スレッドに暗黙にブロック・アンブロックを
+させたいだけの同時 I/O リクエスト数(あるいはオープンファイル数)で
+初期設定されたセマフォを利用すればよいです。
+
+=begin original
+
+Larger increments or decrements are handy in those cases where a
+thread needs to check out or return a number of resources at once.
+
+=end original
+
+あるスレッドが一度にたくさんのリソースを借りたり戻したりするような
+こういうケースでは、大きな数で増減を行うのが便利です。
+
+=head2 Waiting for a Condition
+
+(条件を待つ)
+
+=begin original
+
+The functions C<cond_wait()> and C<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 C<pthreads>. However
+for most purposes, queues are simpler to use and more intuitive. See
+L<threads::shared> for more details.
+
+=end original
+
+関数 C<cond_wait()> と C<cond_signal()> は、ロックが同時発生する時に、
+リソースが利用可能になった協調型スレッドに通知を行うために用います。
+これらは、C<pthreads> にある関数とよく似ています。
+しかしほとんどの目的において、キューの方がより単純で直感的です。
+更なる詳細は L<threads::shared> を参照してください。
+
+
+=head2 Giving up control
+
+(制御の明け渡し)
+
+=begin original
+
+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.
+
+=end original
+
+あるスレッドが明示的に他のスレッドへと CPU を譲り渡せられたら便利だと
+思うことがあるでしょう。
+あなたはプロセッサ集約的なことをしようとしているかもしれませんし、
+ユーザーインターフェース担当のスレッドが呼び出されることを確認したいと
+思うかもしれません。
+とにかく、スレッドがプロセッサを明け渡せたら、ということがよくあります。
+
+=begin original
+
+Perl's threading package provides the C<yield()> function that does
+this. C<yield()> is pretty straightforward, and works like this:
+
+=end original
+
+Perl のスレッドパッケージはこれを実現する C<yield()> 関数を提供しています。
+C<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');
+
+=begin original
+
+It is important to remember that C<yield()> is only a hint to give up the CPU,
+it depends on your hardware, OS and threading libraries what actually happens.
+B<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
+C<yield()> calls. It might work on your platform but it won't work on another
+platform.
+
+=end original
+
+C<yield()> は CPU を明け渡すためのヒントでしかありません。
+実際に何が起こるのかは、ハードウェアや OS、そしてスレッドライブラリに
+依存しています。
+B<多くのオペレーティングシステムにおいて、yield() は何も機能しません。>
+それゆえ、C<yield()> を呼んでスレッドのスケジューリングをたてるべきでは
+ないことに注意することが重要です。
+あなたのプラットフォームでは動作したとしても、別のプラットフォームでは
+動かないかもしれません。
+
+=head1 General Thread Utility Routines
+
+(一般的なスレッドユーティリティルーチン)
+
+=begin original
+
+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.
+
+=end original
+
+Perlのスレッドパッケージの働き部分をみてきました。
+これらの道具を使い、あなたのやり方でスレッドコードとパッケージを
+書いていくことができるはずです。
+他の場所では実際にはフィットしないけれども、便利な小物も少しはあります。
+
+=head2 What Thread Am I In?
+
+(私はどのスレッドにいる?)
+
+=begin original
+
+The C<threads-E<gt>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.
+
+=end original
+
+C<threads-E<gt>self()> クラスメソッドを使うと、現在のスレッドを表す
+オブジェクトを得ることができます。
+スレッドを生成するときに返ってくるオブジェクトと同じように、この
+オブジェクトを使うことができます。
+
+=head2 Thread IDs
+
+(スレッド ID)
+
+=begin original
+
+C<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, C<threads-E<gt>tid()>
+can be used by a thread to get its own TID.
+
+=end original
+
+C<tid()> はオブジェクトが表すスレッドの ID を返すメソッドです。
+スレッド ID は整数で、プログラム中のメインスレッドは 0 です。
+現在の Perl は、プログラム中で生成された全てのスレッドに一意な ID を
+つけます。
+最初に生成されたスレッドには 1 があてられ、新しいスレッドが作られる度に
+ID は 1 ずつ増えていきます。
+When used as a class method, C<threads-E<gt>tid()>
+can be used by a thread to get its own TID.
+(TBT)
+
+=head2 Are These Threads The Same?
+
+(このスレッドは同じものか?)
+
+=begin original
+
+The C<equal()> method takes two thread objects and returns true
+if the objects represent the same thread, and false if they don't.
+
+=end original
+
+C<equal()> メソッドは二つのスレッドオブジェクトを引数にとり、オブジェクトが
+同じスレッドを示していれば真を、そうでなければ偽を返します。
+
+=begin original
+
+Thread objects also have an overloaded C<==> comparison so that you can do
+comparison on them as you would with normal objects.
+
+=end original
+
+スレッドオブジェクトは比較演算子 C<==> をオーバーロードするので、普通の
+オブジェクトのようにそれらを比較することもできます。
+
+=head2 What Threads Are Running?
+
+(どのスレッドが実行されているのか?)
+
+=begin original
+
+C<threads-E<gt>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):
+
+=end original
+
+C<threads-E<gt>list()> はスレッドオブジェクトのリストを返します。
+それぞれは現在実行中で detach されていないスレッドです。
+プログラムの終わりにクリーンナップするのも含めていろいろな点で便利です
+(from the main Perl thread, of course):
+(TBT)
+
+ # Loop through all the threads
+ foreach my $thr (threads->list()) {
+ $thr->join();
+ }
+
+=begin original
+
+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.
+
+=end original
+
+もしメインスレッドが終了する時に、あるスレッドが実行を終了していなかったら、
+Perl は警告を発し、die します。
+これは、他のスレッドが実行中の間は Perl が自分自身をクリーンナップ
+できないためです。
+
+=begin original
+
+NOTE: The main Perl thread (thread 0) is in a I<detached> state, and so
+does not appear in the list returned by C<threads-E<gt>list()>.
+
+=end original
+
+NOTE: The main Perl thread (thread 0) is in a I<detached> state, and so
+does not appear in the list returned by C<threads-E<gt>list()>.
+(TBT)
+
+=head1 A Complete Example
+
+(完全な例)
+
+=begin original
+
+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.
+
+=end original
+
+まだ混乱していますか?
+では、サンプルプログラムを使ってこれまで見てきたことのいくつかを示す時です。
+このプログラムはスレッドを使って素数を見つけだします。
+
+ 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 my $stream = Thread::Queue->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 }
+
+=begin original
+
+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.
+
+=end original
+
+このプログラムは素数を発生させるためにパイプラインモデルを利用しています。
+パイプラインにおけるそれぞれのスレッドは、素数を見つけるために
+チェックされる数を渡す入力キューと、チェックに失敗した数をかき集めておく
+出力キューとを持ちます。
+チェックに失敗した数がスレッドにあり、かつ、子スレッドがない場合、その
+スレッドは新しい素数を見つけたことになります。
+この場合、新しい子スレッドはその素数のために生成され、パイプラインの後ろに
+くっつけられます。
+
+=begin original
+
+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.)
+
+=end original
+
+これは実際よりもわかりにくいかもしれません。
+だからこのプログラムを部分部分に分けて、なにをしているのかを見てみましょう。
+(素数とは正確には何だったかということを思い出そうされている方のためにいうと、
+自分自身と 1 でのみ割り切れる数のことです。)
+
+=begin original
+
+The bulk of the work is done by the C<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).
+
+=end original
+
+作業の大半は C<check_num()> ルーチンによってなされます。
+このルーチンは入力キューへのリファレンスとスレッドが受け持つ素数を
+引数にとります。
+[引数を]入力キューとサブルーチンがチェックする素数[のローカル変数]に
+入れた後(20 行目)、新しいキューを生成します(22 行目)。
+そして、後で生成するかもしれないスレッドを入れるスカラー変数を
+用意します(21 行目)。
+
+=begin original
+
+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.
+
+=end original
+
+23 行目から31 行目までの while ループで入力キューからスカラー値を
+取り出し、このスレッドが受け持つ素数でチェックします。
+24 行目では、チェックされる数に対する除算を行い、余りがあるかどうかを
+調べます。
+もしあれば、その数は素数では割れないということです。
+そこでその数を、すでに生成してあるのであれば次のスレッドに渡しますし、
+そうでなければ新しいスレッドを作ります。
+
+=begin original
+
+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.
+
+=end original
+
+29 行目で新しいスレッドの生成を行っています。
+そのスレッドに、先に作ったキューへのリファレンスと発見された素数を渡します。
+
+=begin original
+
+Finally, once the loop terminates (because we got a 0 or C<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).
+
+=end original
+
+最後に、(キューの中に 0 か C<undef> があるかして)ループが終了すると、
+子スレッドを作っていた場合には子スレッドに注意を促し[(undef を送る)]、
+実行が終了するのを待ちます(32, 35 行目)。
+
+=begin original
+
+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 C<join()>.
+
+=end original
+
+一方、メインスレッドに戻ってみると、まずキューを生成(10 行目)、
+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.
+最後に、最初の子スレッドが終了するのを待ちます(17 行目)。
+ある子スレッドの子スレッドが終了するまで、
+そのスレッドは終了しないので、C<join()> から戻ってきた時点で作業が
+終わったことになります。
+(TBT)
+
+=begin original
+
+That's how it works. It's pretty simple; as with many Perl programs,
+the explanation is much longer than the program.
+
+=end original
+
+以上が仕組みです。
+とても単純です; 多くのPerlプログラムにとってそうであるように、
+説明の方が当のプログラム以上にとても長くなります。
+
+=head1 Different implementations of threads
+
+(様々なスレッドの実装)
+
+=begin original
+
+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.
+
+=end original
+
+オペレーティングシステムの観点からみた、スレッド実装についての背景です。
+スレッドには三つの基本的なカテゴリーがあります: ユーザーモードスレッド、
+カーネルスレッド、マルチプロセッサカーネルスレッドです。
+
+=begin original
+
+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.
+
+=end original
+
+ユーザーモードスレッドとは、完全にプログラムとライブラリの中に存在する
+スレッドです。
+このモデルにおいては、OS はスレッドについて何も関知しません。
+OS からしてみる限り、あなたのプロセスはただのひとつのプロセスです。
+
+=begin original
+
+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 C<sleep()>.
+
+=end original
+
+これは最も簡単なスレッドの実装であり、ほとんどの OS が最初にとった方法です。
+この方法の大きな欠点は、OS がスレッドに関知していないために、
+もしも一つのスレッドがブロックをしたら、全てのスレッドがブロックしてしまう
+ということです。
+典型的なブロック行為には、ほとんどのシステムコール、ほとんどの
+I/O、そして C<sleep()> のようなものが含まれます。
+
+=begin original
+
+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.
+
+=end original
+
+カーネルスレッドは進化の第二段階です。
+OS はカーネルスレッドについて知っていて、その許可を出します。
+カーネルスレッドとユーザーモードスレッドの主要な違いは、
+ブロッキングについてです。
+カーネルスレッドでは、一つのスレッドをブロックした事で他のスレッドまで
+ブロックすることはありません。
+これはユーザーモードスレッドにおいては成り立ちません。
+ユーザーモードでは、カーネルがブロックするのはプロセスレベルであって、
+スレッドレベルではないからです。
+
+=begin original
+
+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.
+
+=end original
+
+これは大きな前進であり、非スレッドプログラムに対し、スレッドプログラムが
+大きなパフォーマンスの向上を得ることを可能にしています。
+例えば、I/O の実行をブロックするスレッドは、他のことを行うスレッドを
+ブロックしないでしょう。
+しかし、システムがいくつ CPU を備えているかに関係なく、それぞれのプロセスは
+いまだに一度に一つのスレッドしか走らせません。
+
+=begin original
+
+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 C<$a = $a + 2> can behave
+unpredictably with kernel threads if C<$a> is visible to other
+threads, as another thread may have changed C<$a> between the time it
+was fetched on the right hand side and the time the new value is
+stored.
+
+=end original
+
+カーネルのスレッド制御がいつでも割り込めるので、あなたがプログラム中に
+つくった暗黙のロックの前提が白日の下にさらけ出してしまうでしょう。
+例えば、C<$a = $a + 2>のような単純なものでも、C<$a> が他のスレッドから
+見えるならば、右辺の値を取り出す時間と新しい値を格納する時間の間に、他の
+スレッドが C<$a> を変えてしまって、あなたの予期しない振る舞いをする
+可能性があります。
+
+=begin original
+
+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.
+
+=end original
+
+マルチプロセッサカーネルスレッドは、スレッドのサポートにおける最終段階です。
+一台のマシンが複数の CPU を持っているマルチプロセッサカーネルスレッドでは、
+OS は別々の CPU 上で同時に一つ以上のスレッドを走らせるようにスケジュール
+管理をします。
+
+=begin original
+
+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.
+
+=end original
+
+一つ以上のスレッドが同時に実行するので、これによりスレッドプログラムは
+飛躍的なパフォーマンスの向上を得ることができます。
+しかし、引き換えに、基本的なカーネルスレッドでは現れなかったであろう
+イライラするような同期性の問題が一気に姿を現します。
+
+=begin original
+
+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.
+
+=end original
+
+スレッドを備える OS の違いというレベルに加えて、それぞれの OS は(そして
+それぞれのスレッド実装は)それぞれの方法でもって CPU サイクルをスレッドに
+割り当てます。
+
+=begin original
+
+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.
+
+=end original
+
+次の二つのうちの一つが起こる場合、協調的マルチタスクシステムは実行中の
+スレッドに制御を明け渡させます。
+あるスレッドがyield関数を呼び出すと、制御を明け渡します。
+また、スレッドがI/Oの実行などのブロックを引き起こすような何かを行う場合も、
+制御を明け渡します。
+協調的マルチタスクシステムの実装においては、そのように選択するならば、
+一つのスレッドが他の全てのスレッドの CPU 時間を食い尽くすことができます。
+
+=begin original
+
+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.
+
+=end original
+
+プリエンティブなマルチタスクシステムは、次にどのスレッドを実行するか
+決めながら、一定の間隔でスレッドに割り込みを入れます。
+プリエンティブなマルチタスクシステムにおいて、通常一つのスレッドが CPU を
+独占することはありません。
+
+=begin original
+
+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.)
+
+=end original
+
+いくつかのシステムでは、協調的スレッドとプリエンティブなスレッドを同時に
+実行することができます(例えば、通常のプライオリティを持ったスレッドが
+プリエンディブに振舞うのに対して、リアルタイムのプライオリティを持った
+スレッドはしばしば協調的に振舞います)。
+
+=begin original
+
+Most modern operating systems support preemptive multitasking nowadays.
+
+=end original
+
+今では、ほとんどの近代的なOSでプリエンティブなマルチタスクを
+サポートしています。
+
+=head1 Performance considerations
+
+(パフォーマンスの考慮)
+
+=begin original
+
+The main thing to bear in mind when comparing Perl's I<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.
+
+=end original
+
+Perl の I<iスレッド> と他のスレッドモデルを比較する際に忘れてならないのが、
+新しいスレッドはみな、親スレッドの変数とデータを全て完全にコピーして
+引き渡されるという事実です。
+そのため、メモリ使用量と実行時間の両方の点で、スレッドの生成は非常に
+高くつきます。
+このコストを減らす理想的な方法は、長生きなスレッドを比較的少なめに
+持つことです。
+このスレッドは全て、ベースとなるスレッドが非常に多くのデータを蓄積する前に、
+適切に早い段階で生成されます。
+もちろん、これはいつも可能というわけではないでしょうから、妥協も必要です。
+しかし、スレッドが生成された後は、そのパフォーマンスと追加のメモリ使用量は、
+普通のコードのそれとほとんど違いはありません。
+
+=begin original
+
+Also note that under the current implementation, shared variables
+use a little more memory and are a little slower than ordinary variables.
+
+=end original
+
+また、現在の実装下では、共有変数は通常の変数に比べて少し余計にメモリを
+使用し、スピードも少し遅いことにも注意してください。
+
+=head1 Process-scope Changes
+
+(プロセススコープの変更)
+
+=begin original
+
+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.
+
+=end original
+
+スレッドそれ自身は別々に実行され、Perl のデータは明示的に共有化しない限りは
+スレッド内でプライベートなものです;
+その一方、スレッドは全てのスレッドに影響を与えながら、プロセススコープの
+状態に影響を与えてしまうことに注意してください。
+
+=begin original
+
+The most common example of this is changing the current working
+directory using C<chdir()>. One thread calls C<chdir()>, and the working
+directory of all the threads changes.
+
+=end original
+
+この最も一般的な例は C<chdir()> を使ったときに現在作業中のディレクトリが
+変更されてしまうことです。
+一つのスレッドが C<chdir()> を呼ぶと、全てのスレッドの作業ディレクトリが
+変更されます。
+
+=begin original
+
+Even more drastic example of a process-scope change is C<chroot()>:
+the root directory of all the threads changes, and no thread can
+undo it (as opposed to C<chdir()>).
+
+=end original
+
+さらに劇的なプロセススコープの変更例は C<chroot()> です。
+全部のスレッドのルートディレクトリが変更されます。
+スレッドはそれを元に戻すことはできません(C<chdir()> の場合は可能です)。
+
+=begin original
+
+Further examples of process-scope changes include C<umask()> and
+changing uids and gids.
+
+=end original
+
+さらなるプロセススコープ変化の例は、C<umask()> および uid や gid の変更です。
+
+=begin original
+
+Thinking of mixing C<fork()> and threads? Please lie down and wait
+until the feeling passes. Be aware that the semantics of C<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 C<fork()>. You have been warned!
+
+=end original
+
+C<fork()> とスレッドを混在させたらどうなるかって?
+そんな気分が失せるまで、横になって休んでいてください。
+Be aware that the semantics of C<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 C<fork()>. You have been warned!
+(TBT)
+
+=begin original
+
+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 L<threads/"THREAD SIGNALLING> for more details.)
+
+=end original
+
+同じように、シグナルとスレッドを混ぜるのもするべきではありあません。
+実装はプラットフォーム依存だし、POSIX のセマンティクスでさえ、あなたの
+期待通りにはならないかもしれません
+(そして Perl はフルセットの 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 L<threads/"THREAD SIGNALLING> for more details.)
+(TBT)
+
+=head1 Thread-Safety of System Libraries
+
+(システムライブラリにおけるスレッドの安全性)
+
+=begin original
+
+Whether various library calls are thread-safe is outside the control
+of Perl. Calls often suffering from not being thread-safe include:
+C<localtime()>, C<gmtime()>, functions fetching user, group and
+network information (such as C<getgrent()>, C<gethostent()>,
+C<getnetent()> and so on), C<readdir()>,
+C<rand()>, and C<srand()> -- in general, calls that depend on some global
+external state.
+
+=end original
+
+様々なライブラリの関数呼び出しがスレッドにとって安全かどうかということは、
+Perlのコントロールの埒外です。
+しばしばスレッドセーフではないものに
+よって問題の生じる呼び出しには、C<localtime()>, C<gmtime()>,
+functions fetching user, group and
+network information (such as C<getgrent()>, C<gethostent()>,
+C<getnetent()> and so on), C<readdir()>,
+C<rand()>, C<srand()>
+-- 一般的にいって、グローバルな外部状況に依存する呼び出しが含まれます。
+(TBT)
+
+=begin original
+
+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.
+
+=end original
+
+Perl がコンパイルされたシステムが、そういった呼び出しのスレッドセーフな
+バージョンを持っているなら、そちらが使われます。
+それを超えると、Perl は呼び出しがスレッドセーフかどうかのなすがままに
+なります。
+C ライブラリのドキュメントをよく吟味してください。
+
+=begin original
+
+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
+C<PERL_REENTRANT_MAXSIZE> defined to the maximum number of bytes you will
+allow.
+
+=end original
+
+いくつかのプラットフォームでは、結果バッファが小さすぎる場合に
+スレッドセーフなライブラリのインターフェースが失敗を起こすかもしれません
+(例えば、ユーザーグループのデータベースがかなり大きく、リエントラントな
+インターフェースがこれらのデータベースの完全なスナップショットを
+もたらさなければならないような場合)。
+Perl は小さなバッファでスタートします。
+しかし結果が適合するまで結果バッファの確保を再試行し、大きくしようとします。
+この無制限な成長がセキュリティやメモリ消費の理由から好ましくないもので
+あるなら、C<PERL_REENTRANT_MAXSIZE> であなたの許す最大バイト数を定義して
+Perl を再コンパイルできます。
+
+=head1 Conclusion
+
+(おわりに)
+
+=begin original
+
+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.
+
+=end original
+
+完全なスレッドのチュートリアルをつくると一冊の本になってしまいます。
+しかしこの導入でカバーしてきたことを使って、あなたなりの方法で
+スレッド Perl のエキスパートになっていってください。
+
+=head1 SEE ALSO
+
+Annotated POD for L<threads>:
+L<http://annocpan.org/?mode=search&field=Module&name=threads>
+
+Lastest version of L<threads> on CPAN:
+L<http://search.cpan.org/search?module=threads>
+
+Annotated POD for L<threads::shared>:
+L<http://annocpan.org/?mode=search&field=Module&name=threads%3A%3Ashared>
+
+Lastest version of L<threads::shared> on CPAN:
+L<http://search.cpan.org/search?module=threads%3A%3Ashared>
+
+Perl threads mailing list:
+L<http://lists.cpan.org/showlist.cgi?name=iThreads>
+
+=head1 Bibliography
+
+(参考文献)
+
+=begin original
+
+Here's a short bibliography courtesy of J?gen Christoffel:
+
+=end original
+
+Jurgen Christoffel の提供による簡潔な参考文献集：
+
+=head2 Introductory Texts
+
+(導入テキスト)
+
+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).
+
+=head2 OS-Related References
+
+(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
+
+=head2 Other References
+
+(その他のリファレンス)
+
+Arnold, Ken and James Gosling. The Java Programming Language, 2nd
+ed. Addison-Wesley, 1998, ISBN 0-201-31006-6.
+
+comp.programming.threads FAQ,
+L<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,
+L<http://www.perl.com/pub/a/2002/06/11/threads.html>
+
+=head1 Acknowledgements
+
+(謝辞)
+
+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.
+
+=head1 AUTHOR
+
+(著者)
+
+Dan Sugalski E<lt>dan****@sidhe*****<gt>
+
+=begin original
+
+Slightly modified by Arthur Bergman to fit the new thread model/module.
+
+=end original
+
+新しいスレッドモデル・モジュールに対応するように Arthur Bergman によって
+若干の修正がなされました。
+
+=begin original
+
+Reworked slightly by J?g Walter E<lt>jwalt****@cpan*****<gt> to be more concise
+about thread-safety of Perl code.
+
+=end original
+
+Perl コードのスレッドセーフティについてより簡明になるよう
+Jorg Walter E<lt>jwalt****@cpan*****<gt> によって改訂されました。
+
+=begin original
+
+Rearranged slightly by Elizabeth Mattijsen E<lt>liz****@dijkm*****<gt> to put
+less emphasis on yield().
+
+=end original
+
+Elizabeth Mattijsen E<lt>liz****@dijkm*****<gt> によって、yield() を以前より
+強調しないよう若干アレンジされました。
+
+=head1 Copyrights
+
+(著作権)
+
+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.
+
+=cut
+