perlthrtut 5.10.1 と 5.40.0 の差分

1	1
2		=encoding eu~~c-jp~~
	2	=encoding utf8
3	3
4	4	=head1 NAME
5	5
6	6	=begin original
7	7
8	8	perlthrtut - Tutorial on threads in Perl
9	9
10	10	=end original
11	11
12	12	perlthrtut - Perl におけるスレッドのチュートリアル
13	13
14	14	=head1 DESCRIPTION
15	15
16	16	=begin original
17	17
18	18	This tutorial describes the use of Perl interpreter threads (sometimes
19		referred to as I<ithreads>) ~~that was first introduced in Perl 5.6.0~~. In this
	19	referred to as I<ithreads>). In this
20	20	model, each thread runs in its own Perl interpreter, and any data sharing
21	21	between threads must be explicit. The user-level interface for I<ithreads>
22	22	uses the L<threads> class.
23	23
24	24	=end original
25	25
26		このチュートリアルは、Perl ~~5.6.0 において導入された新しい Perl~~ インタプリタ
	26	このチュートリアルは、Perl インタプリタスレッド(B<iスレッド>(B<ithreads>)と
27		~~スレッド(B<iスレッド>(B<ithreads>)と~~呼ばれる)の特徴を説明するものです。
	27	呼ばれる)の特徴を説明するものです。
28	28	このモデルにおいては、それぞれのスレッドはそれ自身の Perl インタプリタで
29	29	実行され、スレッド間で共有するデータも明示的でなければなりません。
30	30	I<ithreads> のユーザーレベルインターフェースは L<threads> クラスを使います。
31	31
32	32	=begin original
33	33
34	34	B<NOTE>: There was another older Perl threading flavor called the 5.005 model
35		that used the L<Threads> class. This old model was known to have problems, is
	35	that used the L<threads> class. This old model was known to have problems, is
36	36	deprecated, and was removed for release 5.10. You are
37	37	strongly encouraged to migrate any existing 5.005 threads code to the new
38	38	model as soon as possible.
39	39
40	40	=end original
41	41
42		B<注意>: ~~Perl のバージョン~~ 5.005 ~~には、5.005~~ モデルと呼ばれる
	42	B<注意>: 5.005 モデルと呼ばれるL<threads> クラスを使う別の古いスレッド機能が
43		~~L<Threads> クラスを使う別の古いスレッド機能が~~ありました。
	43	ありました。
44	44	この古いモデルは問題があることが知られていて、非推奨で、バージョン5.10 で
45	45	削除されました。
46	46	できるだけ速やかに既存の5.005スレッドを新しいものに移行することが
47	47	強く勧められます。
48	48
49	49	=begin original
50	50
51	51	You can see which (or neither) threading flavour you have by
52	52	running C<perl -V> and looking at the C<Platform> section.
53	53	If you have C<useithreads=define> you have ithreads, if you
54	54	have C<use5005threads=define> you have 5.005 threads.
55	55	If you have neither, you don't have any thread support built in.
56	56	If you have both, you are in trouble.
57	57
58	58	=end original
59	59
60	60	C<perl -V> で C<Platform> セクションを見れば、どちらのスレッド機能があるのか
61	61	(あるいは無いのか)を知ることができます。
62	62	もし C<useithreads=define> となって
63	63	いればiスレッドをサポートしているし、C<use5005threads=define> とあれば
64	64	5.005 スレッドです。
65	65	両方とも出ない場合、あなたの Perl はスレッドをサポートしていません。
66	66	両方ある場合は問題があります。
67	67
68	68	=begin original
69	69
70	70	The L<threads> and L<threads::shared> modules are included in the core Perl
71	71	distribution. Additionally, they are maintained as a separate modules on
72	72	CPAN, so you can check there for any updates.
73	73
74	74	=end original
75	75
76	76	L<threads> と L<threads::shared> のモジュールはコア Perl 配布に
77	77	含まれています。
78	78	さらに、CPAN では別個のモジュールとして保守されているので、更新については
79	79	CPAN をチェックできます。
80	80
81	81	=head1 What Is A Thread Anyway?
82	82
83	83	(ところでスレッドって何?)
84	84
85	85	=begin original
86	86
87	87	A thread is a flow of control through a program with a single
88	88	execution point.
89	89
90	90	=end original
91	91
92	92	スレッドとはプログラム内を通じて一つの実行点を持った制御のフローです。
93	93
94	94	=begin original
95	95
96	96	Sounds an awful lot like a process, doesn't it? Well, it should.
97	97	Threads are one of the pieces of a process. Every process has at least
98	98	one thread and, up until now, every process running Perl had only one
99	99	thread. With 5.8, though, you can create extra threads. We're going
100	100	to show you how, when, and why.
101	101
102	102	=end original
103	103
104	104	こういうと非常に多くの点でプロセスに似ているように聞こえるでしょう。
105	105	確かにその通りで、スレッドはひとつのプロセスにおける細かい部分の一つです。
106	106	全てのプロセスは少なくとも一つのスレッドを持ちます。
107	107	そしてこれまでは、Perl を走らせるプロセスは全てただ一つのスレッドを
108	108	持っていました。
109	109	しかし 5.8 になって、余分にスレッドをつくることができるようになりました。
110	110	それがいつどのように、いかにしてなされるのかをこれから示していきましょう。
111	111
112	112	=head1 Threaded Program Models
113	113
114	114	(スレッドプログラムのモデル)
115	115
116	116	=begin original
117	117
118	118	There are three basic ways that you can structure a threaded
119	119	program. Which model you choose depends on what you need your program
120	120	to do. For many non-trivial threaded programs, you'll need to choose
121	121	different models for different pieces of your program.
122	122
123	123	=end original
124	124
125	125	スレッドプログラムを構築する 3 つの基本的な方法があります。
126	126	どのモデルを選ぶかはプログラムに何をやらせるかに依存します。
127	127	多くの重要なスレッドプログラムにおいては、プログラム中の異なる部分に
128	128	異なるモデルを選択する必要があるでしょう。
129	129
130	130	=head2 Boss/Worker
131	131
132	132	(ボス/ワーカー)
133	133
134	134	=begin original
135	135
136	136	The boss/worker model usually has one I<boss> thread and one or more
137	137	I<worker> threads. The boss thread gathers or generates tasks that need
138	138	to be done, then parcels those tasks out to the appropriate worker
139	139	thread.
140	140
141	141	=end original
142	142
143	143	ボス・ワーカーモデルでは通常、一つの I<ボス> スレッドと、一つ以上の
144	144	I<ワーカー> スレッドを持ります。
145		ボススレッドは必要とされるタスクを集約ないし生成します。
	145	ボススレッドは必要とされるタスクを集約ないし生成します; それからそれらの
146		~~それからそれらの~~タスクを適したワーカースレッドに分配します。
	146	タスクを適したワーカースレッドに分配します。
147	147
148	148	=begin original
149	149
150	150	This model is common in GUI and server programs, where a main thread
151	151	waits for some event and then passes that event to the appropriate
152	152	worker threads for processing. Once the event has been passed on, the
153	153	boss thread goes back to waiting for another event.
154	154
155	155	=end original
156	156
157		このモデルは GUI とサーバプログラムに共通です。
	157	このモデルは GUI とサーバプログラムに共通です; そこではメインスレッドが
158		~~そこではメ~~イ~~ンスレッドがイ~~ベント発生を待ち、処理のために適した
	158	イベント発生を待ち、処理のために適したワーカースレッドにイベントを渡します。
159		ワーカースレッドにイベントを渡します。
160	159	ひとたびイベントが渡されると、ボススレッドは次のイベントのために待機します。
161	160
162	161	=begin original
163	162
164	163	The boss thread does relatively little work. While tasks aren't
165	164	necessarily performed faster than with any other method, it tends to
166	165	have the best user-response times.
167	166
168	167	=end original
169	168
170	169	ボススレッドは相対的に仕事量は少ないです。
171	170	タスクは他の方法を使ったものより必ずしも早く実行されるわけではないですが、
172	171	最もユーザーレスポンスタイムが良くなる傾向にあります。
173	172
174	173	=head2 Work Crew
175	174
176	175	(仕事仲間)
177	176
178	177	=begin original
179	178
180	179	In the work crew model, several threads are created that do
181	180	essentially the same thing to different pieces of data. It closely
182	181	mirrors classical parallel processing and vector processors, where a
183	182	large array of processors do the exact same thing to many pieces of
184	183	data.
185	184
186	185	=end original
187	186
188	187	仕事仲間モデルでは、データの様々な部分に対し本質的に同じ作業を行う
189	188	いくつかのスレッドがつくられます。
190	189	これは、プロセッサの巨大な配列が多くのデータ片に対して全く同じことを行う
191	190	古典的な並列処理やベクトル処理とそっくりです。
192	191
193	192	=begin original
194	193
195	194	This model is particularly useful if the system running the program
196	195	will distribute multiple threads across different processors. It can
197	196	also be useful in ray tracing or rendering engines, where the
198	197	individual threads can pass on interim results to give the user visual
199	198	feedback.
200	199
201	200	=end original
202	201
203	202	プログラムを走らせているシステムが、異なるプロセスをまたいでマルチスレッドを
204	203	分配するような場合、このモデルは殊のほか便利です。
205	204	また、レイトレースやレンダリングエンジンといった、個々のスレッドが暫定的な
206	205	結果をユーザに対し視覚的にフィードバックするような場合にも便利でしょう。
207	206
208	207	=head2 Pipeline
209	208
210	209	(パイプライン)
211	210
212	211	=begin original
213	212
214	213	The pipeline model divides up a task into a series of steps, and
215	214	passes the results of one step on to the thread processing the
216	215	next. Each thread does one thing to each piece of data and passes the
217	216	results to the next thread in line.
218	217
219	218	=end original
220	219
221		パイプラインモデルはあるタスクを何段階の処理の連続へと分けます。
	220	パイプラインモデルはあるタスクを何段階の処理の連続へと分けます;
222	221	そして一つのステップの結果を次の処理を行うスレッドへと渡します。
223	222	それぞれのスレッドはデータの各部分に対し一つのことを行い、結果を次の
224	223	スレッドへ渡します。
225	224
226	225	=begin original
227	226
228	227	This model makes the most sense if you have multiple processors so two
229	228	or more threads will be executing in parallel, though it can often
230	229	make sense in other contexts as well. It tends to keep the individual
231	230	tasks small and simple, as well as allowing some parts of the pipeline
232	231	to block (on I/O or system calls, for example) while other parts keep
233	232	going. If you're running different parts of the pipeline on different
234	233	processors you may also take advantage of the caches on each
235	234	processor.
236	235
237	236	=end original
238	237
239	238	しばしば他の文脈でも同じぐらいの意味があるますが、二つ以上のスレッドが
240	239	並列に処理を行うようにあなたがマルチプロセッサを持っているならば、この
241	240	モデルは最も意味があります。
242	241	それは、あるパイプラインの一部が進行中の間に、他のパイプラインの一部が
243	242	(例えば I/O やシステムコールを)ブロックするのを
244	243	許可するのと同様、個々のタスクを小さく単純なものに留める傾向があります。
245	244	もし違うプロセッサ上で別々のパイプラインを走らせるなら、それぞれの
246	245	プロセッサのキャッシュを利用するという利益を得ることができるでしょう。
247	246
248	247	=begin original
249	248
250	249	This model is also handy for a form of recursive programming where,
251	250	rather than having a subroutine call itself, it instead creates
252	251	another thread. Prime and Fibonacci generators both map well to this
253	252	form of the pipeline model. (A version of a prime number generator is
254	253	presented later on.)
255	254
256	255	=end original
257	256
258	257	このモデルはまた、自分自身を呼び出すサブルーチンを持つよりも、別の
259	258	スレッドを生み出すような再起的プログラムの形態に利用しやすいです。
260	259	素数やフィボナッチ数列ジェネレーターは、どちらもこのパイプラインモデルの
261		形態にうまく位置付けられます~~(素数ジェネレーターの例は後で登場します)~~。
	260	形態にうまく位置付けられます。
	261	(素数ジェネレーターの例は後で登場します。)
262	262
263	263	=head1 What kind of threads are Perl threads?
264	264
265	265	(Perlスレッドはどんなスレッドか?)
266	266
267	267	=begin original
268	268
269	269	If you have experience with other thread implementations, you might
270	270	find that things aren't quite what you expect. It's very important to
271	271	remember when dealing with Perl threads that I<Perl Threads Are Not X
272	272	Threads> for all values of X. They aren't POSIX threads, or
273	273	DecThreads, or Java's Green threads, or Win32 threads. There are
274	274	similarities, and the broad concepts are the same, but if you start
275	275	looking for implementation details you're going to be either
276	276	disappointed or confused. Possibly both.
277	277
278	278	=end original
279	279
280	280	もしもあなたが他のスレッドの実装を経験したことがあるなら、事態は全く
281	281	あなたの予想とは違うことがわかるでしょう。
282	282	Perl スレッドを扱う時には、あらゆる X に対して
283	283	I<Perl スレッドは X スレッドではない> ということを忘れてはなりません。
284		それらは POSIX スレッドではありません。
	284	それらは POSIX スレッドではありません; DecThread でもなければ Java の
285		~~DecThread でもなければ Java の~~グリーンスレッドでないし、
	285	グリーンスレッドでないし、Win32 スレッドでもありません。
286		~~Win32 スレッドでも~~あ~~りません。~~
	286	類似点はあるし、広義の概念は同じです; しかし実装の詳細を調べだしたら、
287		~~類似点は~~ある~~し、広義~~の~~概念は同じ~~です。
	287	あなたは失望するか混乱するかのどちらかになるでしょう。
288		だが実装の詳細を調べだしたら、あなたは失望するか混乱するかの
289		どちらかになるでしょう。
290	288	あるいはその両方かもしれません。
291	289
292	290	=begin original
293	291
294	292	This is not to say that Perl threads are completely different from
295		everything that's ever come before ~~-- t~~hey're not. Perl's threading
	293	everything that's ever come before. They're not. Perl's threading
296	294	model owes a lot to other thread models, especially POSIX. Just as
297	295	Perl is not C, though, Perl threads are not POSIX threads. So if you
298	296	find yourself looking for mutexes, or thread priorities, it's time to
299	297	step back a bit and think about what you want to do and how Perl can
300	298	do it.
301	299
302	300	=end original
303	301
304	302	これは、これまで登場してきたあらゆるスレッドと Perl スレッドが完全に
305	303	異なるということを言っているのではありません。
	304	そうではありません。
306	305	Perl スレッドは他のモデル、特に POSIX スレッドに多くを負っています。
307	306	ですが、Perl が C ではないように、Perl スレッドは POSIX スレッドでは
308	307	ありません。
309	308	だから、もしあなたがミューテックスやスレッドプライオリティを
310	309	期待しているならば、ちょっと立ち戻って、自分が何をしたいのか、
311	310	Perl はいかにしてそれが可能なのかを考える時です。
312	311
313	312	=begin original
314	313
315	314	However, it is important to remember that Perl threads cannot magically
316	315	do things unless your operating system's threads allow it. So if your
317	316	system blocks the entire process on C<sleep()>, Perl usually will, as well.
318	317
319	318	=end original
320	319
321	320	しかし、あなたのオペレーティングシステムのスレッドが許可しない限り、
322	321	Perl スレッドが魔法のように何かを行うことはできないことを覚えておきましょう。
323	322	だからもし、システムが C<sleep()> でプロセスを丸ごとブロックするなら、通常
324	323	Perl も同様にそうするでしょう。
325	324
326	325	=begin original
327	326
328	327	B<Perl Threads Are Different.>
329	328
330	329	=end original
331	330
332		B<Perl スレッドは別ものです>。
	331	B<Perl スレッドは別ものです。>
333	332
334	333	=head1 Thread-Safe Modules
335	334
336	335	(スレッドセーフなモジュール)
337	336
338	337	=begin original
339	338
340	339	The addition of threads has changed Perl's internals
341	340	substantially. There are implications for people who write
342	341	modules with XS code or external libraries. However, since Perl data is
343	342	not shared among threads by default, Perl modules stand a high chance of
344	343	being thread-safe or can be made thread-safe easily. Modules that are not
345	344	tagged as thread-safe should be tested or code reviewed before being used
346	345	in production code.
347	346
348	347	=end original
349	348
350	349	スレッドの追加は Perl の内部的な実態を変化させてしまいました。
351	350	これには XS モジュールや外部ライブラリーを書いている人々も含まれます。
352		しかしながら、デフォルトではスレッド間で Perl のデータは共有されません。
	351	しかしながら、デフォルトではスレッド間で Perl のデータは共有されません;
353	352	そのため Perl モジュールはスレッドセーフであるという機会に恵まれていますし、
354	353	あるいは容易にスレッドセーフにすることができます。
355	354	スレッドセーフの札がついていないモジュールは製品版の前にテストされるか
356	355	コードレビューを受けるべきです。
357	356
358	357	=begin original
359	358
360	359	Not all modules that you might use are thread-safe, and you should
361	360	always assume a module is unsafe unless the documentation says
362	361	otherwise. This includes modules that are distributed as part of the
363	362	core. Threads are a relatively new feature, and even some of the standard
364	363	modules aren't thread-safe.
365	364
366	365	=end original
367	366
368	367	あなたが使おうとしているモジュールの全てがスレッドセーフというわけでは
369	368	ないですし、モジュールのドキュメントに安全であると書かれていないならば、
370	369	常に安全ではないものと仮定するべきです。
371	370	このことは、コアの一部として配布されているモジュールにもあてはまります。
372	371	スレッドは比較的新しい機構なので、標準モジュールの中にさえスレッドセーフで
373	372	ないものがあります。
374	373
375	374	=begin original
376	375
377	376	Even if a module is thread-safe, it doesn't mean that the module is optimized
378	377	to work well with threads. A module could possibly be rewritten to utilize
379	378	the new features in threaded Perl to increase performance in a threaded
380	379	environment.
381	380
382	381	=end original
383	382
384	383	仮にあるモジュールがスレッドセーフであったとしても、そのモジュールが
385	384	うまく働くように最適化されているということを意味するわけではありません。
386	385	できるだけスレッド環境でパフォーマンスが向上するように、スレッド化された
387	386	Perl の新機構を利用するようモジュールを書き直したほうがよいです。
388	387
389	388	=begin original
390	389
391	390	If you're using a module that's not thread-safe for some reason, you
392	391	can protect yourself by using it from one, and only one thread at all.
393	392	If you need multiple threads to access such a module, you can use semaphores and
394	393	lots of programming discipline to control access to it. Semaphores
395	394	are covered in L</"Basic semaphores">.
396	395
397	396	=end original
398	397
399	398	もしもなんらかの理由でスレッドセーフではないモジュールを使っているならば、
400	399	ただ一つのスレッドからそれを使うことによって防ぐことができます。
401	400	そのようなモジュールにアクセスするマルチスレッドが必要ならば、セマフォや
402	401	アクセスを制御するためのプログラミング原則を用いることができます。
403	402	セマフォは L</"Basic semaphores"> でカバーしています。
404	403
405	404	=begin original
406	405
407	406	See also L</"Thread-Safety of System Libraries">.
408	407
409	408	=end original
410	409
411	410	L</"Thread-Safety of System Libraries"> も参照してください。
412	411
413	412	=head1 Thread Basics
414	413
415	414	(スレッドの基本)
416	415
417	416	=begin original
418	417
419	418	The L<threads> module provides the basic functions you need to write
420	419	threaded programs. In the following sections, we'll cover the basics,
421	420	showing you what you need to do to create a threaded program. After
422	421	that, we'll go over some of the features of the L<threads> module that
423	422	make threaded programming easier.
424	423
425	424	=end original
426	425
427	426	L<threads> モジュールは、あなたがスレッドプログラムを書くのに必要と
428	427	なる基本的な機能を提供します。
429	428	次からのセクションでは、スレッドプログラムを作るのに必要なことを示しながら
430	429	基礎的なところをカバーしていきましょう。
431	430	その後で、スレッドプログラミングを容易にしてくれる L<threads> モジュールの
432	431	機能をみることにします。
433	432
434	433	=head2 Basic Thread Support
435	434
436	435	(基本的なスレッドのサポート)
437	436
438	437	=begin original
439	438
440		Thread support is a Perl compile-time option ~~-- i~~t's something that's
	439	Thread support is a Perl compile-time option. It's something that's
441	440	turned on or off when Perl is built at your site, rather than when
442	441	your programs are compiled. If your Perl wasn't compiled with thread
443	442	support enabled, then any attempt to use threads will fail.
444	443
445	444	=end original
446	445
447		スレッドのサポートは~~、あなた~~の~~プログラムが~~コンパイル~~される~~時で~~はなく、~~
	446	スレッドのサポートは Perl のコンパイル時のオプションです。
448		~~Perl~~ のコンパイル時~~のオプションによります。~~
	447	つまり、あなたのプログラムがコンパイルされる時ではなく、
449		~~つまり、~~Perl をビルトするときに、サポートのオン・オフを行います。
	448	Perl をビルトするときに、サポートのオン・オフを行います。
450	449	スレッドがサポートされるように Perl がコンパイルされていないなら、スレッドを
451	450	使おうとしても失敗するでしょう。
452	451
453	452	=begin original
454	453
455	454	Your programs can use the Config module to check whether threads are
456	455	enabled. If your program can't run without them, you can say something
457	456	like:
458	457
459	458	=end original
460	459
461	460	スレッドが使用可能かどうかをチェックするために Config モジュールを
462	461	利用できます。
463	462	あなたのプログラムがスレッド無しには実行できないなら、次のように記述できます:
464	463
465	464	use Config;
466		$Config{useithreads} or ~~die('Recompile Perl with threads to run this program.');~~
	465	$Config{useithreads} or
	466	die('Recompile Perl with threads to run this program.');
467	467
468	468	=begin original
469	469
470	470	A possibly-threaded program using a possibly-threaded module might
471	471	have code like this:
472	472
473	473	=end original
474	474
475	475	スレッドを利用するかもしれないモジュールを使うプログラムには、
476	476	次のようなコードをつけておくとよいでしょう:
477	477
478	478	use Config;
479	479	use MyMod;
480	480
481	481	BEGIN {
482	482	if ($Config{useithreads}) {
483	483	# We have threads
484	484	require MyMod_threaded;
485	485	import MyMod_threaded;
486	486	} else {
487	487	require MyMod_unthreaded;
488	488	import MyMod_unthreaded;
489	489	}
490	490	}
491	491
492	492	=begin original
493	493
494	494	Since code that runs both with and without threads is usually pretty
495	495	messy, it's best to isolate the thread-specific code in its own
496	496	module. In our example above, that's what C<MyMod_threaded> is, and it's
497	497	only imported if we're running on a threaded Perl.
498	498
499	499	=end original
500	500
501	501	スレッドの有無に関わらず走るようなコードは通常、非常に繁雑なものになるので、
502	502	スレッド専用のコードはモジュールとして分離しておくのがベストです。
503	503	上の例では、C<MyMod_threaded> がそれで、スレッド可能な Perl 上で走るときだけ
504	504	インポートされます。
505	505
506	506	=head2 A Note about the Examples
507	507
508	508	(例に対する注意)
509	509
510	510	=begin original
511	511
512	512	In a real situation, care should be taken that all threads are finished
513	513	executing before the program exits. That care has B<not> been taken in these
514	514	examples in the interest of simplicity. Running these examples I<as is> will
515	515	produce error messages, usually caused by the fact that there are still
516	516	threads running when the program exits. You should not be alarmed by this.
517	517
518	518	=end original
519	519
520	520	実際の状況では、プログラムが終了する前に全てのスレッドが実行を終えることに
521	521	注意を払わなければなりません。
522	522	簡明さを重視しているのでここで取り上げる例においては、そのような注意を
523	523	払って B<いません>。
524	524	これらの例を I<そのまま> 実行すると、プログラムが終了する際にまだスレッドが
525	525	走っているという理由で常にエラーメッセージが出力されるでしょう。
526	526	この警告は気にしなくて良いです。
527	527
528	528	=head2 Creating Threads
529	529
530	530	(スレッドの生成)
531	531
532	532	=begin original
533	533
534	534	The L<threads> module provides the tools you need to create new
535	535	threads. Like any other module, you need to tell Perl that you want to use
536	536	it; C<use threads;> imports all the pieces you need to create basic
537	537	threads.
538	538
539	539	=end original
540	540
541	541	L<threads> モジュールは新たなスレッドを生成するのに必要なツールを提供します。
542	542	他のモジュール同様、それを使いたいと Perl に伝える必要があります;
543	543	C<use threads;> によって基本的なスレッドを生み出すのに必要な全ての部品が
544	544	インポートされます。
545	545
546	546	=begin original
547	547
548	548	The simplest, most straightforward way to create a thread is with C<create()>:
549	549
550	550	=end original
551	551
552	552	最も単純で直接的なスレッドの生成方法は C<create()> によるものです:
553	553
554	554	use threads;
555	555
556	556	my $thr = threads->create(\&sub1);
557	557
558	558	sub sub1 {
559	559	print("In the thread\n");
560	560	}
561	561
562	562	=begin original
563	563
564	564	The C<create()> method takes a reference to a subroutine and creates a new
565	565	thread that starts executing in the referenced subroutine. Control
566	566	then passes both to the subroutine and the caller.
567	567
568	568	=end original
569	569
570	570	C<create()> メソッドはサブルーチンへのリファレンスを引数にとって新しい
571		スレッドを生成します。
	571	スレッドを生成します; このスレッドはリファレンスされたサブルーチンの実行を
572		~~このスレッドはリファレンスされたサブルーチンの実行を~~開始します。
	572	開始します。
573	573	このとき制御はサブルーチンと呼び出し側との両方に渡されます。
574	574
575	575	=begin original
576	576
577	577	If you need to, your program can pass parameters to the subroutine as
578	578	part of the thread startup. Just include the list of parameters as
579	579	part of the C<threads-E<gt>create()> call, like this:
580	580
581	581	=end original
582	582
583	583	もし必要ならばスレッド開始時のサブルーチンにパラメータを渡せます。
584	584	以下のように、C<threads-E<gt>create()> の呼び出しにパラメータのリストを
585	585	含めます:
586	586
587	587	use threads;
588	588
589	589	my $Param3 = 'foo';
590	590	my $thr1 = threads->create(\&sub1, 'Param 1', 'Param 2', $Param3);
591	591	my @ParamList = (42, 'Hello', 3.14);
592	592	my $thr2 = threads->create(\&sub1, @ParamList);
593	593	my $thr3 = threads->create(\&sub1, qw(Param1 Param2 Param3));
594	594
595	595	sub sub1 {
596	596	my @InboundParameters = @_;
597	597	print("In the thread\n");
598		print('Got parameters >', join('<>', @InboundParameters), "<\n");
	598	print('Got parameters >', join('<>',@InboundParameters), "<\n");
599	599	}
600	600
601	601	=begin original
602	602
603	603	The last example illustrates another feature of threads. You can spawn
604	604	off several threads using the same subroutine. Each thread executes
605	605	the same subroutine, but in a separate thread with a separate
606	606	environment and potentially separate arguments.
607	607
608	608	=end original
609	609
610	610	最後の例はスレッドのもう一つの特徴を示しています。
611	611	同じサブルーチンを利用するいくつものスレッドを生成することができます。
612	612	それぞれのスレッドは同一のサブルーチンを実行するが、それぞれのスレッドは
613	613	それぞれ別々の環境と引数をとることができます。
614	614
615	615	=begin original
616	616
617	617	C<new()> is a synonym for C<create()>.
618	618
619	619	=end original
620	620
621	621	C<new()> は C<create()> の言い換えです。
622	622
623	623	=head2 Waiting For A Thread To Exit
624	624
625	625	(スレッド終了の待機)
626	626
627	627	=begin original
628	628
629	629	Since threads are also subroutines, they can return values. To wait
630	630	for a thread to exit and extract any values it might return, you can
631	631	use the C<join()> method:
632	632
633	633	=end original
634	634
635	635	スレッドはサブルーチンでもあるので、値を返せます。
636	636	スレッドが終了して何らかの戻り値を得るのを待つために、C<join()> を使えます:
637	637
638	638	use threads;
639	639
640	640	my ($thr) = threads->create(\&sub1);
641	641
642	642	my @ReturnData = $thr->join();
643	643	print('Thread returned ', join(', ', @ReturnData), "\n");
644	644
645	645	sub sub1 { return ('Fifty-six', 'foo', 2); }
646	646
647	647	=begin original
648	648
649	649	In the example above, the C<join()> method returns as soon as the thread
650	650	ends. In addition to waiting for a thread to finish and gathering up
651	651	any values that the thread might have returned, C<join()> also performs
652	652	any OS cleanup necessary for the thread. That cleanup might be
653	653	important, especially for long-running programs that spawn lots of
654	654	threads. If you don't want the return values and don't want to wait
655	655	for the thread to finish, you should call the C<detach()> method
656	656	instead, as described next.
657	657
658	658	=end original
659	659
660	660	上の例では、スレッドが終了するとすぐに C<join()> メソッドが戻ります。
661	661	スレッドの終了と、返すべき値を収集するための待機に加えて、C<join()> は
662	662	スレッドが必要とする OS レベルのクリーンナップを実行します。
663	663	このクリーンナップは重要です; 特に長時間にわたって実行されるプログラムが
664	664	大量のスレッドを生成する場合には。
665	665	もしも戻り値を必要とせず、スレッドの終了を待つ必要もなければ、かわりに
666	666	次に説明する C<detach()> メソッドを呼び出すべきです。
667	667
668	668	=begin original
669	669
670	670	NOTE: In the example above, the thread returns a list, thus necessitating
671	671	that the thread creation call be made in list context (i.e., C<my ($thr)>).
672		See L<threads/"$thr->join()"> and L<threads/"THREAD CONTEXT"> for more
	672	See L<< threads/"$thr->join()" >> and L<threads/"THREAD CONTEXT"> for more
673	673	details on thread context and return values.
674	674
675	675	=end original
676	676
677	677	注意: 上記の例では、スレッドはリストを返すので、スレッド作成呼び出しは
678	678	(C<my ($thr)> のように)リストコンテキストで行われる必要があります。
679	679	スレッドのコンテキストと返り値に関する更なる詳細については
680		L<threads/"$thr->join()"> と L<threads/"THREAD CONTEXT"> を~~参照してください。~~
	680	L<< threads/"$thr->join()" >> と L<threads/"THREAD CONTEXT"> を
	681	参照してください。
681	682
682	683	=head2 Ignoring A Thread
683	684
684	685	(スレッドを無視する)
685	686
686	687	=begin original
687	688
688	689	C<join()> does three things: it waits for a thread to exit, cleans up
689	690	after it, and returns any data the thread may have produced. But what
690	691	if you're not interested in the thread's return values, and you don't
691	692	really care when the thread finishes? All you want is for the thread
692	693	to get cleaned up after when it's done.
693	694
694	695	=end original
695	696
696		C<join()> は三つのことを行います。
	697	C<join()> は三つのことを行います: スレッド終了の待機、その後の
697		~~スレッド終了の待機、その後の~~クリーンナップ、そしてスレッドが生み出したで
	698	クリーンナップ、そしてスレッドが生み出したであろうデータを返すことです。
698		あろうデータを返すことです。
699	699	しかし、スレッドの返す値に関心がなく、いつスレッドが終了するのかを本当に
700	700	気にしない場合には?
701	701	必要なのは仕事がなされた後にスレッドがクリーンナップされることです。
702	702
703	703	=begin original
704	704
705	705	In this case, you use the C<detach()> method. Once a thread is detached,
706	706	it'll run until it's finished; then Perl will clean up after it
707	707	automatically.
708	708
709	709	=end original
710	710
711	711	このような場合、C<detach()> メソッドを使います。
712	712	ひとたびスレッドが detach されると、スレッドは終了するまで実行し続け、
713	713	そのあと Perl が自動的にクリーンナップを行います。
714	714
715	715	use threads;
716	716
717	717	my $thr = threads->create(\&sub1); # Spawn the thread
718	718
719	719	$thr->detach(); # Now we officially don't care any more
720	720
721	721	sleep(15); # Let thread run for awhile
722	722
723	723	sub sub1 {
724		$a = 0;
	724	my $count = 0;
725	725	while (1) {
726		$a++;
	726	$count++;
727		print("\$a is $a\n");
	727	print("\$count is $count\n");
728	728	sleep(1);
729	729	}
730	730	}
731	731
732	732	=begin original
733	733
734	734	Once a thread is detached, it may not be joined, and any return data
735	735	that it might have produced (if it was done and waiting for a join) is
736	736	lost.
737	737
738	738	=end original
739	739
740		一度あるスレッドが detach されたら、そのスレッドは join されないでしょう。
	740	一度あるスレッドが detach されたら、そのスレッドは join されないでしょう;
741	741	(join のために待機しても)スレッドが生成したであろうデータは失われます。
742	742
743	743	=begin original
744	744
745	745	C<detach()> can also be called as a class method to allow a thread to
746	746	detach itself:
747	747
748	748	=end original
749	749
750	750	C<detach()> はスレッドが自分自身を detach するためにクラスメソッドとしても
751	751	呼び出されます:
752	752
753	753	use threads;
754	754
755	755	my $thr = threads->create(\&sub1);
756	756
757	757	sub sub1 {
758	758	threads->detach();
759	759	# Do more work
760	760	}
761	761
762	762	=head2 Process and Thread Termination
763	763
764	764	(プロセスとスレッドの終了)
765	765
766	766	=begin original
767	767
768	768	With threads one must be careful to make sure they all have a chance to
769	769	run to completion, assuming that is what you want.
770	770
771	771	=end original
772	772
773	773	スレッドを使う場合は、全てのスレッドが確実に完全に実行される(それが
774	774	あなたの望むもののはずです)ように注意しなければなりません。
775	775
776	776	=begin original
777	777
778	778	An action that terminates a process will terminate I<all> running
779	779	threads. die() and exit() have this property,
780	780	and perl does an exit when the main thread exits,
781	781	perhaps implicitly by falling off the end of your code,
782	782	even if that's not what you want.
783	783
784	784	=end original
785	785
786	786	プロセスを終了させる行動は実行中の I<全ての> スレッドを終了させます。
787	787	die() と exit() はこの性質を持ち、(あなたが望んでいないとしても)
788	788	おそらくは暗黙のうちにコードの最後に到達することによってメインスレッドが
789	789	終了すると、perl は終了します。
790	790
791	791	=begin original
792	792
793	793	As an example of this case, this code prints the message
794	794	"Perl exited with active threads: 2 running and unjoined":
795	795
796	796	=end original
797	797
798	798	この場合の例として、このコードは
799	799	"Perl exited with active threads: 2 running and unjoined" というメッセージを
800	800	表示します:
801	801
802	802	use threads;
803	803	my $thr1 = threads->new(\&thrsub, "test1");
804	804	my $thr2 = threads->new(\&thrsub, "test2");
805	805	sub thrsub {
806	806	my ($message) = @_;
807	807	sleep 1;
808	808	print "thread $message\n";
809	809	}
810	810
811	811	=begin original
812	812
813	813	But when the following lines are added at the end:
814	814
815	815	=end original
816	816
817	817	しかし以下の行が最後に追加されると:
818	818
819	819	$thr1->join();
820	820	$thr2->join();
821	821
822	822	=begin original
823	823
824	824	it prints two lines of output, a perhaps more useful outcome.
825	825
826	826	=end original
827	827
828	828	2 行の出力があり、おそらくより有用な成果となります。
829	829
830	830	=head1 Threads And Data
831	831
832	832	(スレッドとデータ)
833	833
834	834	=begin original
835	835
836	836	Now that we've covered the basics of threads, it's time for our next
837	837	topic: Data. Threading introduces a couple of complications to data
838	838	access that non-threaded programs never need to worry about.
839	839
840	840	=end original
841	841
842		これでスレッドの基本部分については見終わりました。
	842	これでスレッドの基本部分については見終わりました; 次の話題はデータです。
843		次の話題はデータです。
844	843	スレッドを扱うと、非スレッドプログラムが決して心配することのなかった
845	844	データアクセスに対する二つの複雑さを導入することになります。
846	845
847	846	=head2 Shared And Unshared Data
848	847
849	848	(共有データと非共有データ)
850	849
851	850	=begin original
852	851
853	852	The biggest difference between Perl I<ithreads> and the old 5.005 style
854	853	threading, or for that matter, to most other threading systems out there,
855	854	is that by default, no data is shared. When a new Perl thread is created,
856	855	all the data associated with the current thread is copied to the new
857	856	thread, and is subsequently private to that new thread!
858		This is similar in feel to what happens when a U~~NIX~~ process forks,
	857	This is similar in feel to what happens when a Unix process forks,
859	858	except that in this case, the data is just copied to a different part of
860	859	memory within the same process rather than a real fork taking place.
861	860
862	861	=end original
863	862
864	863	I<iスレッド> と古い 5.005 型スレッドの間の(もっといえば、そこから外れる
865	864	多くのスレッドシステムにとっての)最大の違いは、デフォルトではデータが
866	865	共有されないという点です。
867	866	新しい Perl スレッドが生成されるとき、現在のスレッドに関連する全てのデータは
868		新しいスレッドにコピーされます。
	867	新しいスレッドにコピーされます; 続いてそのデータは新しいスレッド内で
869		~~続いてそのデータは新しいスレッド内で~~プライベートなものとなります!
	868	プライベートなものとなります!
870		これは U~~NIX~~ のプロセスが fork するときに起きることと似ています。
	869	これは Unix のプロセスが fork するときに起きることと似ています;
871	870	ただしこの場合、実際の fork ではメモリ上での置き換えが起こるのに対して、この
872	871	データは同一プロセッサ内の違うメモリ部分にコピーされるだけであるという点が
873	872	除かれます。
874	873
875	874	=begin original
876	875
877	876	To make use of threading, however, one usually wants the threads to share
878	877	at least some data between themselves. This is done with the
879	878	L<threads::shared> module and the C<:shared> attribute:
880	879
881	880	=end original
882	881
883	882	しかしスレッド機能を利用するならば、通常はスレッド間で少なくともいくつかの
884	883	データを共有したいものです。
885	884	これは L<threads::shared> モジュールと C<:shared> 属性によって行われます:
886	885
887	886	use threads;
888	887	use threads::shared;
889	888
890	889	my $foo :shared = 1;
891	890	my $bar = 1;
892	891	threads->create(sub { $foo++; $bar++; })->join();
893	892
894	893	print("$foo\n"); # Prints 2 since $foo is shared
895	894	print("$bar\n"); # Prints 1 since $bar is not shared
896	895
897	896	=begin original
898	897
899	898	In the case of a shared array, all the array's elements are shared, and for
900	899	a shared hash, all the keys and values are shared. This places
901	900	restrictions on what may be assigned to shared array and hash elements: only
902	901	simple values or references to shared variables are allowed - this is
903	902	so that a private variable can't accidentally become shared. A bad
904	903	assignment will cause the thread to die. For example:
905	904
906	905	=end original
907	906
908		共有化された配列の場合は、配列の要素全てが共有化されます。
	907	共有化された配列の場合は、配列の要素全てが共有化されます;
909	908	共有化されたハッシュの場合、全てのキーと値が共有されます。
910	909	共有化された配列やハッシュの要素に代入するものに対しては制限があります:
911		単純な値や共有化された変数へのリファレンスは可能です。
	910	単純な値や共有化された変数へのリファレンスは可能です - これは、
912		~~これは、~~プライベート変数が図らずも共有化されることがないからです。
	911	プライベート変数が図らずも共有化されることがないからです。
913	912	不正な代入はスレッドを殺してしまうでしょう。
914	913	例えば:
915	914
916	915	use threads;
917	916	use threads::shared;
918	917
919	918	my $var = 1;
920	919	my $svar :shared = 2;
921	920	my %hash :shared;
922	921
923	922	... create some threads ...
924	923
925	924	=begin original
926	925
927		$hash{a} = 1; # All threads see exists($hash{a}) ~~and $hash{a} == 1~~
	926	$hash{a} = 1; # All threads see exists($hash{a})
	927	# and $hash{a} == 1
928	928	$hash{a} = $var; # okay - copy-by-value: same effect as previous
929	929	$hash{a} = $svar; # okay - copy-by-value: same effect as previous
930	930	$hash{a} = \$svar; # okay - a reference to a shared variable
931	931	$hash{a} = \$var; # This will die
932	932	delete($hash{a}); # okay - all threads will see !exists($hash{a})
933	933
934	934	=end original
935	935
936		$hash{a} = 1; # どのスレッドからも exists($hash{a}) ~~and $hash{a} == 1~~
	936	$hash{a} = 1; # どのスレッドからも exists($hash{a})
937		$hash{a} = ~~$var; # OK、値のコピー。効果は上に同じ。~~
	937	# and $hash{a} == 1
938		$hash{a} = $svar; # OK、値のコピー。効果は上に同じ。
	938	$hash{a} = $var; # OK、値のコピー: 効果は上に同じ
939		$hash{a} = \$svar; # OK、~~共有変数へ~~の~~リファレンス。~~
	939	$hash{a} = $svar; # OK、値のコピー: 効果は上に同じ
	940	$hash{a} = \$svar; # OK、共有変数へのリファレンス
940	941	$hash{a} = \$var; # これは die する
941	942	delete($hash{a}); # OK、どのスレッドからも !exists($hash{a})
942	943
943	944	=begin original
944	945
945	946	Note that a shared variable guarantees that if two or more threads try to
946	947	modify it at the same time, the internal state of the variable will not
947	948	become corrupted. However, there are no guarantees beyond this, as
948	949	explained in the next section.
949	950
950	951	=end original
951	952
952	953	共有変数が、複数のスレッドが同時にその変数に変更を加えようとしても、
953	954	変数の内部状態は破壊されないことを保証していることに注意してください。
954	955	しかし次のセクションで説明するように、ここを超えてしまうと保証は
955	956	なくなってしまいます。
956	957
957	958	=head2 Thread Pitfalls: Races
958	959
959	960	(スレッドの落とし穴: 競合)
960	961
961	962	=begin original
962	963
963	964	While threads bring a new set of useful tools, they also bring a
964	965	number of pitfalls. One pitfall is the race condition:
965	966
966	967	=end original
967	968
968	969	スレッドは新しい便利なツールを一揃いもたらしてくれる一方で、たくさんの
969	970	落とし穴ももたらします。
970	971	その一つは競合条件です:
971	972
972	973	use threads;
973	974	use threads::shared;
974	975
975		my $a :shared = 1;
	976	my $x :shared = 1;
976	977	my $thr1 = threads->create(\&sub1);
977	978	my $thr2 = threads->create(\&sub2);
978	979
979	980	$thr1->join();
980	981	$thr2->join();
981		print("$a\n");
	982	print("$x\n");
982	983
983		sub sub1 { my $foo = $a; $a = $foo + 1; }
	984	sub sub1 { my $foo = $x; $x = $foo + 1; }
984		sub sub2 { my $bar = $a; $a = $bar + 1; }
	985	sub sub2 { my $bar = $x; $x = $bar + 1; }
985	986
986	987	=begin original
987	988
988		What do you think C<$a> will be? The answer, unfortunately, is I<it
	989	What do you think C<$x> will be? The answer, unfortunately, is I<it
989		depends>. Both C<sub1()> and C<sub2()> access the global variable C<$a>, once
	990	depends>. Both C<sub1()> and C<sub2()> access the global variable C<$x>, once
990	991	to read and once to write. Depending on factors ranging from your
991	992	thread implementation's scheduling algorithm to the phase of the moon,
992		C<$a> can be 2 or 3.
	993	C<$x> can be 2 or 3.
993	994
994	995	=end original
995	996
996		C<$a> はどうなるでしょうか?
	997	C<$x> はどうなるでしょうか?
997	998	残念ながら、その答えは I<場合によりけり> です。
998	999	C<sub1()> と C<sub2()> はどちらも一度だけ読み込み、一度だけ書き込むために
999		グローバル変数 C<$a> にアクセスします。
	1000	グローバル変数 C<$x> にアクセスします。
1000	1001	あなたの使っているスレッド実装のスケジューリングアルゴリズムから月の
1001		満ち欠けまでの種々の要因によって、C<$a> は 2 にも 3 にもなりえます。
	1002	満ち欠けまでの種々の要因によって、C<$x> は 2 にも 3 にもなりえます。
1002	1003
1003	1004	=begin original
1004	1005
1005	1006	Race conditions are caused by unsynchronized access to shared
1006	1007	data. Without explicit synchronization, there's no way to be sure that
1007	1008	nothing has happened to the shared data between the time you access it
1008	1009	and the time you update it. Even this simple code fragment has the
1009	1010	possibility of error:
1010	1011
1011	1012	=end original
1012	1013
1013	1014	競合条件は共有データに対して非同期なアクセスを行うことによって生じます。
1014	1015	明示的に同期をとらない限り、アクセスして更新するまでの間に
1015	1016	共有データに何も起こらないことを確実にする方法はありません。
1016	1017	こんな単純なコードでさえ、エラーの可能性があります:
1017	1018
1018	1019	use threads;
1019		my $a :shared = 2;
	1020	my $x :shared = 2;
1020		my $b :shared;
	1021	my $y :shared;
1021		my $c :shared;
	1022	my $z :shared;
1022		my $thr1 = threads->create(sub { $b = $a; $a = $b + 1; });
	1023	my $thr1 = threads->create(sub { $y = $x; $x = $y + 1; });
1023		my $thr2 = threads->create(sub { $c = $a; $a = $c + 1; });
	1024	my $thr2 = threads->create(sub { $z = $x; $x = $z + 1; });
1024	1025	$thr1->join();
1025	1026	$thr2->join();
1026	1027
1027	1028	=begin original
1028	1029
1029		Two threads both access C<$a>. Each thread can potentially be interrupted
	1030	Two threads both access C<$x>. Each thread can potentially be interrupted
1030		at any point, or be executed in any order. At the end, C<$a> could be 3
	1031	at any point, or be executed in any order. At the end, C<$x> could be 3
1031		or 4, and both C<$b> and C<$c> could be 2 or 3.
	1032	or 4, and both C<$y> and C<$z> could be 2 or 3.
1032	1033
1033	1034	=end original
1034	1035
1035		二つのスレッドが C<$a> にアクセスします。
	1036	二つのスレッドが C<$x> にアクセスします。
1036	1037	それぞれのスレッドはいずれかの時点で割り込まれたり、いずれかの順番で
1037	1038	実行される可能性があります。
1038		結局、C<$a> は 3 か 4 に、C<$b> と C<$c> はともに 2 か 3 になるでしょう。
	1039	結局、C<$x> は 3 か 4 に、C<$y> と C<$z> はともに 2 か 3 になるでしょう。
1039	1040
1040	1041	=begin original
1041	1042
1042		Even C<$a += 5> or C<$a++> are not guaranteed to be atomic.
	1043	Even C<$x += 5> or C<$x++> are not guaranteed to be atomic.
1043	1044
1044	1045	=end original
1045	1046
1046		C<$a += 5> や C<$a++> でさえ、アトミックな演算であることを保証されません。
	1047	C<$x += 5> や C<$x++> でさえ、アトミックな演算であることを保証されません。
1047	1048
1048	1049	=begin original
1049	1050
1050	1051	Whenever your program accesses data or resources that can be accessed
1051	1052	by other threads, you must take steps to coordinate access or risk
1052	1053	data inconsistency and race conditions. Note that Perl will protect its
1053	1054	internals from your race conditions, but it won't protect you from you.
1054	1055
1055	1056	=end original
1056	1057
1057	1058	他のスレッドによってアクセスされる可能性のあるデータやリソースにあなたの
1058	1059	プログラムがアクセスするときはいつでも、整合的なアクセスのための手順を
1059	1060	踏まなければなりません。
1060	1061	さもなければデータの一貫性が崩れたり、競合条件に陥るリスクを
1061	1062	負うことになります。
1062	1063
1063	1064	=head1 Synchronization and control
1064	1065
1065	1066	(同期と制御)
1066	1067
1067	1068	=begin original
1068	1069
1069	1070	Perl provides a number of mechanisms to coordinate the interactions
1070	1071	between themselves and their data, to avoid race conditions and the like.
1071	1072	Some of these are designed to resemble the common techniques used in thread
1072	1073	libraries such as C<pthreads>; others are Perl-specific. Often, the
1073	1074	standard techniques are clumsy and difficult to get right (such as
1074	1075	condition waits). Where possible, it is usually easier to use Perlish
1075	1076	techniques such as queues, which remove some of the hard work involved.
1076	1077
1077	1078	=end original
1078	1079
1079	1080	競合条件やそれに似た状態を回避するために、スレッドとデータとの間の相互作用を
1080	1081	調整する多くのメカニズムを Perl は提供します。
1081	1082	それらのうちのあるものは、C<pthreads> のようなスレッドライブラリにおいて
1082		使われる共通のテクニックに似た設計がなされています。
	1083	使われる共通のテクニックに似た設計がなされています; またあるものは Perl に
1083		~~またあるものは Perl に~~特化しています。
	1084	特化しています。
1084	1085	しばしば標準的なテクニックというものはぎこちないもので、正しく扱うには
1085	1086	難しいです。
1086	1087	可能なところでは通常、キューのような Perl 的テクニックはより簡単で、難しい
1087	1088	仕事のうちのあるものを取り除いてくれます。
1088	1089
1089	1090	=head2 Controlling access: lock()
1090	1091
1091	1092	(アクセス制御：lock())
1092	1093
1093	1094	=begin original
1094	1095
1095	1096	The C<lock()> function takes a shared variable and puts a lock on it.
1096	1097	No other thread may lock the variable until the variable is unlocked
1097	1098	by the thread holding the lock. Unlocking happens automatically
1098	1099	when the locking thread exits the block that contains the call to the
1099	1100	C<lock()> function. Using C<lock()> is straightforward: This example has
1100	1101	several threads doing some calculations in parallel, and occasionally
1101	1102	updating a running total:
1102	1103
1103	1104	=end original
1104	1105
1105	1106	C<lock()> 関数は共有変数を引数にとり、それにロックをかけます。
1106	1107	ロックを保持するスレッドによって変数のロックが解除されるまで、他のスレッドは
1107	1108	ロックをかけることができません。
1108	1109	ロックしているスレッドが C<lock()> 関数の呼び出しを含むブロックの外に出ると
1109	1110	ロックは自動的に解除されます。
1110		C<lock()> の利用は率直なやり方です。
	1111	C<lock()> の利用は率直なやり方です: この例は、ある計算を並列的に処理し、
1111		~~この例は、ある計算を並列的に処理し、~~時折その総計値を更新するいくつかの
	1112	時折その総計値を更新するいくつかのスレッドを伴っています:
1112		スレッドを伴っています:
1113	1113
1114	1114	use threads;
1115	1115	use threads::shared;
1116	1116
1117	1117	my $total :shared = 0;
1118	1118
1119	1119	sub calc {
1120	1120	while (1) {
1121	1121	my $result;
1122	1122	# (... do some calculations and set $result ...)
1123	1123	{
1124	1124	lock($total); # Block until we obtain the lock
1125	1125	$total += $result;
1126	1126	} # Lock implicitly released at end of scope
1127	1127	last if $result == 0;
1128	1128	}
1129	1129	}
1130	1130
1131	1131	my $thr1 = threads->create(\&calc);
1132	1132	my $thr2 = threads->create(\&calc);
1133	1133	my $thr3 = threads->create(\&calc);
1134	1134	$thr1->join();
1135	1135	$thr2->join();
1136	1136	$thr3->join();
1137	1137	print("total=$total\n");
1138	1138
1139	1139	=begin original
1140	1140
1141	1141	C<lock()> blocks the thread until the variable being locked is
1142	1142	available. When C<lock()> returns, your thread can be sure that no other
1143	1143	thread can lock that variable until the block containing the
1144	1144	lock exits.
1145	1145
1146	1146	=end original
1147	1147
1148	1148	ロックされている変数が利用可能になるまで、C<lock()> はそのスレッドを
1149	1149	ブロックします。
1150	1150	C<lock()> が戻ってくると、そのロックが存在しているブロックの外に出ない限り、
1151	1151	他のスレッドがその変数をロックできないことが確実になります。
1152	1152
1153	1153	=begin original
1154	1154
1155	1155	It's important to note that locks don't prevent access to the variable
1156	1156	in question, only lock attempts. This is in keeping with Perl's
1157	1157	longstanding tradition of courteous programming, and the advisory file
1158	1158	locking that C<flock()> gives you.
1159	1159
1160	1160	=end original
1161	1161
1162	1162	ロックは問題の変数にアクセスするのを阻止するのではなくて、ロックの試みを
1163	1163	阻止するということに注意することが重要です。
1164	1164	これは Perl の長年にわたる作法どおりのプログラミングの伝統と、flock() が
1165	1165	提供する勧告ロックとに調和するものです。
1166	1166
1167	1167	=begin original
1168	1168
1169	1169	You may lock arrays and hashes as well as scalars. Locking an array,
1170	1170	though, will not block subsequent locks on array elements, just lock
1171	1171	attempts on the array itself.
1172	1172
1173	1173	=end original
1174	1174
1175	1175	スカラ変数同様、配列やハッシュにもロックをかけるかもしれません。
1176	1176	しかし、配列へのロックは、配列の要素に対する二次的なロックを
1177	1177	ブロックするのではなく、配列そのものへのロックの試みをブロックします。
1178	1178
1179	1179	=begin original
1180	1180
1181	1181	Locks are recursive, which means it's okay for a thread to
1182	1182	lock a variable more than once. The lock will last until the outermost
1183	1183	C<lock()> on the variable goes out of scope. For example:
1184	1184
1185	1185	=end original
1186	1186
1187	1187	ロックは再帰的、つまりスレッドはある変数に対し何度もロックをかけて大丈夫です。
1188	1188	一番外側の C<lock()> がスコープを抜けるまでロックは続きます。
1189	1189	例えば:
1190	1190
1191	1191	my $x :shared;
1192	1192	doit();
1193	1193
1194	1194	sub doit {
1195	1195	{
1196	1196	{
1197	1197	lock($x); # Wait for lock
1198	1198	lock($x); # NOOP - we already have the lock
1199	1199	{
1200	1200	lock($x); # NOOP
1201	1201	{
1202	1202	lock($x); # NOOP
1203	1203	lockit_some_more();
1204	1204	}
1205	1205	}
1206	1206	} # * Implicit unlock here *
1207	1207	}
1208	1208	}
1209	1209
1210	1210	sub lockit_some_more {
1211	1211	lock($x); # NOOP
1212	1212	} # Nothing happens here
1213	1213
1214	1214	=begin original
1215	1215
1216	1216	Note that there is no C<unlock()> function - the only way to unlock a
1217	1217	variable is to allow it to go out of scope.
1218	1218
1219	1219	=end original
1220	1220
1221		C<unlock()> 関数は無いことに注意してください。
	1221	C<unlock()> 関数は無いことに注意してください - 変数のロックを解除する方法は
1222		~~変数のロックを解除する方法は~~スコープを抜けさせることだけです。
	1222	スコープを抜けさせることだけです。
1223	1223
1224	1224	=begin original
1225	1225
1226	1226	A lock can either be used to guard the data contained within the variable
1227	1227	being locked, or it can be used to guard something else, like a section
1228	1228	of code. In this latter case, the variable in question does not hold any
1229	1229	useful data, and exists only for the purpose of being locked. In this
1230	1230	respect, the variable behaves like the mutexes and basic semaphores of
1231	1231	traditional thread libraries.
1232	1232
1233	1233	=end original
1234	1234
1235	1235	ロックされている変数内に保持されているデータをガードするか、あるいは
1236	1236	コードのセクションのようなものを守るために、ロックは用いられます。
1237	1237	後者の場合、問題の変数は役に立つデータを持たず、ロックの目的のためにだけ
1238	1238	存在します。
1239	1239	この点からすると、その変数は伝統的なスレッドライブラリにおける
1240	1240	ミューテックスや基本的なセマフォのような振る舞いをするといえます。
1241	1241
1242	1242	=head2 A Thread Pitfall: Deadlocks
1243	1243
1244	1244	(スレッドの落とし穴: デッドロック)
1245	1245
1246	1246	=begin original
1247	1247
1248	1248	Locks are a handy tool to synchronize access to data, and using them
1249	1249	properly is the key to safe shared data. Unfortunately, locks aren't
1250	1250	without their dangers, especially when multiple locks are involved.
1251	1251	Consider the following code:
1252	1252
1253	1253	=end original
1254	1254
1255		ロックはデータに同期アクセスするための便利なツールです。
	1255	ロックはデータに同期アクセスするための便利なツールです; 適切に使えば安全な
1256		~~適切に使えば安全な~~共有データへの鍵となります。
	1256	共有データへの鍵となります。
1257		残念なことに、ロックには危険が伴います。
	1257	残念なことに、ロックには危険が伴います; 特に複数のロックが関わると
1258		~~特に複数のロックが関わると~~そうなります。
	1258	そうなります。
1259	1259	次のコードを考えてみましょう:
1260	1260
1261	1261	use threads;
1262	1262
1263		my $a :shared = 4;
	1263	my $x :shared = 4;
1264		my $b :shared = 'foo';
	1264	my $y :shared = 'foo';
1265	1265	my $thr1 = threads->create(sub {
1266		lock($a);
	1266	lock($x);
1267	1267	sleep(20);
1268		lock($b);
	1268	lock($y);
1269	1269	});
1270	1270	my $thr2 = threads->create(sub {
1271		lock($b);
	1271	lock($y);
1272	1272	sleep(20);
1273		lock($a);
	1273	lock($x);
1274	1274	});
1275	1275
1276	1276	=begin original
1277	1277
1278	1278	This program will probably hang until you kill it. The only way it
1279	1279	won't hang is if one of the two threads acquires both locks
1280	1280	first. A guaranteed-to-hang version is more complicated, but the
1281	1281	principle is the same.
1282	1282
1283	1283	=end original
1284	1284
1285	1285	このプログラムは恐らくあなたが kill するまで固まってしまうでしょう。
1286	1286	ハングさせないための唯一の方法は、どちらかのスレッドが先に両方のロックを
1287	1287	獲得することです。
1288	1288	ハングを保証する方法はもっと複雑ですが、原理はこれと同じです。
1289	1289
1290	1290	=begin original
1291	1291
1292		The first thread will grab a lock on C<$a>, then, after a pause during which
	1292	The first thread will grab a lock on C<$x>, then, after a pause during which
1293	1293	the second thread has probably had time to do some work, try to grab a
1294		lock on C<$b>. Meanwhile, the second thread grabs a lock on C<$b>, then later
	1294	lock on C<$y>. Meanwhile, the second thread grabs a lock on C<$y>, then later
1295		tries to grab a lock on C<$a>. The second lock attempt for both threads will
	1295	tries to grab a lock on C<$x>. The second lock attempt for both threads will
1296	1296	block, each waiting for the other to release its lock.
1297	1297
1298	1298	=end original
1299	1299
1300		最初のスレッドが C<$a> のロックを手にします。
	1300	最初のスレッドが C<$x> のロックを手にします; それから二つ目のスレッドが
1301		~~それから二つ目のスレッドが~~何かやっている間に一時停止した後、C<$b> への
	1301	何かやっている間に一時停止した後、C<$y> へのロックを手に入れようと試みます。
1302		ロックを手に~~入れようと試み~~ます。
	1302	ところが、その二つ目のスレッドは C<$y> へのロックを手にします; そして
1303		~~ところが、~~その~~二つ目のスレッドは~~ C<$b> へのロックを手にします。
	1303	その後 C<$x> のロックを手に入れようとします。
1304		そしてその後 C<$a> のロックを手に入れようとします。
1305	1304	それぞれのスレッドが、他方のスレッドのロックが開放されるの待つため、
1306	1305	二番目のロックへの試みはブロックしてしまいます。
1307	1306
1308	1307	=begin original
1309	1308
1310	1309	This condition is called a deadlock, and it occurs whenever two or
1311	1310	more threads are trying to get locks on resources that the others
1312	1311	own. Each thread will block, waiting for the other to release a lock
1313	1312	on a resource. That never happens, though, since the thread with the
1314	1313	resource is itself waiting for a lock to be released.
1315	1314
1316	1315	=end original
1317	1316
1318		この状態をデッドロックと言います。
	1317	この状態をデッドロックと言います; 二つ以上のスレッドが他スレッドの所有する
1319		~~二つ以上のスレッドが他スレッドの所有する~~リソースをロックしようと
	1318	リソースをロックしようと試みるときにはいつでも生じます。
1320		試みるときにはいつでも生じます。
1321	1319	他のスレッドがリソースへのロックを開放するのを待って、互いにスレッドが
1322	1320	ブロックします。
1323	1321	しかし、リソースを持っているスレッドが自分自身のロックの開放を待つ場合は
1324	1322	生じません。
1325	1323
1326	1324	=begin original
1327	1325
1328	1326	There are a number of ways to handle this sort of problem. The best
1329	1327	way is to always have all threads acquire locks in the exact same
1330		order. If, for example, you lock variables C<$a>, C<$b>, and C<$c>, always lock
	1328	order. If, for example, you lock variables C<$x>, C<$y>, and C<$z>, always lock
1331		C<$a> before C<$b>, and C<$b> before C<$c>. It's also best to hold on to locks for
	1329	C<$x> before C<$y>, and C<$y> before C<$z>. It's also best to hold on to locks for
1332	1330	as short a period of time to minimize the risks of deadlock.
1333	1331
1334	1332	=end original
1335	1333
1336	1334	この種の問題を扱う方法はたくさんあります。
1337	1335	最もよい方法は、常に全てのスレッドが正確に同じ順番でロックを獲得するように
1338	1336	することです。
1339		例えば、C<$a>、C<$b>、C<$c>をロックするなら、いつでも C<$b> の前に C<$a> を、
	1337	例えば、C<$x>、C<$y>、C<$z> をロックするなら、いつでも C<$y> の前に C<$x> を、
1340		そして C<$c> の前に C<$b> をロックするようにします。
	1338	そして C<$z> の前に C<$y> をロックするようにします。
1341		デッドロックの危険を最小にするために、短い時間だけロックを保持するのも~~良い手です。~~
	1339	デッドロックの危険を最小にするために、短い時間だけロックを保持するのも
	1340	良い手です。
1342	1341
1343	1342	=begin original
1344	1343
1345	1344	The other synchronization primitives described below can suffer from
1346	1345	similar problems.
1347	1346
1348	1347	=end original
1349	1348
1350	1349	下記で説明するような他のプリミティブな同期も同様な問題を抱える可能性があります。
1351	1350
1352	1351	=head2 Queues: Passing Data Around
1353	1352
1354	1353	(キュー: データの受け渡し)
1355	1354
1356	1355	=begin original
1357	1356
1358	1357	A queue is a special thread-safe object that lets you put data in one
1359	1358	end and take it out the other without having to worry about
1360	1359	synchronization issues. They're pretty straightforward, and look like
1361	1360	this:
1362	1361
1363	1362	=end original
1364	1363
1365	1364	キューとは、一方の端にデータを入れ、他方から取り出すことによって、
1366	1365	同期の問題を心配しなくてすむ、特別なスレッドセーフオブジェクトです。
1367	1366	これらは非常に素朴で、以下のようなものです:
1368	1367
1369	1368	use threads;
1370	1369	use Thread::Queue;
1371	1370
1372	1371	my $DataQueue = Thread::Queue->new();
1373	1372	my $thr = threads->create(sub {
1374	1373	while (my $DataElement = $DataQueue->dequeue()) {
1375	1374	print("Popped $DataElement off the queue\n");
1376	1375	}
1377	1376	});
1378	1377
1379	1378	$DataQueue->enqueue(12);
1380	1379	$DataQueue->enqueue("A", "B", "C");
1381	1380	sleep(10);
1382	1381	$DataQueue->enqueue(undef);
1383	1382	$thr->join();
1384	1383
1385	1384	=begin original
1386	1385
1387	1386	You create the queue with C<Thread::Queue-E<gt>new()>. Then you can
1388	1387	add lists of scalars onto the end with C<enqueue()>, and pop scalars off
1389	1388	the front of it with C<dequeue()>. A queue has no fixed size, and can grow
1390	1389	as needed to hold everything pushed on to it.
1391	1390
1392	1391	=end original
1393	1392
1394	1393	C<Thread::Queue-E<gt>new()> でキューを生成します。
1395		それから C<enqueue()> を使ってキューの
	1394	それから C<enqueue()> を使ってキューの最後にスカラのリストを追加します;
1396		最後にスカラのリストを追加します。
1397	1395	そして C<dequeue()> でキューの前方からスカラを取り出します。
1398		キューのサイズは固定していません。
	1396	キューのサイズは固定していません; キューの中に押し込められたものを保持する
1399		~~キューの中に押し込められたものを保持する~~必要に応じてサイズは成長します。
	1397	必要に応じてサイズは成長します。
1400	1398
1401	1399	=begin original
1402	1400
1403	1401	If a queue is empty, C<dequeue()> blocks until another thread enqueues
1404	1402	something. This makes queues ideal for event loops and other
1405	1403	communications between threads.
1406	1404
1407	1405	=end original
1408	1406
1409	1407	もしキューが空っぽの場合、他のスレッドが何かをキューの中に入れるまで、
1410	1408	C<dequeue()> はブロックします。
1411	1409	そのため、イベントループやスレッド間でのコミュニケーションにとって、
1412	1410	キューは理想的です。
1413	1411
1414	1412	=head2 Semaphores: Synchronizing Data Access
1415	1413
1416	1414	(セマフォ：データアクセスの同期)
1417	1415
1418	1416	=begin original
1419	1417
1420	1418	Semaphores are a kind of generic locking mechanism. In their most basic
1421	1419	form, they behave very much like lockable scalars, except that they
1422	1420	can't hold data, and that they must be explicitly unlocked. In their
1423	1421	advanced form, they act like a kind of counter, and can allow multiple
1424	1422	threads to have the I<lock> at any one time.
1425	1423
1426	1424	=end original
1427	1425
1428	1426	セマフォは包括的なロックメカニズムの一種です。
1429	1427	最も基本となる形態では、
1430	1428	セマフォはデータを持つことはできないし、明示的にロック解除されなければ
1431	1429	ならないことを除くと、ロック可能なスカラそっくりに振る舞います。
1432	1430	発展的な形態においては、一種のカウンターのように動作し、いつでも複数の
1433	1431	スレッドが I<ロック> を持つことを可能にします。
1434	1432
1435	1433	=head2 Basic semaphores
1436	1434
1437	1435	(ベーシックなセマフォ)
1438	1436
1439	1437	=begin original
1440	1438
1441	1439	Semaphores have two methods, C<down()> and C<up()>: C<down()> decrements the resource
1442	1440	count, while C<up()> increments it. Calls to C<down()> will block if the
1443	1441	semaphore's current count would decrement below zero. This program
1444	1442	gives a quick demonstration:
1445	1443
1446	1444	=end original
1447	1445
1448		セマフォは二つのメソッド、C<down()> と C<up()> を持ちます。
	1446	セマフォは二つのメソッド、C<down()> と C<up()> を持ちます: C<down()> は
1449		~~C<down()> は~~リソースのカウントを減少させ、C<up()> の方は増加させます。
	1447	リソースのカウントを減少させ、C<up()> の方は増加させます。
1450	1448	セマフォの現在のカウントが 0 を下回るようなら C<down()> の呼び出しは
1451	1449	ブロックします。
1452	1450	このプログラムは短い例です:
1453	1451
1454	1452	use threads;
1455	1453	use Thread::Semaphore;
1456	1454
1457	1455	my $semaphore = Thread::Semaphore->new();
1458	1456	my $GlobalVariable :shared = 0;
1459	1457
1460	1458	$thr1 = threads->create(\&sample_sub, 1);
1461	1459	$thr2 = threads->create(\&sample_sub, 2);
1462	1460	$thr3 = threads->create(\&sample_sub, 3);
1463	1461
1464	1462	sub sample_sub {
1465	1463	my $SubNumber = shift(@_);
1466	1464	my $TryCount = 10;
1467	1465	my $LocalCopy;
1468	1466	sleep(1);
1469	1467	while ($TryCount--) {
1470	1468	$semaphore->down();
1471	1469	$LocalCopy = $GlobalVariable;
1472		print("$TryCount tries left for sub $SubNumber ~~(\$GlobalVariable is $GlobalVariable)\n~~");
	1470	print("$TryCount tries left for sub $SubNumber "
	1471	."(\$GlobalVariable is $GlobalVariable)\n");
1473	1472	sleep(2);
1474	1473	$LocalCopy++;
1475	1474	$GlobalVariable = $LocalCopy;
1476	1475	$semaphore->up();
1477	1476	}
1478	1477	}
1479	1478
1480	1479	$thr1->join();
1481	1480	$thr2->join();
1482	1481	$thr3->join();
1483	1482
1484	1483	=begin original
1485	1484
1486	1485	The three invocations of the subroutine all operate in sync. The
1487	1486	semaphore, though, makes sure that only one thread is accessing the
1488	1487	global variable at once.
1489	1488
1490	1489	=end original
1491	1490
1492	1491	このサブルーチンに対する三つの呼び出しは同時に作用します。
1493	1492	しかし一度に一つのスレッドだけが、グローバル変数にアクセスすることを
1494	1493	セマフォが保証します。
1495	1494
1496	1495	=head2 Advanced Semaphores
1497	1496
1498	1497	(高度なセマフォ)
1499	1498
1500	1499	=begin original
1501	1500
1502	1501	By default, semaphores behave like locks, letting only one thread
1503	1502	C<down()> them at a time. However, there are other uses for semaphores.
1504	1503
1505	1504	=end original
1506	1505
1507		デフォルトでは、セマフォはロックのように振舞います。
	1506	デフォルトでは、セマフォはロックのように振舞います; 一度にただ一つの
1508		~~一度にただ一つの~~スレッドだけが C<down()> できます。
	1507	スレッドだけが C<down()> できます。
1509	1508	しかし、セマフォには別の使い方があります。
1510	1509
1511	1510	=begin original
1512	1511
1513	1512	Each semaphore has a counter attached to it. By default, semaphores are
1514	1513	created with the counter set to one, C<down()> decrements the counter by
1515	1514	one, and C<up()> increments by one. However, we can override any or all
1516	1515	of these defaults simply by passing in different values:
1517	1516
1518	1517	=end original
1519	1518
1520	1519	それぞれのセマフォは、関連付けられたカウンタを持ちます。
1521		デフォルトでセマフォは生成時、カウンタに 1 がセットされます。
	1520	デフォルトでセマフォは生成時、カウンタに 1 がセットされます; C<down()> は
1522		~~C<down()> は~~カウンタから 1 を引き、C<up()> は 1 を足します。
	1521	カウンタから 1 を引き、C<up()> は 1 を足します。
1523	1522	しかしこの規定値の一部ないしは全部を別の値でもって上書きできます:
1524	1523
1525	1524	use threads;
1526	1525	use Thread::Semaphore;
1527	1526
1528	1527	my $semaphore = Thread::Semaphore->new(5);
1529	1528	# Creates a semaphore with the counter set to five
1530	1529
1531	1530	my $thr1 = threads->create(\&sub1);
1532	1531	my $thr2 = threads->create(\&sub1);
1533	1532
1534	1533	sub sub1 {
1535	1534	$semaphore->down(5); # Decrements the counter by five
1536	1535	# Do stuff here
1537	1536	$semaphore->up(5); # Increment the counter by five
1538	1537	}
1539	1538
1540	1539	$thr1->detach();
1541	1540	$thr2->detach();
1542	1541
1543	1542	=begin original
1544	1543
1545	1544	If C<down()> attempts to decrement the counter below zero, it blocks until
1546	1545	the counter is large enough. Note that while a semaphore can be created
1547	1546	with a starting count of zero, any C<up()> or C<down()> always changes the
1548	1547	counter by at least one, and so C<< $semaphore->down(0) >> is the same as
1549	1548	C<< $semaphore->down(1) >>.
1550	1549
1551	1550	=end original
1552	1551
1553	1552	もしも C<down()> がカウンタを 0 より小さい値に下げようとするなら、
1554	1553	カウンタが十分な大きさになるまでブロックします。
1555	1554	セマフォはカウンタの値を 0 にして生成することができる一方、C<up()> や
1556		C<down()> は常に、少なくとも 1 の変化をカウンタに対して行う~~ことに~~
	1555	C<down()> は常に、少なくとも 1 の変化をカウンタに対して行うので、
	1556	C<< $semaphore->down(0) >> は C<< $semaphore->down(1) >> と同じであることに
1557	1557	注意してください。
1558		だから、C<< $semaphore->down(0) >> は C<< $semaphore->down(1) >> と同じです。
1559	1558
1560	1559	=begin original
1561	1560
1562	1561	The question, of course, is why would you do something like this? Why
1563	1562	create a semaphore with a starting count that's not one, or why
1564	1563	decrement or increment it by more than one? The answer is resource
1565	1564	availability. Many resources that you want to manage access for can be
1566	1565	safely used by more than one thread at once.
1567	1566
1568	1567	=end original
1569	1568
1570	1569	もちろん、問題はどうしてこんなことをするのかということです。
1571	1570	なぜセマフォを 1 ではなくて、0 から始めるように生成するのでしょうか?
1572	1571	あるいは、なぜ 1 より大きい値で増減を行うのでしょうか？
1573	1572	その答えはリソースの利用可能性です。
1574	1573	あなたがアクセス管理をしたいリソースの多くは、同時に一つを超える数の
1575	1574	スレッドによって安全に利用されます。
1576	1575
1577	1576	=begin original
1578	1577
1579	1578	For example, let's take a GUI driven program. It has a semaphore that
1580	1579	it uses to synchronize access to the display, so only one thread is
1581	1580	ever drawing at once. Handy, but of course you don't want any thread
1582	1581	to start drawing until things are properly set up. In this case, you
1583	1582	can create a semaphore with a counter set to zero, and up it when
1584	1583	things are ready for drawing.
1585	1584
1586	1585	=end original
1587	1586
1588	1587	例として GUI 駆動型のプログラムを取り上げてみましょう。
1589		プログラムは、ディスプレイに同期アクセスするためにセマフォを持っています。
	1588	プログラムは、ディスプレイに同期アクセスするためにセマフォを持っています;
1590	1589	そうして一度にただ一つのスレッドだけが描画を行っています。
1591	1590	簡単な話ですが、もちろん、ちゃんと準備ができるまでどのスレッドにも描画を
1592	1591	始めてもらいたくはありません。
1593		こんな場合に、カウンタを 0 にしてセマフォを生成するのです。
	1592	こんな場合に、カウンタを 0 にしてセマフォを生成するのです; そして描画の
1594		~~そして描画の~~準備ができたら、カウンタを増加させます。
	1593	準備ができたら、カウンタを増加させます。
1595	1594
1596	1595	=begin original
1597	1596
1598	1597	Semaphores with counters greater than one are also useful for
1599	1598	establishing quotas. Say, for example, that you have a number of
1600	1599	threads that can do I/O at once. You don't want all the threads
1601	1600	reading or writing at once though, since that can potentially swamp
1602		your I/O channels, or deplete your process' quota of filehandles. You
	1601	your I/O channels, or deplete your process's quota of filehandles. You
1603	1602	can use a semaphore initialized to the number of concurrent I/O
1604	1603	requests (or open files) that you want at any one time, and have your
1605	1604	threads quietly block and unblock themselves.
1606	1605
1607	1606	=end original
1608	1607
1609	1608	1 より大きいカウンタを持つセマフォはクォータの確立にも役立ちます。
1610	1609	例えば、同時に I/O を使うスレッドがいくつもあるとします。
1611		だが、全てのスレッドが同時に読み書きをするのは望みません。
	1610	だが、全てのスレッドが同時に読み書きをするのは望みません;
1612	1611	そんなことをしたら I/O チャンネルを圧迫するかもしれないし、プロセスに
1613	1612	割り当てられたファイルハンドルを枯渇させてしまうかもしれないからです。
1614	1613	あなたがいつでも必要とし、スレッドに暗黙にブロック・アンブロックを
1615	1614	させたいだけの同時 I/O リクエスト数(あるいはオープンファイル数)で
1616	1615	初期設定されたセマフォを利用すればよいです。
1617	1616
1618	1617	=begin original
1619	1618
1620	1619	Larger increments or decrements are handy in those cases where a
1621	1620	thread needs to check out or return a number of resources at once.
1622	1621
1623	1622	=end original
1624	1623
1625	1624	あるスレッドが一度にたくさんのリソースを借りたり戻したりするような
1626	1625	こういうケースでは、大きな数で増減を行うのが便利です。
1627	1626
1628	1627	=head2 Waiting for a Condition
1629	1628
1630	1629	(条件を待つ)
1631	1630
1632	1631	=begin original
1633	1632
1634	1633	The functions C<cond_wait()> and C<cond_signal()>
1635	1634	can be used in conjunction with locks to notify
1636	1635	co-operating threads that a resource has become available. They are
1637	1636	very similar in use to the functions found in C<pthreads>. However
1638	1637	for most purposes, queues are simpler to use and more intuitive. See
1639	1638	L<threads::shared> for more details.
1640	1639
1641	1640	=end original
1642	1641
1643	1642	関数 C<cond_wait()> と C<cond_signal()> は、ロックが同時発生する時に、
1644	1643	リソースが利用可能になった協調型スレッドに通知を行うために用います。
1645	1644	これらは、C<pthreads> にある関数とよく似ています。
1646	1645	しかしほとんどの目的において、キューの方がより単純で直感的です。
1647	1646	更なる詳細は L<threads::shared> を参照してください。
1648	1647
1649	1648	=head2 Giving up control
1650	1649
1651	1650	(制御の明け渡し)
1652	1651
1653	1652	=begin original
1654	1653
1655	1654	There are times when you may find it useful to have a thread
1656	1655	explicitly give up the CPU to another thread. You may be doing something
1657	1656	processor-intensive and want to make sure that the user-interface thread
1658	1657	gets called frequently. Regardless, there are times that you might want
1659	1658	a thread to give up the processor.
1660	1659
1661	1660	=end original
1662	1661
1663	1662	あるスレッドが明示的に他のスレッドへと CPU を譲り渡せられたら便利だと
1664	1663	思うことがあるでしょう。
1665	1664	あなたはプロセッサ集約的なことをしようとしているかもしれませんし、
1666	1665	ユーザーインターフェース担当のスレッドが呼び出されることを確認したいと
1667	1666	思うかもしれません。
1668	1667	とにかく、スレッドがプロセッサを明け渡せたら、ということがよくあります。
1669	1668
1670	1669	=begin original
1671	1670
1672	1671	Perl's threading package provides the C<yield()> function that does
1673	1672	this. C<yield()> is pretty straightforward, and works like this:
1674	1673
1675	1674	=end original
1676	1675
1677	1676	Perl のスレッドパッケージはこれを実現する C<yield()> 関数を提供しています。
1678	1677	C<yield()> はとても素朴で、このように動作します:
1679	1678
1680	1679	use threads;
1681	1680
1682	1681	sub loop {
1683	1682	my $thread = shift;
1684	1683	my $foo = 50;
1685	1684	while($foo--) { print("In thread $thread\n"); }
1686	1685	threads->yield();
1687	1686	$foo = 50;
1688	1687	while($foo--) { print("In thread $thread\n"); }
1689	1688	}
1690	1689
1691	1690	my $thr1 = threads->create(\&loop, 'first');
1692	1691	my $thr2 = threads->create(\&loop, 'second');
1693	1692	my $thr3 = threads->create(\&loop, 'third');
1694	1693
1695	1694	=begin original
1696	1695
1697	1696	It is important to remember that C<yield()> is only a hint to give up the CPU,
1698	1697	it depends on your hardware, OS and threading libraries what actually happens.
1699	1698	B<On many operating systems, yield() is a no-op.> Therefore it is important
1700	1699	to note that one should not build the scheduling of the threads around
1701	1700	C<yield()> calls. It might work on your platform but it won't work on another
1702	1701	platform.
1703	1702
1704	1703	=end original
1705	1704
1706		C<yield()> は CPU を明け渡すためのヒントでしかありません。
	1705	C<yield()> は CPU を明け渡すためのヒントでしかありません; 実際に何が
1707		~~実際に何が~~起こるのかは、ハードウェアや OS、そしてスレッドライブラリに
	1706	起こるのかは、ハードウェアや OS、そしてスレッドライブラリに依存しています。
1708		依存しています。
1709	1707	B<多くのオペレーティングシステムにおいて、yield() は何も機能しません。>
1710	1708	それゆえ、C<yield()> を呼んでスレッドのスケジューリングをたてるべきでは
1711	1709	ないことに注意することが重要です。
1712	1710	あなたのプラットフォームでは動作したとしても、別のプラットフォームでは
1713	1711	動かないかもしれません。
1714	1712
1715	1713	=head1 General Thread Utility Routines
1716	1714
1717	1715	(一般的なスレッドユーティリティルーチン)
1718	1716
1719	1717	=begin original
1720	1718
1721	1719	We've covered the workhorse parts of Perl's threading package, and
1722	1720	with these tools you should be well on your way to writing threaded
1723	1721	code and packages. There are a few useful little pieces that didn't
1724	1722	really fit in anyplace else.
1725	1723
1726	1724	=end original
1727	1725
1728		Perlのスレッドパッケージの働き部分をみてきました。
	1726	Perlのスレッドパッケージの働き部分をみてきました; これらの道具を使い、
1729		~~これらの道具を使い、~~あなたのやり方でスレッドコードとパッケージを
	1727	あなたのやり方でスレッドコードとパッケージを書いていくことができるはずです。
1730		書いていくことができるはずです。
1731	1728	他の場所では実際にはフィットしないけれども、便利な小物も少しはあります。
1732	1729
1733	1730	=head2 What Thread Am I In?
1734	1731
1735	1732	(私はどのスレッドにいる?)
1736	1733
1737	1734	=begin original
1738	1735
1739	1736	The C<threads-E<gt>self()> class method provides your program with a way to
1740	1737	get an object representing the thread it's currently in. You can use this
1741	1738	object in the same way as the ones returned from thread creation.
1742	1739
1743	1740	=end original
1744	1741
1745	1742	C<threads-E<gt>self()> クラスメソッドを使うと、現在のスレッドを表す
1746	1743	オブジェクトを得ることができます。
1747	1744	スレッドを生成するときに返ってくるオブジェクトと同じように、この
1748	1745	オブジェクトを使うことができます。
1749	1746
1750	1747	=head2 Thread IDs
1751	1748
1752	1749	(スレッド ID)
1753	1750
1754	1751	=begin original
1755	1752
1756	1753	C<tid()> is a thread object method that returns the thread ID of the
1757	1754	thread the object represents. Thread IDs are integers, with the main
1758	1755	thread in a program being 0. Currently Perl assigns a unique TID to
1759	1756	every thread ever created in your program, assigning the first thread
1760	1757	to be created a TID of 1, and increasing the TID by 1 for each new
1761	1758	thread that's created. When used as a class method, C<threads-E<gt>tid()>
1762	1759	can be used by a thread to get its own TID.
1763	1760
1764	1761	=end original
1765	1762
1766	1763	C<tid()> はオブジェクトが表すスレッドの ID を返すメソッドです。
1767	1764	スレッド ID は整数で、プログラム中のメインスレッドは 0 です。
1768	1765	現在の Perl は、プログラム中で生成された全てのスレッドに一意な ID を
1769		つけます。
	1766	つけます; 最初に生成されたスレッドには 1 があてられ、新しいスレッドが
1770		~~最初に生成さ~~れ~~たスレッド~~には 1 があて~~られ、新し~~い~~スレッドが作られる度に~~
	1767	作られる度に ID は 1 ずつ増えていきます。
1771		ID は 1 ずつ増えていきます。
1772	1768	クラスメソッドとして使われると、C<threads-E<gt>tid()> はスレッドが自身の
1773	1769	TID を得るために使われます。
1774	1770
1775	1771	=head2 Are These Threads The Same?
1776	1772
1777	1773	(このスレッドは同じものか?)
1778	1774
1779	1775	=begin original
1780	1776
1781	1777	The C<equal()> method takes two thread objects and returns true
1782	1778	if the objects represent the same thread, and false if they don't.
1783	1779
1784	1780	=end original
1785	1781
1786	1782	C<equal()> メソッドは二つのスレッドオブジェクトを引数にとり、オブジェクトが
1787	1783	同じスレッドを示していれば真を、そうでなければ偽を返します。
1788	1784
1789	1785	=begin original
1790	1786
1791	1787	Thread objects also have an overloaded C<==> comparison so that you can do
1792	1788	comparison on them as you would with normal objects.
1793	1789
1794	1790	=end original
1795	1791
1796	1792	スレッドオブジェクトは比較演算子 C<==> をオーバーロードするので、普通の
1797	1793	オブジェクトのようにそれらを比較することもできます。
1798	1794
1799	1795	=head2 What Threads Are Running?
1800	1796
1801	1797	(どのスレッドが実行されているのか?)
1802	1798
1803	1799	=begin original
1804	1800
1805	1801	C<threads-E<gt>list()> returns a list of thread objects, one for each thread
1806	1802	that's currently running and not detached. Handy for a number of things,
1807	1803	including cleaning up at the end of your program (from the main Perl thread,
1808	1804	of course):
1809	1805
1810	1806	=end original
1811	1807
1812		C<threads-E<gt>list()> はスレッドオブジェクトのリストを返します。
	1808	C<threads-E<gt>list()> はスレッドオブジェクトのリストを返します;
1813	1809	それぞれは現在実行中で detach されていないスレッドです。
1814	1810	プログラムの終わりに(もちろん Perl のメインスレッドから)
1815	1811	クリーンナップするのも含めていろいろな点で便利です:
1816	1812
1817	1813	# Loop through all the threads
1818	1814	foreach my $thr (threads->list()) {
1819	1815	$thr->join();
1820	1816	}
1821	1817
1822	1818	=begin original
1823	1819
1824	1820	If some threads have not finished running when the main Perl thread
1825	1821	ends, Perl will warn you about it and die, since it is impossible for Perl
1826	1822	to clean up itself while other threads are running.
1827	1823
1828	1824	=end original
1829	1825
1830	1826	もしメインスレッドが終了する時に、あるスレッドが実行を終了していなかったら、
1831		Perl は警告を発し、die します。
	1827	Perl は警告を発し、die します; これは、他のスレッドが実行中の間は Perl が
1832		~~これは、他のスレッドが実行中の間は Perl が~~自分自身をクリーンナップ
	1828	自分自身をクリーンナップできないためです。
1833		できないためです。
1834	1829
1835	1830	=begin original
1836	1831
1837	1832	NOTE: The main Perl thread (thread 0) is in a I<detached> state, and so
1838	1833	does not appear in the list returned by C<threads-E<gt>list()>.
1839	1834
1840	1835	=end original
1841	1836
1842	1837	注意: Perl のメインスレッド (スレッド 0) は I<detach された> 状態にあるので、
1843	1838	C<threads-E<gt>list()> で返されるリストには現れません。
1844	1839
1845	1840	=head1 A Complete Example
1846	1841
1847	1842	(完全な例)
1848	1843
1849	1844	=begin original
1850	1845
1851	1846	Confused yet? It's time for an example program to show some of the
1852	1847	things we've covered. This program finds prime numbers using threads.
1853	1848
1854	1849	=end original
1855	1850
1856	1851	まだ混乱していますか?
1857	1852	では、サンプルプログラムを使ってこれまで見てきたことのいくつかを示す時です。
1858	1853	このプログラムはスレッドを使って素数を見つけだします。
1859	1854
1860		1 #!/usr/bin/perl
	1855	1 #!/usr/bin/perl
1861		2 # prime-pthread, courtesy of Tom Christiansen
	1856	2 # prime-pthread, courtesy of Tom Christiansen
1862		3
	1857	3
1863		4 use ~~strict~~;
	1858	4 use v5.36;
1864		5 ~~use warnings;~~
	1859	5
1865		6
	1860	6 use threads;
1866		7 use threads;
	1861	7 use Thread::Queue;
1867		8 ~~use Thread::Queue;~~
	1862	8
1868		9
	1863	9 sub check_num ($upstream, $cur_prime) {
1869		10 ~~sub~~ ~~check_nu~~m {
	1864	10 my $kid;
1870		11 my ($upstream, ~~$cu~~r~~_prim~~e) ~~= @_~~;
	1865	11 my $downstream = Thread::Queue->new();
1871		12 my $kid;
	1866	12 while (my $num = $upstream->dequeue()) {
1872		13 my ~~$dow~~nstream = Thre~~ad::Queue->new(~~);
	1867	13 next unless ($num % $cur_prime);
1873		14 ~~while~~ ~~(my~~ ~~$num~~ = $~~upstream->~~d~~equeue()~~) {
	1868	14 if ($kid) {
1874		15 next unless ($num ~~% $cur_prime~~);
	1869	15 $downstream->enqueue($num);
1875		16 if ~~($kid)~~ {
	1870	16 } else {
1876		17 ~~$dow~~nstream->e~~nqueue(~~$num);
	1871	17 print("Found prime: $num\n");
1877		18 } else {
	1872	18 $kid = threads->create(\&check_num, $downstream, $num);
1878		19 print(~~"Found~~ ~~prime:~~ $~~num\n"~~);
	1873	19 if (! $kid) {
1879		20 ~~$kid~~ = ~~thre~~a~~ds->c~~r~~eate~~(~~\&check_~~num, $do~~wns~~trea~~m, $~~num);
	1874	20 warn("Sorry. Ran out of threads.\n");
1880		21 if (! ~~$kid)~~ {
	1875	21 last;
1881		22 ~~warn("Sorry. Ran out of threads.\n");~~
	1876	22 }
1882		23 ~~last;~~
	1877	23 }
1883		24 }
	1878	24 }
1884		25 }
	1879	25 if ($kid) {
1885		26 }
	1880	26 $downstream->enqueue(undef);
1886		27 if ($kid) {
	1881	27 $kid->join();
1887		28 ~~$downstream->enqueue(undef);~~
	1882	28 }
1888		29 ~~$kid->join();~~
	1883	29 }
1889		30 }
	1884	30
1890		31 }
	1885	31 my $stream = Thread::Queue->new(3..1000, undef);
1891		32
	1886	32 check_num($stream, 2);
1892		33 my $stream = Thread::Queue->new(3..1000, undef);
1893		34 check_num($stream, 2);
1894	1887
1895	1888	=begin original
1896	1889
1897	1890	This program uses the pipeline model to generate prime numbers. Each
1898	1891	thread in the pipeline has an input queue that feeds numbers to be
1899	1892	checked, a prime number that it's responsible for, and an output queue
1900	1893	into which it funnels numbers that have failed the check. If the thread
1901	1894	has a number that's failed its check and there's no child thread, then
1902	1895	the thread must have found a new prime number. In that case, a new
1903	1896	child thread is created for that prime and stuck on the end of the
1904	1897	pipeline.
1905	1898
1906	1899	=end original
1907	1900
1908	1901	このプログラムは素数を発生させるためにパイプラインモデルを利用しています。
1909	1902	パイプラインにおけるそれぞれのスレッドは、素数を見つけるために
1910	1903	チェックされる数を渡す入力キューと、チェックに失敗した数をかき集めておく
1911	1904	出力キューとを持ちます。
1912	1905	チェックに失敗した数がスレッドにあり、かつ、子スレッドがない場合、その
1913	1906	スレッドは新しい素数を見つけたことになります。
1914	1907	この場合、新しい子スレッドはその素数のために生成され、パイプラインの後ろに
1915	1908	くっつけられます。
1916	1909
1917	1910	=begin original
1918	1911
1919	1912	This probably sounds a bit more confusing than it really is, so let's
1920	1913	go through this program piece by piece and see what it does. (For
1921	1914	those of you who might be trying to remember exactly what a prime
1922	1915	number is, it's a number that's only evenly divisible by itself and 1.)
1923	1916
1924	1917	=end original
1925	1918
1926		これは実際よりもわかりにくいかもしれません。
	1919	これは実際よりもわかりにくいかもしれません; だからこのプログラムを部分部分に
1927		~~だからこのプログラムを部分部分に~~分けて、なにをしているのかを見てみましょう。
	1920	分けて、なにをしているのかを見てみましょう。
1928	1921	(素数とは正確には何だったかということを思い出そうされている方のためにいうと、
1929	1922	自分自身と 1 でのみ割り切れる数のことです。)
1930	1923
1931	1924	=begin original
1932	1925
1933	1926	The bulk of the work is done by the C<check_num()> subroutine, which
1934	1927	takes a reference to its input queue and a prime number that it's
1935		responsible for. ~~Aft~~er ~~pulling~~ in the ~~input~~ queue and the prime that
	1928	responsible for. We create a new queue (line 11) and reserve a scalar
1936		the ~~subrou~~tine ~~is c~~he~~cking~~ (line ~~11),~~ we create a new ~~queue~~ (line 13)
	1929	for the thread that we're likely to create later (line 10).
1937		and reserve a scalar for the thread that we're likely to create later
1938		(line 12).
1939	1930
1940	1931	=end original
1941	1932
1942		作業の大半は C<check_num()> ルーチンによってなされます。
	1933	作業の大半は C<check_num()> ルーチンによってなされます; このルーチンは
1943		~~このルーチンは~~入力キューへのリファレンスとスレッドが受け持つ素数を
	1934	入力キューへのリファレンスとスレッドが受け持つ素数を引数にとります。
1944		~~引数にとり~~ます。
	1935	新しいキューを生成します(13 行目); そして、後で
1945		~~[引数~~を]入~~力キューとサブルーチンがチェックす~~る~~素数[のロー~~カル変数]に
	1936	生成するかもしれないスレッドを入れるスカラ変数を用意します(12 行目)。
1946		入れた後(11 行目)、新しいキューを生成します(13 行目)。
1947		そして、後で生成するかもしれないスレッドを入れるスカラ変数を
1948		用意します(12 行目)。
1949	1937
1950	1938	=begin original
1951	1939
1952		The while loop from line 14 to line 26 grabs a scalar off the input
	1940	The while loop from line 12 to line 24 grabs a scalar off the input
1953	1941	queue and checks against the prime this thread is responsible
1954		for. Line 15 checks to see if there's a remainder when we divide the
	1942	for. Line 13 checks to see if there's a remainder when we divide the
1955	1943	number to be checked by our prime. If there is one, the number
1956	1944	must not be evenly divisible by our prime, so we need to either pass
1957		it on to the next thread if we've created one (line 17) or create a
	1945	it on to the next thread if we've created one (line 15) or create a
1958	1946	new thread if we haven't.
1959	1947
1960	1948	=end original
1961	1949
1962		14 行目から 26 行目までの while ループで入力キューからスカラ値を
	1950	12 行目から 24 行目までの while ループで入力キューからスカラ値を
1963	1951	取り出し、このスレッドが受け持つ素数でチェックします。
1964		15 行目では、チェックされる数に対する除算を行い、余りがあるかどうかを
	1952	13 行目では、チェックされる数に対する除算を行い、余りがあるかどうかを
1965	1953	調べます。
1966	1954	もしあれば、その数は素数では割れないということなので、
1967		その数を、すでに生成してあるのであれば (17 行目) 次のスレッドに渡しますし、
	1955	その数を、すでに生成してあるのであれば (15 行目) 次のスレッドに渡しますし、
1968	1956	そうでなければ新しいスレッドを作ります。
1969	1957
1970	1958	=begin original
1971	1959
1972		The new thread creation is line 20. We pass on to it a reference to
	1960	The new thread creation is line 18. We pass on to it a reference to
1973		the queue we've created, and the prime number we've found. In lines 21
	1961	the queue we've created, and the prime number we've found. In lines 19
1974		through 24, we check to make sure that our new thread got created, and
	1962	through 22, we check to make sure that our new thread got created, and
1975	1963	if not, we stop checking any remaining numbers in the queue.
1976	1964
1977	1965	=end original
1978	1966
1979		20 行目で新しいスレッドの生成を行っています。
	1967	18 行目で新しいスレッドの生成を行っています。
1980	1968	そのスレッドに、先に作ったキューへのリファレンスと発見された素数を渡します。
1981		21 行目から 24 行目で、新しいスレッドが作成されたことを確認して、
	1969	19 行目から 22 行目で、新しいスレッドが作成されたことを確認して、
1982	1970	もし作成されていないなら、キューの残りの番号に関するチェックを
1983	1971	中止します。
1984	1972
1985	1973	=begin original
1986	1974
1987	1975	Finally, once the loop terminates (because we got a 0 or C<undef> in the
1988	1976	queue, which serves as a note to terminate), we pass on the notice to our
1989		child, and wait for it to exit if we've created a child (lines 27 and
	1977	child, and wait for it to exit if we've created a child (lines 25 and
1990		30).
	1978	28).
1991	1979
1992	1980	=end original
1993	1981
1994	1982	最後に、(キューの中に 0 か C<undef> があるかして)ループが終了すると、
1995	1983	子スレッドを作っていた場合には子スレッドに注意を促し[(undef を送る)]、
1996		実行が終了するのを待ちます(27, 30 行目)。
	1984	実行が終了するのを待ちます(25, 28 行目)。
1997	1985
1998	1986	=begin original
1999	1987
2000		Meanwhile, back in the main thread, we first create a queue (line 33) and
	1988	Meanwhile, back in the main thread, we first create a queue (line 31) and
2001	1989	queue up all the numbers from 3 to 1000 for checking, plus a termination
2002	1990	notice. Then all we have to do to get the ball rolling is pass the queue
2003		and the first prime to the C<check_num()> subroutine (line 34).
	1991	and the first prime to the C<check_num()> subroutine (line 32).
2004	1992
2005	1993	=end original
2006	1994
2007		一方、メインスレッドに戻ってみると、まずキューを生成し(33 行目)、
	1995	一方、メインスレッドに戻ってみると、まずキューを生成し(31 行目)、
2008	1996	チェックするための 3 から 1000 までの全ての数と終端マークを
2009	1997	キューに入れます。
2010	1998	それからボールを転がすために必要なことは、キューと最初の素数を
2011		C<check_num()> サブルーチンに渡すことです (~~line~~ 34)。
	1999	C<check_num()> サブルーチンに渡すことです (32 行目)。
2012	2000
2013	2001	=begin original
2014	2002
2015	2003	That's how it works. It's pretty simple; as with many Perl programs,
2016	2004	the explanation is much longer than the program.
2017	2005
2018	2006	=end original
2019	2007
2020	2008	以上が仕組みです。
2021	2009	とても単純です; 多くのPerlプログラムにとってそうであるように、
2022	2010	説明の方が当のプログラム以上にとても長くなります。
2023	2011
2024	2012	=head1 Different implementations of threads
2025	2013
2026	2014	(様々なスレッドの実装)
2027	2015
2028	2016	=begin original
2029	2017
2030	2018	Some background on thread implementations from the operating system
2031	2019	viewpoint. There are three basic categories of threads: user-mode threads,
2032	2020	kernel threads, and multiprocessor kernel threads.
2033	2021
2034	2022	=end original
2035	2023
2036	2024	オペレーティングシステムの観点からみた、スレッド実装についての背景です。
2037	2025	スレッドには三つの基本的なカテゴリーがあります: ユーザーモードスレッド、
2038	2026	カーネルスレッド、マルチプロセッサカーネルスレッドです。
2039	2027
2040	2028	=begin original
2041	2029
2042	2030	User-mode threads are threads that live entirely within a program and
2043	2031	its libraries. In this model, the OS knows nothing about threads. As
2044	2032	far as it's concerned, your process is just a process.
2045	2033
2046	2034	=end original
2047	2035
2048	2036	ユーザーモードスレッドとは、完全にプログラムとライブラリの中に存在する
2049	2037	スレッドです。
2050	2038	このモデルにおいては、OS はスレッドについて何も関知しません。
2051	2039	OS からしてみる限り、あなたのプロセスはただのひとつのプロセスです。
2052	2040
2053	2041	=begin original
2054	2042
2055	2043	This is the easiest way to implement threads, and the way most OSes
2056	2044	start. The big disadvantage is that, since the OS knows nothing about
2057	2045	threads, if one thread blocks they all do. Typical blocking activities
2058	2046	include most system calls, most I/O, and things like C<sleep()>.
2059	2047
2060	2048	=end original
2061	2049
2062	2050	これは最も簡単なスレッドの実装であり、ほとんどの OS が最初にとった方法です。
2063	2051	この方法の大きな欠点は、OS がスレッドに関知していないために、
2064	2052	もしも一つのスレッドがブロックをしたら、全てのスレッドがブロックしてしまう
2065	2053	ということです。
2066	2054	典型的なブロック行為には、ほとんどのシステムコール、ほとんどの
2067	2055	I/O、そして C<sleep()> のようなものが含まれます。
2068	2056
2069	2057	=begin original
2070	2058
2071	2059	Kernel threads are the next step in thread evolution. The OS knows
2072	2060	about kernel threads, and makes allowances for them. The main
2073	2061	difference between a kernel thread and a user-mode thread is
2074	2062	blocking. With kernel threads, things that block a single thread don't
2075	2063	block other threads. This is not the case with user-mode threads,
2076	2064	where the kernel blocks at the process level and not the thread level.
2077	2065
2078	2066	=end original
2079	2067
2080	2068	カーネルスレッドは進化の第二段階です。
2081	2069	OS はカーネルスレッドについて知っていて、その許可を出します。
2082	2070	カーネルスレッドとユーザーモードスレッドの主要な違いは、
2083	2071	ブロッキングについてです。
2084	2072	カーネルスレッドでは、一つのスレッドをブロックした事で他のスレッドまで
2085	2073	ブロックすることはありません。
2086		これはユーザーモードスレッドにおいては成り立ちません。
	2074	これはユーザーモードスレッドにおいては成り立ちません; ユーザーモードでは、
2087		~~ユーザーモードでは、~~カーネルがブロックするのはプロセスレベルであって、
	2075	カーネルがブロックするのはプロセスレベルであって、スレッドレベルでは
2088		~~スレッドレベルでは~~ないからです。
	2076	ないからです。
2089	2077
2090	2078	=begin original
2091	2079
2092	2080	This is a big step forward, and can give a threaded program quite a
2093	2081	performance boost over non-threaded programs. Threads that block
2094	2082	performing I/O, for example, won't block threads that are doing other
2095	2083	things. Each process still has only one thread running at once,
2096	2084	though, regardless of how many CPUs a system might have.
2097	2085
2098	2086	=end original
2099	2087
2100	2088	これは大きな前進であり、非スレッドプログラムに対し、スレッドプログラムが
2101	2089	大きなパフォーマンスの向上を得ることを可能にしています。
2102	2090	例えば、I/O の実行をブロックするスレッドは、他のことを行うスレッドを
2103	2091	ブロックしないでしょう。
2104	2092	しかし、システムがいくつ CPU を備えているかに関係なく、それぞれのプロセスは
2105	2093	いまだに一度に一つのスレッドしか走らせません。
2106	2094
2107	2095	=begin original
2108	2096
2109	2097	Since kernel threading can interrupt a thread at any time, they will
2110	2098	uncover some of the implicit locking assumptions you may make in your
2111		program. For example, something as simple as C<$a = $a + 2> can behave
	2099	program. For example, something as simple as C<$x = $x + 2> can behave
2112		unpredictably with kernel threads if C<$a> is visible to other
	2100	unpredictably with kernel threads if C<$x> is visible to other
2113		threads, as another thread may have changed C<$a> between the time it
	2101	threads, as another thread may have changed C<$x> between the time it
2114	2102	was fetched on the right hand side and the time the new value is
2115	2103	stored.
2116	2104
2117	2105	=end original
2118	2106
2119	2107	カーネルのスレッド制御がいつでも割り込めるので、あなたがプログラム中に
2120	2108	つくった暗黙のロックの前提が白日の下にさらけ出してしまうでしょう。
2121		例えば、C<$a = $a + 2>のような単純なものでも、C<$a> が他のスレッドから
	2109	例えば、C<$x = $x + 2>のような単純なものでも、C<$x> が他のスレッドから
2122	2110	見えるならば、右辺の値を取り出す時間と新しい値を格納する時間の間に、他の
2123		スレッドが C<$a> を変えてしまって、あなたの予期しない振る舞いをする
	2111	スレッドが C<$x> を変えてしまって、あなたの予期しない振る舞いをする
2124	2112	可能性があります。
2125	2113
2126	2114	=begin original
2127	2115
2128	2116	Multiprocessor kernel threads are the final step in thread
2129	2117	support. With multiprocessor kernel threads on a machine with multiple
2130	2118	CPUs, the OS may schedule two or more threads to run simultaneously on
2131	2119	different CPUs.
2132	2120
2133	2121	=end original
2134	2122
2135	2123	マルチプロセッサカーネルスレッドは、スレッドのサポートにおける最終段階です。
2136	2124	一台のマシンが複数の CPU を持っているマルチプロセッサカーネルスレッドでは、
2137	2125	OS は別々の CPU 上で同時に一つ以上のスレッドを走らせるようにスケジュール
2138	2126	管理をします。
2139	2127
2140	2128	=begin original
2141	2129
2142	2130	This can give a serious performance boost to your threaded program,
2143	2131	since more than one thread will be executing at the same time. As a
2144	2132	tradeoff, though, any of those nagging synchronization issues that
2145	2133	might not have shown with basic kernel threads will appear with a
2146	2134	vengeance.
2147	2135
2148	2136	=end original
2149	2137
2150	2138	一つ以上のスレッドが同時に実行するので、これによりスレッドプログラムは
2151	2139	飛躍的なパフォーマンスの向上を得ることができます。
2152	2140	しかし、引き換えに、基本的なカーネルスレッドでは現れなかったであろう
2153	2141	イライラするような同期性の問題が一気に姿を現します。
2154	2142
2155	2143	=begin original
2156	2144
2157	2145	In addition to the different levels of OS involvement in threads,
2158	2146	different OSes (and different thread implementations for a particular
2159	2147	OS) allocate CPU cycles to threads in different ways.
2160	2148
2161	2149	=end original
2162	2150
2163	2151	スレッドを備える OS の違いというレベルに加えて、それぞれの OS は(そして
2164	2152	それぞれのスレッド実装は)それぞれの方法でもって CPU サイクルをスレッドに
2165	2153	割り当てます。
2166	2154
2167	2155	=begin original
2168	2156
2169	2157	Cooperative multitasking systems have running threads give up control
2170	2158	if one of two things happen. If a thread calls a yield function, it
2171	2159	gives up control. It also gives up control if the thread does
2172	2160	something that would cause it to block, such as perform I/O. In a
2173	2161	cooperative multitasking implementation, one thread can starve all the
2174	2162	others for CPU time if it so chooses.
2175	2163
2176	2164	=end original
2177	2165
2178	2166	次の二つのうちの一つが起こる場合、協調的マルチタスクシステムは実行中の
2179	2167	スレッドに制御を明け渡させます。
2180	2168	あるスレッドがyield関数を呼び出すと、制御を明け渡します。
2181	2169	また、スレッドがI/Oの実行などのブロックを引き起こすような何かを行う場合も、
2182	2170	制御を明け渡します。
2183	2171	協調的マルチタスクシステムの実装においては、そのように選択するならば、
2184	2172	一つのスレッドが他の全てのスレッドの CPU 時間を食い尽くすことができます。
2185	2173
2186	2174	=begin original
2187	2175
2188	2176	Preemptive multitasking systems interrupt threads at regular intervals
2189	2177	while the system decides which thread should run next. In a preemptive
2190	2178	multitasking system, one thread usually won't monopolize the CPU.
2191	2179
2192	2180	=end original
2193	2181
2194	2182	プリエンティブなマルチタスクシステムは、次にどのスレッドを実行するか
2195	2183	決めながら、一定の間隔でスレッドに割り込みを入れます。
2196	2184	プリエンティブなマルチタスクシステムにおいて、通常一つのスレッドが CPU を
2197	2185	独占することはありません。
2198	2186
2199	2187	=begin original
2200	2188
2201	2189	On some systems, there can be cooperative and preemptive threads
2202	2190	running simultaneously. (Threads running with realtime priorities
2203	2191	often behave cooperatively, for example, while threads running at
2204	2192	normal priorities behave preemptively.)
2205	2193
2206	2194	=end original
2207	2195
2208	2196	いくつかのシステムでは、協調的スレッドとプリエンティブなスレッドを同時に
2209		実行することができます~~(例えば、通常のプライオリティを持ったスレッドが~~
	2197	実行することができます。
2210		~~プリエンディブに振舞うのに対して~~、~~リアルタイム~~のプライオリティを持った
	2198	(例えば、通常のプライオリティを持ったスレッドがプリエンディブに振舞うのに
2211		スレッドはしばしば協調的に~~振舞います)。~~
	2199	対して、リアルタイムのプライオリティを持ったスレッドはしばしば協調的に
	2200	振舞います。)
2212	2201
2213	2202	=begin original
2214	2203
2215	2204	Most modern operating systems support preemptive multitasking nowadays.
2216	2205
2217	2206	=end original
2218	2207
2219	2208	今では、ほとんどの近代的なOSでプリエンティブなマルチタスクを
2220	2209	サポートしています。
2221	2210
2222	2211	=head1 Performance considerations
2223	2212
2224	2213	(パフォーマンスの考慮)
2225	2214
2226	2215	=begin original
2227	2216
2228	2217	The main thing to bear in mind when comparing Perl's I<ithreads> to other threading
2229	2218	models is the fact that for each new thread created, a complete copy of
2230	2219	all the variables and data of the parent thread has to be taken. Thus,
2231	2220	thread creation can be quite expensive, both in terms of memory usage and
2232	2221	time spent in creation. The ideal way to reduce these costs is to have a
2233	2222	relatively short number of long-lived threads, all created fairly early
2234		on -- before the base thread has accumulated too much data. Of course, this
	2223	on (before the base thread has accumulated too much data). Of course, this
2235	2224	may not always be possible, so compromises have to be made. However, after
2236	2225	a thread has been created, its performance and extra memory usage should
2237	2226	be little different than ordinary code.
2238	2227
2239	2228	=end original
2240	2229
2241	2230	Perl の I<iスレッド> と他のスレッドモデルを比較する際に忘れてならないのが、
2242	2231	新しいスレッドはみな、親スレッドの変数とデータを全て完全にコピーして
2243	2232	引き渡されるという事実です。
2244	2233	そのため、メモリ使用量と実行時間の両方の点で、スレッドの生成は非常に
2245	2234	高くつきます。
2246	2235	このコストを減らす理想的な方法は、長生きなスレッドを比較的少なめに
2247		持つことです。
	2236	持つことです; このスレッドは全て (ベースとなるスレッドが非常に多くのデータを
2248		~~このスレッドは全て、ベースとなるスレッドが非常に多くのデータを~~蓄積する前に、
	2237	蓄積する前に) 適切に早い段階で生成されます。
2249		適切に早い段階で生成されます。
2250	2238	もちろん、これはいつも可能というわけではないでしょうから、妥協も必要です。
2251	2239	しかし、スレッドが生成された後は、そのパフォーマンスと追加のメモリ使用量は、
2252	2240	普通のコードのそれとほとんど違いはありません。
2253	2241
2254	2242	=begin original
2255	2243
2256	2244	Also note that under the current implementation, shared variables
2257	2245	use a little more memory and are a little slower than ordinary variables.
2258	2246
2259	2247	=end original
2260	2248
2261	2249	また、現在の実装下では、共有変数は通常の変数に比べて少し余計にメモリを
2262	2250	使用し、スピードも少し遅いことにも注意してください。
2263	2251
2264	2252	=head1 Process-scope Changes
2265	2253
2266	2254	(プロセススコープの変更)
2267	2255
2268	2256	=begin original
2269	2257
2270	2258	Note that while threads themselves are separate execution threads and
2271	2259	Perl data is thread-private unless explicitly shared, the threads can
2272	2260	affect process-scope state, affecting all the threads.
2273	2261
2274	2262	=end original
2275	2263
2276	2264	スレッドそれ自身は別々に実行され、Perl のデータは明示的に共有化しない限りは
2277	2265	スレッド内でプライベートなものです;
2278	2266	その一方、スレッドは全てのスレッドに影響を与えながら、プロセススコープの
2279	2267	状態に影響を与えてしまうことに注意してください。
2280	2268
2281	2269	=begin original
2282	2270
2283	2271	The most common example of this is changing the current working
2284	2272	directory using C<chdir()>. One thread calls C<chdir()>, and the working
2285	2273	directory of all the threads changes.
2286	2274
2287	2275	=end original
2288	2276
2289	2277	この最も一般的な例は C<chdir()> を使ったときに現在作業中のディレクトリが
2290	2278	変更されてしまうことです。
2291	2279	一つのスレッドが C<chdir()> を呼ぶと、全てのスレッドの作業ディレクトリが
2292	2280	変更されます。
2293	2281
2294	2282	=begin original
2295	2283
2296	2284	Even more drastic example of a process-scope change is C<chroot()>:
2297	2285	the root directory of all the threads changes, and no thread can
2298	2286	undo it (as opposed to C<chdir()>).
2299	2287
2300	2288	=end original
2301	2289
2302		さらに劇的なプロセススコープの変更例は C<chroot()> です。
	2290	さらに劇的なプロセススコープの変更例は C<chroot()> です: 全部のスレッドの
2303		~~全部のスレッドの~~ルートディレクトリが変更されます。
	2291	ルートディレクトリが変更されます; スレッドはそれを元に戻すことはできません
2304		~~スレッドはそれを元に戻すことはできません~~(C<chdir()> の場合は可能です)。
	2292	(C<chdir()> の場合は可能です)。
2305	2293
2306	2294	=begin original
2307	2295
2308	2296	Further examples of process-scope changes include C<umask()> and
2309	2297	changing uids and gids.
2310	2298
2311	2299	=end original
2312	2300
2313	2301	さらなるプロセススコープ変化の例は、C<umask()> および uid や gid の変更です。
2314	2302
2315	2303	=begin original
2316	2304
2317	2305	Thinking of mixing C<fork()> and threads? Please lie down and wait
2318	2306	until the feeling passes. Be aware that the semantics of C<fork()> vary
2319		between platforms. For example, some U~~NIX~~ systems copy all the current
	2307	between platforms. For example, some Unix systems copy all the current
2320	2308	threads into the child process, while others only copy the thread that
2321	2309	called C<fork()>. You have been warned!
2322	2310
2323	2311	=end original
2324	2312
2325	2313	C<fork()> とスレッドを混在させたらどうなるかって?
2326	2314	そんな気分が失せるまで、横になって休んでいてください。
2327	2315	C<fork()> の動作はプラットフォームによって異なることに注意してください。
2328		例えば、U~~NIX~~ システムには現状の全てのスレッドを子プロセスに
	2316	例えば、Unix システムには現状の全てのスレッドを子プロセスに
2329	2317	コピーするものもありますが、C<fork()> を呼び出したスレッドのみを
2330	2318	コピーするものもあります。
2331	2319	あなたは警告されました!
2332	2320
2333	2321	=begin original
2334	2322
2335	2323	Similarly, mixing signals and threads may be problematic.
2336	2324	Implementations are platform-dependent, and even the POSIX
2337	2325	semantics may not be what you expect (and Perl doesn't even
2338	2326	give you the full POSIX API). For example, there is no way to
2339	2327	guarantee that a signal sent to a multi-threaded Perl application
2340	2328	will get intercepted by any particular thread. (However, a recently
2341	2329	added feature does provide the capability to send signals between
2342		threads. See L<threads/"THREAD SIGNALLING> for more details.)
	2330	threads. See L<threads/THREAD SIGNALLING> for more details.)
2343	2331
2344	2332	=end original
2345	2333
2346	2334	同じように、シグナルとスレッドを混ぜるのもするべきではありあません。
2347	2335	実装はプラットフォーム依存だし、POSIX のセマンティクスでさえ、あなたの
2348	2336	期待通りにはならないかもしれません
2349	2337	(そして Perl はフルセットの POSIX API を提供することさえできません)。
2350	2338	例えば、マルチスレッド Perl アプリケーションに送られたシグナルが、
2351	2339	特定のスレッドによって受信されることを保証する方法はありません。
2352	2340	(しかし、最近追加された機能はスレッド間でシグナルを送る能力を提供します。
2353		更なる詳細については L<threads/"THREAD SIGNALLING> を参照してください。)
	2341	更なる詳細については L<threads/THREAD SIGNALLING> を参照してください。)
2354	2342
2355	2343	=head1 Thread-Safety of System Libraries
2356	2344
2357	2345	(システムライブラリにおけるスレッドの安全性)
2358	2346
2359		=begin original
2360	2347
2361		Whether various library calls are thread-safe is outside the control
2362		of Perl. Calls often suffering from not being thread-safe include:
2363		C<localtime()>, C<gmtime()>, functions fetching user, group and
2364		network information (such as C<getgrent()>, C<gethostent()>,
2365		C<getnetent()> and so on), C<readdir()>,
2366		C<rand()>, and C<srand()> -- in general, calls that depend on some global
2367		external state.
2368
2369		=end original
2370
2371		様々なライブラリの関数呼び出しがスレッドにとって安全かどうかということは、
2372		Perlのコントロールの埒外です。
2373		しばしばスレッドセーフではないものに
2374		よって問題の生じる呼び出しには以下のようなものです:
2375		C<localtime()>, C<gmtime()>,
2376		(C<getgrent()>, C<gethostent()>, C<getnetent()> などのような)ユーザー、
2377		グループ、ネットワークの情報を取り出す関数、C<readdir()>,
2378		C<rand()>, C<srand()> -- 一般的に言って、グローバルな外部状況に依存する
2379		呼び出しが含まれます。
2380
2381	2348	=begin original
2382	2349
2383		~~If t~~he ~~sys~~te~~m Pe~~rl is ~~compi~~led in has thread-safe ~~var~~iants of ~~such~~
	2350	Whether C library calls are thread-safe is outside the control of Perl.
2384		~~calls,~~ they will be used. ~~Bey~~on~~d that, P~~e~~rl i~~s a~~t th~~e me~~rcy~~ of
	2351	Undefined behavior will happen if unsafe ones are used during
2385		the thread~~-safety~~ or ~~-uns~~afety o~~f the calls~~. Please ~~consult your~~
	2352	multi-thread operation. See
2386		C libra~~ry ca~~ll ~~docu~~menta~~tion~~.
	2353	L<perlclib/Dealing with embedded perls and threads>.
2387	2354
2388	2355	=end original
2389	2356
2390		~~Perl~~ ~~がコンパ~~イ~~ルされたシステムが、そういった~~呼び出しのスレッドセーフな
	2357	C ライブラリの呼び出しがスレッドセーフかどうかということは、
2391		~~バージョンを持っているなら、そちらが使われま~~す。
	2358	Perl の制御の範囲外です。
2392		~~それを超えると、Perl は呼び出しが~~スレッドセーフ~~かどうかの~~な~~すがままに~~
	2359	マルチスレッド操作中にスレッドセーフでないものを使うと、
2393		なります。
	2360	未定義の振る舞いが起こります。
2394		C ~~ライブラリのドキュメント~~を~~よく吟味~~してください。
	2361	L<perlclib/Dealing with embedded perls and threads> を参照してください。
2395	2362
2396		=begin original
2397
2398		On some platforms the thread-safe library interfaces may fail if the
2399		result buffer is too small (for example the user group databases may
2400		be rather large, and the reentrant interfaces may have to carry around
2401		a full snapshot of those databases). Perl will start with a small
2402		buffer, but keep retrying and growing the result buffer
2403		until the result fits. If this limitless growing sounds bad for
2404		security or memory consumption reasons you can recompile Perl with
2405		C<PERL_REENTRANT_MAXSIZE> defined to the maximum number of bytes you will
2406		allow.
2407
2408		=end original
2409
2410		いくつかのプラットフォームでは、結果バッファが小さすぎる場合に
2411		スレッドセーフなライブラリのインターフェースが失敗を起こすかもしれません
2412		(例えば、ユーザーグループのデータベースがかなり大きく、リエントラントな
2413		インターフェースがこれらのデータベースの完全なスナップショットを
2414		もたらさなければならないような場合)。
2415		Perl は小さなバッファでスタートします。
2416		しかし結果が適合するまで結果バッファの確保を再試行し、大きくしようとします。
2417		この無制限な成長がセキュリティやメモリ消費の理由から好ましくないもので
2418		あるなら、C<PERL_REENTRANT_MAXSIZE> であなたの許す最大バイト数を定義して
2419		Perl を再コンパイルできます。
2420
2421	2363	=head1 Conclusion
2422	2364
2423	2365	(おわりに)
2424	2366
2425	2367	=begin original
2426	2368
2427	2369	A complete thread tutorial could fill a book (and has, many times),
2428	2370	but with what we've covered in this introduction, you should be well
2429	2371	on your way to becoming a threaded Perl expert.
2430	2372
2431	2373	=end original
2432	2374
2433		完全なスレッドのチュートリアルをつくると一冊の本になってしまいます。
	2375	完全なスレッドのチュートリアルをつくると一冊の本になってしまいます; しかし
2434		~~しかし~~この導入でカバーしてきたことを使って、あなたなりの方法で
	2376	この導入でカバーしてきたことを使って、あなたなりの方法でスレッド Perl の
2435		~~スレッド Perl の~~エキスパートになっていってください。
	2377	エキスパートになっていってください。
2436	2378
2437	2379	=head1 SEE ALSO
2438	2380
2439	2381	Annotated POD for L<threads>:
2440		L<http://annocpan.org/?mode=search&field=Module&name=threads>
	2382	L<https://web.archive.org/web/20171028020148/http://annocpan.org/?mode=search&field=Module&name=threads>
2441	2383
2442		Lastest version of L<threads> on CPAN:
	2384	Latest version of L<threads> on CPAN:
2443		L<http://searc~~h.c~~pan.org/~~search?m~~od~~ule=~~threads>
	2385	L<https://metacpan.org/pod/threads>
2444	2386
2445	2387	Annotated POD for L<threads::shared>:
2446		L<http://annocpan.org/?mode=search&field=Module&name=threads%3A%3Ashared>
	2388	L<https://web.archive.org/web/20171028020148/http://annocpan.org/?mode=search&field=Module&name=threads%3A%3Ashared>
2447	2389
2448		Lastest version of L<threads::shared> on CPAN:
	2390	Latest version of L<threads::shared> on CPAN:
2449		L<http://searc~~h.c~~pan.org/~~search?m~~od~~ule=~~threads~~%3A%3A~~shared>
	2391	L<https://metacpan.org/pod/threads::shared>
2450	2392
2451	2393	Perl threads mailing list:
2452		L<http://lists.cpan.org/~~show~~list~~.cg~~i~~?name=iT~~hreads>
	2394	L<https://lists.perl.org/list/ithreads.html>
2453	2395
2454	2396	=head1 Bibliography
2455	2397
2456	2398	(参考文献)
2457	2399
2458	2400	=begin original
2459	2401
2460		Here's a short bibliography courtesy of Jurgen Christoffel:
	2402	Here's a short bibliography courtesy of Jürgen Christoffel:
2461	2403
2462	2404	=end original
2463	2405
2464		Jurgen Christoffel の提供による簡潔な参考文献集：
	2406	Jürgen Christoffel の提供による簡潔な参考文献集:
2465	2407
2466	2408	=head2 Introductory Texts
2467	2409
2468	2410	(導入テキスト)
2469	2411
2470	2412	Birrell, Andrew D. An Introduction to Programming with
2471	2413	Threads. Digital Equipment Corporation, 1989, DEC-SRC Research Report
2472	2414	#35 online as
2473		http://~~gatekee~~per.~~dec~~.com/~~pub/DEC/SRC/r~~e~~sear~~ch-reports/a~~bstracts~~/~~src~~-rr-035.~~html~~
	2415	L<https://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-35.pdf>
2474	2416	(highly recommended)
2475	2417
2476	2418	Robbins, Kay. A., and Steven Robbins. Practical Unix Programming: A
2477	2419	Guide to Concurrency, Communication, and
2478	2420	Multithreading. Prentice-Hall, 1996.
2479	2421
2480	2422	Lewis, Bill, and Daniel J. Berg. Multithreaded Programming with
2481	2423	Pthreads. Prentice Hall, 1997, ISBN 0-13-443698-9 (a well-written
2482	2424	introduction to threads).
2483	2425
2484	2426	Nelson, Greg (editor). Systems Programming with Modula-3. Prentice
2485	2427	Hall, 1991, ISBN 0-13-590464-1.
2486	2428
2487	2429	Nichols, Bradford, Dick Buttlar, and Jacqueline Proulx Farrell.
2488	2430	Pthreads Programming. O'Reilly & Associates, 1996, ISBN 156592-115-1
2489	2431	(covers POSIX threads).
2490	2432
2491	2433	=head2 OS-Related References
2492	2434
2493	2435	(OS関連のリファレンス)
2494	2436
2495	2437	Boykin, Joseph, David Kirschen, Alan Langerman, and Susan
2496	2438	LoVerso. Programming under Mach. Addison-Wesley, 1994, ISBN
2497	2439	0-201-52739-1.
2498	2440
2499	2441	Tanenbaum, Andrew S. Distributed Operating Systems. Prentice Hall,
2500	2442	1995, ISBN 0-13-219908-4 (great textbook).
2501	2443
2502	2444	Silberschatz, Abraham, and Peter B. Galvin. Operating System Concepts,
2503	2445	4th ed. Addison-Wesley, 1995, ISBN 0-201-59292-4
2504	2446
2505	2447	=head2 Other References
2506	2448
2507	2449	(その他のリファレンス)
2508	2450
2509	2451	Arnold, Ken and James Gosling. The Java Programming Language, 2nd
2510	2452	ed. Addison-Wesley, 1998, ISBN 0-201-31006-6.
2511	2453
2512	2454	comp.programming.threads FAQ,
2513	2455	L<http://www.serpentine.com/~bos/threads-faq/>
2514	2456
2515	2457	Le Sergent, T. and B. Berthomieu. "Incremental MultiThreaded Garbage
2516	2458	Collection on Virtually Shared Memory Architectures" in Memory
2517	2459	Management: Proc. of the International Workshop IWMM 92, St. Malo,
2518	2460	France, September 1992, Yves Bekkers and Jacques Cohen, eds. Springer,
2519	2461	1992, ISBN 3540-55940-X (real-life thread applications).
2520	2462
2521	2463	Artur Bergman, "Where Wizards Fear To Tread", June 11, 2002,
2522	2464	L<http://www.perl.com/pub/a/2002/06/11/threads.html>
2523	2465
2524	2466	=head1 Acknowledgements
2525	2467
2526	2468	(謝辞)
2527	2469
	2470	=begin original
	2471
2528	2472	Thanks (in no particular order) to Chaim Frenkel, Steve Fink, Gurusamy
2529		Sarathy, Ilya Zakharevich, Benjamin Sugars, Jurgen Christoffel, Joshua
	2473	Sarathy, Ilya Zakharevich, Benjamin Sugars, Jürgen Christoffel, Joshua
2530	2474	Pritikin, and Alan Burlison, for their help in reality-checking and
2531	2475	polishing this article. Big thanks to Tom Christiansen for his rewrite
2532	2476	of the prime number generator.
2533	2477
	2478	=end original
	2479
	2480	現実性のチェックとこの文章の磨き上げを助けてくれた以下の人々に
	2481	感謝します (順不同) Chaim Frenkel, Steve Fink, Gurusamy
	2482	Sarathy, Ilya Zakharevich, Benjamin Sugars, Jürgen Christoffel, Joshua
	2483	Pritikin, and Alan Burlison。
	2484	素数生成器を書き直してくれた Tom Christiansen にとても感謝します。
	2485
2534	2486	=head1 AUTHOR
2535	2487
2536	2488	(著者)
2537	2489
2538		Dan Sugalski E<lt>dan@sidhe.org<gt>
	2490	Dan Sugalski E<lt>dan@sidhe.orgE<gt>
2539	2491
2540	2492	=begin original
2541	2493
2542	2494	Slightly modified by Arthur Bergman to fit the new thread model/module.
2543	2495
2544	2496	=end original
2545	2497
2546	2498	新しいスレッドモデル・モジュールに対応するように Arthur Bergman によって
2547	2499	若干の修正がなされました。
2548	2500
2549	2501	=begin original
2550	2502
2551		Reworked slightly by Jorg Walter E<lt>jwalt@cpan.org<gt> to be more concise
	2503	Reworked slightly by Jörg Walter E<lt>jwalt@cpan.orgE<gt> to be more concise
2552	2504	about thread-safety of Perl code.
2553	2505
2554	2506	=end original
2555	2507
2556	2508	Perl コードのスレッドセーフティについてより簡明になるよう
2557		Jorg Walter E<lt>jwalt@cpan.org<gt> によって改訂されました。
	2509	Jörg Walter E<lt>jwalt@cpan.orgE<gt> によって改訂されました。
2558	2510
2559	2511	=begin original
2560	2512
2561		Rearranged slightly by Elizabeth Mattijsen E<lt>liz@dijkmat.nl<gt> to put
	2513	Rearranged slightly by Elizabeth Mattijsen E<lt>liz@dijkmat.nlE<gt> to put
2562	2514	less emphasis on yield().
2563	2515
2564	2516	=end original
2565	2517
2566		Elizabeth Mattijsen E<lt>liz@dijkmat.nl<gt> によって、yield() を以前より
	2518	Elizabeth Mattijsen E<lt>liz@dijkmat.nlE<gt> によって、yield() を以前より
2567	2519	強調しないよう若干アレンジされました。
2568	2520
2569	2521	=head1 Copyrights
2570	2522
2571	2523	(著作権)
2572	2524
2573	2525	The original version of this article originally appeared in The Perl
2574	2526	Journal #10, and is copyright 1998 The Perl Journal. It appears courtesy
2575	2527	of Jon Orwant and The Perl Journal. This document may be distributed
2576	2528	under the same terms as Perl itself.
2577	2529
	2530	=cut
	2531
2578	2532	=begin meta
2579	2533
2580	2534	Translate: まかまか <makamaka@donzoko.net> (-5.8.1)
2581	2535	Update: SHIRAKATA Kentaro <argrath@ub32.org> (5.10.0-)
2582	2536	Status: completed
2583	2537
2584	2538	=end meta
2585
2586		=cut

Powered by Amon2, 翻訳, サイト. Operated by Japan Perl Association