Multithreaded Application Tutorial/ja: what changed

Revision 2 to 3. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		## 概要
2	2
3	3		このページでは Free Pascal と Lazarus を使ってマルチスレッドアプリケーションを記述したりデバッグしたりする方法について述べます。マルチスレッドアプリケーションは、同時作業させるために複数のスレッドを作成しているものを指します。もし、読者がマルチスレッドに初めて触れるのなら、是非マルチスレッドが本当に必要かどうかを「マルチスレッドが必要ですか？」節でお確かめください。そうすれば頭痛の種を激減することができるでしょう。
4	4
5	5		スレッドのうち 1 つは、メインスレッドと呼ばれるものです。メインスレッドはアプリケーションが起動する際、オペレーティングシステムによって生成されます。メインスレッドはユーザインターフェイス、コンポーネントを更新する唯一のスレッドです。メインスレッドはかならずただ一つである必要があり、そうでないとアプリケーションは暴走します。
6	6
7	7		マルチスレッドプログラミングの基本的な考え方は、ユーザがメインスレッドを通して作業する傍ら、もう一つのスレッドを用いてある種の処理をバックグラウンドで行えるようにアプリケーションを組むという点です。
8	8
9	9		スレッドの他の使い方として、アプリケーションの応答速度を改善することが挙げられます。例えば、あなたがアプリケーションを作られたとして、ユーザがボタンを押してアプリケーションがすごく重たい処理を開始したとします。処理の間、スクリーンは凍りつき反応が無くなり、ユーザはアプリケーションが落ちたと思うでしょう。よくないことです。もし、その重たい処理を 2 つ目のスレッドの中で実行するようにすれば、アプリケーションの応答性は保たれ、まるでそんな処理は行っていないかのように振舞います。このような場合には、スレッドを開始する前にフォームの処理を開始するボタンを使用不可能にしておくと、ユーザがそれ以上の作業を要求することを無くすことができ、好都合です。
10	10
11	11		また、サーバアプリケーションを作る際に、同時に大量のクライアントに応答しなければならない場合にも使えます。
12	12
13	13		## マルチスレッドが必要ですか？
14	14
15	15		もし読者がマルチスレッドにこれまで触れたことがなく、単に重い処理を実行するアプリケーションの応答性を改善したいだけなら、マルチスレッドはお探しのものとは違うかもしれません。マルチスレッドアプリケーションはしばしば複雑であり、デバッグは常に困難です。また、多くの場合マルチスレッドは必要のないものです。単一スレッドアプリケーションで十分です。時間のかかるタスクを細かな部分に分割することができるなら、マルチスレッドの代わりに Application.ProcessMessages を使うべきです。このメソッドを使用すると、LCL に待機中のメッセージをすべて処理させたのち制御が戻ってきます。分割したタスクの一部分を実行したら Application.ProcessMessages を呼び、ユーザがアプリケーションを終了させたりどこかをクリックしたりしたかを確認し、あるいは進行状況表示を再描画したりします。その後タスクの次の部分を実行し、また Application.ProcessMessages を呼びます。
16	16
17	17		例：大きなファイルの読み込みと処理\
18	18		examples/multithreading/singlethreadingexample1.lpi
19	19
20	20		マルチスレッドが必要なのは、次のような場合だけです。
21	21
22	22		- 同期型のネットワーク通信のような、ブロッキングタイプの処理の場合（訳注：同期型の場合タイムアウトするまで処理が戻ってこない可能性がありますから、例えば別スレッドでキャンセル待ち処理をするような使い方が考えられます）。
23	23		- マルチプロセッサによる同時処理（SMP）の場合。
24	24		- API を呼び出さなければならないためにそれ以上細かく分割できないアルゴリズムやライブラリの呼び出し（訳注：分割できない長い処理を普通に行うとハングアップして固まったかのように見えてしまいますから、時間がかかる処理は別スレッドで行い描画やウィンドウの移動などの操作にはメインスレッドで反応するような使い方が考えられます）。
25	25
26	26		マルチプロセッサによる同時処理で処理速度を上げるためにマルチスレッドを使いたいのであれば、プログラムが 1 つの CPU コアのリソースを 100% フルに使い切っているか確認してください（例えば、プログラムでファイルの書き込みなど入出力の処理が多く占めている場合、時間がかかる作業ではありますが CPU には負荷はかかっていません。このようなケースでマルチスレッドを使ってもプログラムは速くならないでしょう。）。また、最適化レベルが最大の 3 なっているかも確認してください。最適化レベルを 1 から 3 に切り替えたら、プログラムが約 5 倍速くなったことがありました。
27	27
28	28		## マルチスレッドアプリケーションで必要となるユニット
29	29
30	30		Windows では動作させるのに必要なユニットは特にありません。Linux、Mac OS X、FreeBSD では cthreads ユニットが必要で、プロジェクトユニット（プログラムソース、通常は .lpr ファイル）の一番最初に必ず置かなくてなりません！
31	31
32	32		Lazarus アプリケーションコードでは以下のようになるでしょう。（訳注：実際に見れば分かりますが、cthreads は自動生成された時点で既に UseCThreads スイッチ付きで組み込まれています。）
33	33
34	34		``` pascal
35	35		program MyMultiThreadedProgram;
36	36		{$mode objfpc}{$H+}
37	37		uses
38	38		{$ifdef unix}
39	39		cthreads,
40	40		cmem, // the c memory manager is on some systems much faster for multi-threading
41	41		{$endif}
42	42		Interfaces, // this includes the LCL widgetset
43	43		Forms
44	44		{ you can add units here },
45	45		```
46	46
47	47		これを怠ると、起動時に以下のエラーが出ます。
48	48
49		-	~~` This binary has no thread support compiled in.`\~~
50		-	~~` Recompile the application with a thread-driver in the program uses clause before other units using thread.`\~~
51		-	~~` 訳：このバイナリはスレッドをサポートしないでコンパイルされています。`\~~
52		-	~~` スレッドドライバをスレッドを使用されているユニットより前のプログラム uses 節に置き、アプリケーションをコンパイルし直してください。`~~
	49	+	``` pascal
	50	+	This binary has no thread support compiled in.
	51	+	Recompile the application with a thread-driver in the program uses clause before other units using thread.
	52	+	訳：このバイナリはスレッドをサポートしないでコンパイルされています。
	53	+	スレッドドライバをスレッドを使用されているユニットより前のプログラム uses 節に置き、アプリケーションをコンパイルし直してください。
	54	+	```
53	55
54	56		> Note: "mcount" が見つからないというようなリンカエラーが発生することがあります。これが発生するのは、マルチスレッドコードを含むユニットを使っていて、cthreads ユニットの追加もしくはスマートリンクの使用が必要な場合です。
55	57
56	58		> Note: 手続き SYSTEM_NOTHREADERROR 内でエラー "Project raised exception class 'RunError(232)'" が発生することがあります。これが発生するのは、コード内でスレッドが必要としており、cthreads ユニットの追加が必要な場合です。
57	59
58	60		## TThread クラス
59	61
60	62		サンプルは「examples/multithreading/」にあります。
61	63
62	64		マルチスレッドアプリケーションは TThread クラスを使用すると簡単に作成できます。このクラスを用いると追加のスレッド（メインスレッドと並列に実行する）を作ることができます。そのためには通常、Create コンストラクタと、Execute メソッドの 2 つのメソッドをオーバーライドしなければなりません。
63	65
64	66		コンストラクタは、スレッドを準備する際に使います。必要となる変数ないしプロパティに初期値を設定します。基となる TThread のコンストラクタは Suspended という引数を必要とします。名前からもお分かりのように、Suspended が False の場合、スレッドは作成後直ちに実行されます。逆に Suspended が True の場合、スレッドは停止状態で作成されます。この場合、スレッドを実行するには Start メソッドを呼びます。
65	67
66	68		> Note: メソッド Resume は [FPC 2.4.4 以降非推奨になりました](http://wiki.freepascal.org/User_Changes_2.4.4#TThread.Suspend_and_TThread.Resume_have_been_deprecated)。Resume は Start に置き換えてください。
67	69
68	70		FPC バージョン 2.0.1 以降の場合、TThread.Create は StackSize という暗黙のパラメータを持っています。必要であれば作成されたスレッドのデフォルトスタックサイズを変更することが可能です。例えばスレッド内で深い再帰呼び出しを行う際には重宝するでしょう。スタックサイズを指定しなかった場合は、OS による規定のスタックサイズが使用されます。
69	71
70	72		スレッドで実行したいコードは、Execute メソッドをオーバーライドして、その中に書きます。
71	73
72	74		TThread クラスは一つの重要なプロパティを持っています。それは、
73	75
74		-	~~`Terminated : boolean;`~~
	76	+	```text
	77	+	Terminated : boolean;
	78	+	```
75	79
76	80		です。
77	81
78	82		Terminated のデフォルト値は False です。通常の場合、スレッドはループを持っていますが、Terminated が True になったら、そのループから脱出しなければなりません。したがってループのサイクル毎に、Terminated が True になっていないかチェックする必要があります。もし True になっていたなら、速やかに必要な終了処理を行い、Execute メソッドを終了させなければなりません。ですから、Terminate メソッドを呼び出してもデフォルト状態では何も起きないことを、しっかり覚えておいてください。Execute メソッド自体が自分自身を終了するように明示的に実装しなければなりません。
79	83
80	84		先に説明したように、スレッドはビジュアルコンポーネントを操作すべきではありません。なにかをユーザに表示するためにはメインスレッドで行います。
81	85
82	86		これを行うために TThread には Synchronize というメソッドがあります。このメソッドは引数として、引数を持たないメソッドを 1 つとります。例えば、MyMethod というメソッドをスレッドから実行するには、Synchronize(@MyMethod) として呼び出します。この時スレッドの実行は一時的に停止し、メインスレッドから当該メソッドが実行され、その後スレッド実行が再開されます。
83	87
84	88		Synchronize の正確な動作はプラットフォーム依存しますが、基本的には以下のようになります。
85	89
86	90		- メッセージをメインメッセージキューに投げ、スレッドは休眠状態になります。
87	91		- メインスレッドでメッセージが処理され、MyMethod が呼ばれます。MyMethod は（デバイスや描画用の）コンテクスト無しで実行されます。つまり、MouseDown イベントや Paint イベント実行中に割り込んで実行されるのではなく、これらのイベントは後で実行されます。
88	92		- メインスレッドで MyMethod が実行された後、スレッドの休眠状態が解かれ、次のメッセージが処理されます。
89	93		- スレッドの処理が再開されます。
90	94
91	95		TThread が持つもう一つの重要なプロパティに FreeOnTerminate があります。このプロパティを True にしておくと、スレッドの実行（Execute メソッド）が停止した後にスレッドオブジェクトは自動的に解放されます。これを行わない場合は、アプリケーション側で手動でオブジェクトを解放する必要があります。\
92	96		（訳注：以下の例では単に FreeOnTerminate = True しているだけなので、スレッドが終了した場合 MyThread 変数が示すアドレスに不正にアクセスできてしまいます。スレッド終了時に必ず呼ばれる TThread.OnTerminate で MyThread := nil するなどして適切な処置を行ってください。OnTerminate イベントも Synchronize を通して呼ばれています。）
93	97
94	98		例：
95	99
96	100		``` pascal
97	101		Type
98	102		TMyThread = class(TThread)
99	103		private
100	104		fStatusText : string;
101	105		procedure ShowStatus;
102	106		protected
103	107		procedure Execute; override;
104	108		public
105	109		Constructor Create(CreateSuspended : boolean);
106	110		end;
107	111
108	112		constructor TMyThread.Create(CreateSuspended : boolean);
109	113		begin
110	114		FreeOnTerminate := True;
111	115		inherited Create(CreateSuspended);
112	116		end;
113	117
114	118		procedure TMyThread.ShowStatus;
115	119		// このメソッドはメインスレッドで実行されるので、すべての GUI 要素にアクセス可能です。
116	120		begin
117	121		Form1.Caption := fStatusText;
118	122		end;
119	123
120	124		procedure TMyThread.Execute;
121	125		var
122	126		newStatus : string;
123	127		begin
124	128		fStatusText := 'TMyThread Starting...';
125	129		Synchronize(@Showstatus);
126	130		fStatusText := 'TMyThread Running...';
127	131		while (not Terminated) and ([他のループ終了条件]) do
128	132		begin
129	133		...
130	134		[ここにスレッドループの本体コードを記述します]
131	135		...
132	136		if NewStatus <> fStatusText then
133	137		begin
134	138		fStatusText := newStatus;
135	139		Synchronize(@Showstatus);
136	140		end;
137	141		end;
138	142		end;
139	143		```
140	144
141	145		アプリケーション側では、
142	146
143	147		``` pascal
144	148		var
145	149		MyThread : TMyThread;
146	150		begin
147	151		MyThread := TMyThread.Create(True); // このようにすると自動的に開始しません
148	152		...
149	153		[ここにスレッドを実行する前に必要な初期化コードを記述します]
150	154		...
151	155		MyThread.Start;
152	156		end;
153	157		```
154	158
155	159		もっと柔軟な制御を望むなら、スレッドに対しイベントを作成します。こうすることで、イベントに対してイベントハンドラで設定できるようになり、Synchronize されたメソッドは特定のフォームやクラスに縛られなくなります。以下が例です。
156	160
157	161		``` pascal
158	162		Type
159	163		TShowStatusEvent = procedure(Status: String) of Object;
160	164
161	165		TMyThread = class(TThread)
162	166		private
163	167		fStatusText : string;
164	168		FOnShowStatus: TShowStatusEvent;
165	169		procedure ShowStatus;
166	170		protected
167	171		procedure Execute; override;
168	172		public
169	173		Constructor Create(CreateSuspended : boolean);
170	174		property OnShowStatus: TShowStatusEvent read FOnShowStatus write FOnShowStatus;
171	175		end;
172	176
173	177		constructor TMyThread.Create(CreateSuspended : boolean);
174	178		begin
175	179		FreeOnTerminate := True;
176	180		inherited Create(CreateSuspended);
177	181		end;
178	182
179	183		procedure TMyThread.ShowStatus;
180	184		// このメソッドはメインスレッドで実行されるので、すべての GUI 要素にアクセス可能です。
181	185		begin
182	186		if Assigned(FOnShowStatus) then
183	187		begin
184	188		FOnShowStatus(fStatusText);
185	189		end;
186	190		end;
187	191
188	192		procedure TMyThread.Execute;
189	193		var
190	194		newStatus : string;
191	195		begin
192	196		fStatusText := 'TMyThread Starting...';
193	197		Synchronize(@Showstatus);
194	198		fStatusText := 'TMyThread Running...';
195	199		while (not Terminated) and ([他のループ終了条件]) do
196	200		begin
197	201		...
198	202		[ここにスレッドループの本体コードを記述します]
199	203		...
200	204		if NewStatus <> fStatusText then
201	205		begin
202	206		fStatusText := newStatus;
203	207		Synchronize(@Showstatus);
204	208		end;
205	209		end;
206	210		end;
207	211		```
208	212
209	213		アプリケーション側では、
210	214
211	215		``` pascal
212	216		Type
213	217		TForm1 = class(TForm)
214	218		Button1: TButton;
215	219		Label1: TLabel;
216	220		procedure FormCreate(Sender: TObject);
217	221		procedure FormDestroy(Sender: TObject);
218	222		private
219	223		{ private declarations }
220	224		MyThread: TMyThread;
221	225		procedure ShowStatus(Status: string);
222	226		public
223	227		{ public declarations }
224	228		end;
225	229
226	230		procedure TForm1.FormCreate(Sender: TObject);
227	231		begin
228	232		inherited;
229	233		MyThread := TMyThread.Create(true);
230	234		MyThread.OnShowStatus := @ShowStatus;
231	235		end;
232	236
233	237		procedure TForm1.FormDestroy(Sender: TObject);
234	238		begin
235	239		MyThread.Terminate;
236	240
237	241		// FreeOnTerminate が true であれば、以下の記述は必要ありません。
238	242		// MyThread.Free;
239	243		inherited;
240	244		end;
241	245
242	246		procedure TForm1.Button1Click(Sender: TObject);
243	247		begin
244	248		MyThread.Start;
245	249		end;
246	250
247	251		procedure TForm1.ShowStatus(Status: string);
248	252		begin
249	253		Label1.Caption := Status;
250	254		end;
251	255		```
252	256
253	257		## 特に注意すべきこと
254	258
255	259		### Windows におけるスタックチェック
256	260
257	261		Windows で -Ct スイッチ（スタックチェック）を使うスレッドには頭の痛い問題があります。理由は定かではありませんが、デフォルトのスタックサイズを使う場合、スタックチェックが TTread.Create 内で問題を引き起こすことがあります。現在の運用上の回避策としては -Ct スイッチを使わないことです。一連の現象がメインスレッドで例外を引き起こすことは全くなく、新しく生成されたスレッド内で起こります。そのためスレッドが絶対開始できないように見えます。
258	262
259	263		スレッド生成時に発生するその他の例外や、この問題をチェックする良いコードを示します。
260	264
261	265		``` pascal
262	266		MyThread := TThread.Create(False);
263	267		if Assigned(MyThread.FatalException) then
264	268		raise MyThread.FatalException;
265	269		```
266	270
267	271		このコードは、スレッド生成時に発生するどんな例外でも、メインスレッドで生成させます。
268	272
269	273		### パッケージでのマルチスレッド
270	274
271	275		マルチスレッドを使用しているパッケージには、-dUseCThreads フラグをカスタム使用オプションに追加してください。パッケージエディタを開いて、オプション → 使用 → カスタム、そこへ -dUseCThreads を追加します。これによって、このパッケージを使用している IDE を含めたすべてのプロジェクトおよびパッケージでこのフラグが定義されます。IDE および IDE によって作成されたアプリケーションには、.lpr ファイル内に以下のコードが組み込まれています。（訳注：cmem は自動生成で組み込まれてはいません（Lazarus 1.0.12/1.2RC1 で確認）。）
272	276
273	277		``` pascal
274	278		uses
275	279		{$IFDEF UNIX}{$IFDEF UseCThreads}
276	280		cthreads,
277	281		cmem, // the c memory manager is on some systems much faster for multi-threading
278	282		{$ENDIF}{$ENDIF}
279	283		```
280	284
281	285		### Heaptrc
282	286
283	287		cmem ユニットを使った上で -gh スイッチを使うことはできません。-gh スイッチは、（メモリーリークを調べるために）ヒープマネージャーを拡張する heaptrc ユニットを使用するものです。ですから（リークチェックしたいのであれば）、cmem ユニットを使ってからその後に heaptrc ユニットを置くようにする必要があります。（訳注：heaptrc は cmem を考慮するように作られているけど、cmem はそうではないからでしょう。）
284	288
285	289		``` pascal
286	290		uses
287	291		{$IFDEF UNIX}{$IFDEF UseCThreads}
288	292		cthreads,
289	293		cmem, // the c memory manager is on some systems much faster for multi-threading
290	294		{$ENDIF}{$ENDIF}
291	295		heaptrc,
292	296		```
293	297
294	298		## SMP（対称型マルチプロセッシング）のサポート
295	299
296	300		難しく考える必要はありません。このページで紹介されているマルチスレッドのやり方でアプリケーションを適切な動作をさせればいいのです。SMP は常に有効になっていますから。
297	301
298	302		## Lazarus でのマルチスレッドアプリケーションのデバッグ
299	303
300	304		LazarusでのデバグにはGDBが必要です。Lazarusのデバグ環境はどんどんフル装備かつ安定になっています。しかしながら Linux の一部のディストリビューションには問題をかかえたものもあります。 (* 訳注: MacOSX 10.8以降の場合、Xcode から GDB が失われているため、ユーザが自力で GDB をインストールし、デバグのための特権を与える必要があります *)
301	305
302	306		### デバッグ出力
303	307
304	308		単一スレッドアプリケーションでは、単純にコンソールでもターミナルでも好きなものに出力すれば、出力した順に行が並びます。マルチスレッドアプリケーションでは事態はもっと複雑です。スレッドAがスレッドBより先に一行出力したからといって、その順に書き込まれるとは限りません。あるスレッドが自分の出力を書いているときに、たまたま他のスレッドが行を書き込んでいるかも知れないのです。Linux では（多分）適切なDebugLn() 出力を得られるでしょう。Win32 ではDegubLn() をメインスレッドの外で使っていることによる例外が発生するかもしれません（おそらく DiskFull 例外）。頭痛を軽減するには、下記の DebugLnThreadLog() をお使いください。
305	309
306	310		The LCLProc ユニットには、各スレッドが自身のログファイルを書くための手続き／関数がいくつかあります:
307	311
308	312		``` pascal
309	313		procedure DbgOutThreadLog(const Msg: string); overload;
310	314		procedure DebuglnThreadLog(const Msg: string); overload;
311	315		procedure DebuglnThreadLog(Args: array of const); overload;
312	316		procedure DebuglnThreadLog; overload;
313	317		```
314	318
315	319		例: writeln('Some text ',123); の代わりに、これを使います
316	320
317		-	~~` DebuglnThreadLog(['Some text ',123]);`~~
	321	+	```text
	322	+	DebuglnThreadLog(['Some text ',123]);
	323	+	```
318	324
319	325		こうすると、 'Some text 123' という行が Log\<PID\>.txt に追加されます。ここで \<PID\> はそのスレッドのプロセス ID です。
320	326
321	327		実行する前毎に、ログファイルを削除するとよいでしょう:
322	328
323		-	~~` rm -f Log* && ./project1`~~
	329	+	```text
	330	+	rm -f Log* && ./project1
	331	+	```
324	332
325	333		### Linux
326	334
327	335		Linux でマルチスレッドアプリケーションをデバグする場合、一つの大きな問題があります: Xサーバの Desktop Manager がハングするかもしれません。例えば、デバグ中のアプリケーションがマウスやキーボードを捕獲し、そこで gdb がアプリケーションを一時停止させ、Xサーバがアプリケーションを待ってしまうとこうなります。こうなってしまったら、他のコンピュータからログインするか、CTRL+ALT+F3 でそのセッションから抜け出すかして、gdb を kill してください。あるいは、ウィンドウマネジャを再起動することもできます: 次のように入力してください sudo /etc/init.d/gdm restart。これで Desktop Manager が再起動し、デスクトップに戻れます。
328	336
329	337		この問題は、gdb がデバグ中のプログラムのどこで実行を止めるかに依存するので、ちょっとしたトリックが有効な場合があります: Ubuntu x64 では、プロジェクトオプション → コンパイラオプション → リンク → デバッグ：外部の gdb デバッグシンボルファイルを使用 (-Xg) をチェックします。
330	338
331	339		別のXデスクトップを開く手もあります。IDEとgdbを動かすデスクトップと、アプリケーションを動かすデスクトップを分けるのです。そうすれば固まるのはテスト用のデスクトップだけです。Xの別インスタンスを作るには:
332	340
333		-	~~` X :1 &`~~
	341	+	```text
	342	+	X :1 &
	343	+	```
334	344
335	345		とします。元のデスクトップに戻るには CTRL+ALT+F7を、再び新しいデスクトップに行くには CTRL+ALT+F8 を使います (このキーコンビネーションがうまく行かなかったら、CTRL+ALT+F2 を試してください... [Slackware](http://www.slackware.com)で有効でした)。
336	346
337	347		これで、X上のデスクトップセッションを始められます:
338	348
339		-	~~` gnome-session --display=:1 &`~~
	349	+	```text
	350	+	gnome-session --display=:1 &
	351	+	```
340	352
341	353		そしてLazarusでプロジェクトの run parameters dialogで"Use display"をチェックして、:1を入力します。
342	354
343	355		これでアプリケーションは2番目のXサーバーで動作するようになり、最初のXサーバーでデバッグが可能になりました。
344	356
345	357		この方法は、FPC2.0 と Lazarus 0.9.10 で、OS は Windows と Linux でテストしました。
346	358
347	359		------------------------------------------------------------------------
348	360
349	361		新しい X セッションを開始する代わりに、 [Xnest](http://en.wikipedia.org/wiki/Xnest) を用いることもできます。Xnest は X セッションをウィンドウで開くものです。これを用いると、スレッドをデバッグする間も X サーバがロックしません。また、複数のターミナルを行ったり来たりしながらデバグするよりも楽です。
350	362
351	363		Xnestを起動するには、次のようなコマンドをタイプします:
352	364
353		-	~~` Xnest :1 -ac`~~
	365	+	```text
	366	+	Xnest :1 -ac
	367	+	```
354	368
355	369		一つの X セッションが :1 で開き、アクセス制御がディセーブルされます。
356	370
357	371		## Lazarus ウィジェットセットインターフェース
358	372
359	373		win32、gtk、carbon インターフェースはマルチスレッドをサポートしています。それは TThread、クリティカルセクション、同期動作のことを指しています。しかしながら、これらはスレッドセーフではないのです。つまり、ある瞬間に同時に LCL にアクセスできるスレッドは 1 つに限られているということです。また、メインスレッドが他のスレッドに対して待機するようなことは通常はなく、メインスレッドだけが LCL へのアクセスを許可されているのです。TControl、アプリケーション、LCL ウィジェットの各ハンドルを使って動作させられるのはメインスレッドだけなのです。その一方で、LCL にはスレッドセーフな関数もいくつかあります。例えば、FileUtil ユニット内のほとんどの関数はスレッドセーフです。
360	374
361	375		### スレッド間のやり取りに SendMessage／PostMessage を使用する
362	376
363	377		1 つのアプリケーションにおいて LCL API を呼び出すのはただ 1 つであるべきで、通常はメインスレッドがそれを担っています。いくつかの間接的手段を通すことで、他のスレッドでも LCL の使用が可能になります。SendMessage や PostMessage の使用もそのような手段の一つといえるでしょう。LCLIntf.SendMessage と LCLIntf.PostMessage は、メッセージをアプリケーションのメッセージプールに送り、ウィンドウを直接制御するものです。
364	378
365	379		これらのルーチンのドキュメントもお読みください。
366	380
367	381		- [[doc:lcl/lclintf/sendmessage.html\|SendMessage]]
368	382		- [[doc:lcl/lclintf/postmessage.html\|PostMessage]]
369	383
370	384		SendMessage と PostMessage の違いは、呼び出した側への制御の復帰方法です。SendMessage ではメッセージを送った先のウィンドウの処理が完了するまで制御が戻りませんが、PostMessage では即座に制御が戻ります。
371	385
372	386		以下は、別のスレッドよりメインスレッドへ LCL コントロールに表示させるテキストを送る方法の例です。
373	387
374	388		``` pascal
375	389		const
376	390		WM_GOT_ERROR = LM_USER + 2004;
377	391		WM_VERBOSE = LM_USER + 2005;
378	392
379	393		procedure VerboseLog(Msg: string);
380	394		var
381	395		PError: PChar;
382	396		begin
383	397		if MessageHandler = 0 then Exit;
384	398		PError := StrAlloc(Length(Msg)+1);
385	399		StrCopy(PError, PChar(Msg));
386	400		PostMessage(formConsole.Handle, WM_VERBOSE, Integer(PError), 0);
387	401		end;
388	402		```
389	403
390	404		こちらは、受け取ったメッセージの処理の例です。
391	405
392	406		``` pascal
393	407		const
394	408		WM_GOT_ERROR = LM_USER + 2004;
395	409		WM_VERBOSE = LM_USER + 2005;
396	410
397	411		type
398	412		{ TformConsole }
399	413
400	414		TformConsole = class(TForm)
401	415		DebugList: TListView;
402	416		// ...
403	417		private
404	418		procedure HandleDebug(var Msg: TLMessage); message WM_VERBOSE;
405	419		end;
406	420
407	421		var
408	422		formConsole: TformConsole;
409	423
410	424		implementation
411	425
412	426		....
413	427
414	428		{ TformConsole }
415	429
416	430		procedure TformConsole.HandleDebug(var Msg: TLMessage);
417	431		var
418	432		Item: TListItem;
419	433		MsgStr: PChar;
420	434		MsgPasStr: string;
421	435		begin
422	436		MsgStr := PChar(Msg.wparam);
423	437		MsgPasStr := StrPas(MsgStr);
424	438		Item := DebugList.Items.Add;
425	439		Item.Caption := TimeToStr(SysUtils.Now);
426	440		Item.SubItems.Add(MsgPasStr);
427	441		Item.MakeVisible(False);
428	442		//f/TrayControl.SetError(MsgPasStr);
429	443		end;
430	444
431	445		end.
432	446		```
433	447
434	448		## クリティカルセクション
435	449
436	450		クリティカルセクションはオブジェクトの一つで、ある部分のコードがある時点では 1 つのスレッドだけで実行されること（排他的に実行されること）を保証するものです。クリティカルセクションは使用前に作成／初期化し、使用後は解放する必要があります。
437	451
438	452		以下はクリティカルセクションの一般的な使い方です。
439	453
440	454		セクションを宣言します（すべてのスレッドからアクセスできるようにグローバルにします）。
441	455
442		-	~~` MyCriticalSection: TRTLCriticalSection;`~~
	456	+	```text
	457	+	MyCriticalSection: TRTLCriticalSection;
	458	+	```
443	459
444	460		セクションを作成します。
445	461
446		-	~~` InitializeCriticalSection(MyCriticalSection);`~~
	462	+	```text
	463	+	InitializeCriticalSection(MyCriticalSection);
	464	+	```
447	465
448	466		スレッドを実行します。排他的な処理は以下のようにします。
449	467
450	468		``` pascal
451	469		EnterCriticalSection(MyCriticalSection);
452	470		try
453	471		// 変数へのアクセス、ファイルの書き出し、ネットワークパケットの送信、など
454	472		finally
455	473		LeaveCriticalSection(MyCriticalSection);
456	474		end;
457	475		```
458	476
459	477		すべてのスレッドが停止した後、セクションを解放します。
460	478
461		-	~~` DeleteCriticalSection(MyCriticalSection);`~~
	479	+	```text
	480	+	DeleteCriticalSection(MyCriticalSection);
	481	+	```
462	482
463	483		別の方法として、TCriticalSection オブジェクトも使えます。オプジェクトを作成するとセクションの作成と初期化を、Enter メソッドを実行すると EnterCriticalSection と同様の動作を、Leave メソッドを実行すると LeaveCriticalSection と同様の動作を、オブジェクトを破棄するとセクションの削除を行います。
464	484
465	485		例：5 つのスレッドが 1 つのカウンターに対して増加処理を行います。\
466	486		lazarus/examples/multithreading/criticalsectionexample1.lpi
467	487
468	488		注意：上述の 4 つの手続きは RTL（FPC のランタイム）と LCL に一組ずつ存在します。LCL のは LCLIntf と LCLType ユニットで定義されています（RTL のは System 系ユニット内）。どちらの組も同様に用いることができます。アプリケーションの中で混用することもできますが、RTL の関数／手続きには RTL のクリティカルセクションを、LCL の関数／手続きには LCL のクリティカルセクションを使わなければなりません。
469	489
470	490		### 変数の共用
471	491
472	492		複数のスレッドが 1 つの変数を共用する場合、読み出すだけなら何も問題はありません。単に読めばいいのです。しかし、1 つまたは複数のスレッドがその値を変更しようとするなら、複数のスレッドがその変数に同時にアクセスしないように注意しなければなりません。
473	493
474	494		例：5 つのスレッドが 1 つのカウンターに対して増加処理を行います。\
475	495		lazarus/examples/multithreading/criticalsectionexample1.lpi
476	496
477	497		## 別のスレッドの処理を待つ方法
478	498
479	499		スレッド A が別のスレッド B の結果を利用するなら、A は B の処理が終了するまで待つ必要があります。
480	500
481	501		重要：メインスレッドは決して他のスレッドの処理を待ってはいけません。その代わりに上述の Synchronize を用います。
482	502
483	503		一例：lazarus/examples/multithreading/waitforexample1.lpi
484	504
485	505		``` pascal
486	506		{ TThreadA }
487	507
488	508		procedure TThreadA.Execute;
489	509		begin
490	510		Form1.ThreadB:=TThreadB.Create(false);
491	511		// イベント作成
492	512		WaitForB:=RTLEventCreate;
493	513		while not Application.Terminated do begin
494	514		// B が A を起動させるまで待機し続けます
495	515		RtlEventWaitFor(WaitForB);
496	516		writeln('A: ThreadB.Counter='+IntToStr(Form1.ThreadB.Counter));
497	517		end;
498	518		end;
499	519
500	520		{ TThreadB }
501	521
502	522		procedure TThreadB.Execute;
503	523		var
504	524		i: Integer;
505	525		begin
506	526		Counter:=0;
507	527		while not Application.Terminated do begin
508	528		// B 処理中 ...
509	529		Sleep(1500);
510	530		inc(Counter);
511	531		// A 起動
512	532		RtlEventSetEvent(Form1.ThreadA.WaitForB);
513	533		end;
514	534		end;
515	535		```
516	536
517	537		> Note: RtlEventWaitFor の前に RtlEventSetEvent を呼ぶことはできますが、その場合 RtlEventWaitFor は即座に制御を返します。終了フラグをクリアしたいのでしたら RTLeventResetEvent を使用してください。
518	538
519	539		## Fork
520	540
521	541		マルチスレッドアプリケーションにおける fork に関して、次のことに留意してください。fork （あるいはfpFork）を呼び出す前に生成し動作させたあらゆるスレッドは、子プロセスで走っているのではありません。fork() の man ページで述べられているように、fork を呼び出す前に走っているスレッドの状態は未定義になります。
522	542
523	543		従って、fork を呼び出す前に初期化されたスレッドは、intialization 節を含め、動作しません。
524	544
525	545		## 並列手続き／ループ
526	546
527	547		マルチスレッドの内の特殊なもので、単一の手続きを並列実行するものです。[[Parallel procedures/ja\|並列手続きをご]]覧ください。
528	548
529	549		## 分散コンピューティング
530	550
531	551		マルチスレッドを更に踏み込んだもので、複数のマシンでスレッドを稼動させます。
532	552
533	553		- synapse、lnet、indy のような TCP スイートのいずれかを通信に使用します。これらは柔軟性に富み、クライアントとサーバのアプリケーションの接続の自由度上げたい場合よく用いられます。
534	554		- [[MPICH]] のようなメッセージパッシングライブラリを使用します。MPICH はコンピュータクラスタ上で高性能計算をするのに使われています。
535	555
536	556		## 外部スレッド
537	557
538	558		Free Pascal のスレッディングシステムを正しく動作させるには、新たに生成された FPC スレッドを初期化する必要があります（より正確には、スレッド毎に例外・I/O・スレッド変数 threadvar システムを初期化し、スレッド変数とヒープを動作可能にしなければなりません）。この過程は BeginThread を（あるいは間接的に TThread クラスを）用いると完全に自動的に行われます。しかし BeginThread を通さす生成されたスレッド（外部スレッド）を利用する場合、追加の作業が（いまのところ）必要となります。外部スレッドには外部の C ライブラリ (.DLL/.so) が生成したものも含みます。
539	559
540	560		外部スレッドを用いる際に考慮すべき点です（将来のコンパイラのヴァージョンでは不要になるかもしれません）:
541	561
542	562		- 外部スレッドを一切使わない - FPC スレッドを使う。スレッドの生成を完全に制御できるなら、BeginThread を使って自分でスレッドを生成します。
543	563
544	564		- 呼出規約が一致しない場合（生成しようとするスレッド関数が cdecl 呼出規約を必要としているのに、BeginThread が Pascal 呼出規約を必要としているような場合）、レコード型を一つ作り、オリジナルのスレッド関数をその中に入れて、Pascal スレッド関数側から次のように呼びます:
545	565
546	566		``` pascal
547	567		type
548	568		TCdeclThreadFunc = function (user_data:Pointer):Pointer;cdecl;
549	569
550	570		PCdeclThreadFuncData = ^TCdeclThreadFuncData;
551	571		TCdeclThreadFuncData = record
552	572		Func: TCdeclThreadFunc; //cdecl 関数
553	573		Data: Pointer; //ユーザデータ
554	574		end;
555	575
556	576		// Pascal スレッドは cdecl 関数で呼ばれます
557	577		function C2P_Translator(FuncData: pointer) : ptrint;
558	578		var
559	579		ThreadData: TCdeclThreadFuncData;
560	580		begin
561	581		ThreadData := PCdeclThreadFuncData(FuncData)^;
562	582		Result := ptrint(ThreadData.Func(ThreadData.Data));
563	583		end;
564	584
565	585		procedure CreatePascalThread;
566	586		var
567	587		ThreadData: PCdeclThreadFuncData;
568	588		begin
569	589		New(ThreadData);
570	590		// cdecl スレッド関数でなければなりません
571	591		ThreadData^.Func := func;
572	592		ThreadData^.Data := user_data;
573	593		// Pascal スレッドを作成
574	594		BeginThread(@C2P_Translator, ThreadData );
575	595		end;
576	596		```
577	597
578	598		- ダミーのスレッドを一つ生成して、FPC のスレッドシステムを初期化します。アプリケーションの中で Pascal スレッドを一つでも生成しないと、スレッドシステムは初期化されず、スレッド変数もヒープも正しく動作しません。
579	599
580	600		``` pascal
581	601		type
582	602		tc = class(tthread)
583	603		procedure execute;override;
584	604		end;
585	605
586	606		procedure tc.execute;
587	607		begin
588	608		end;
589	609
590	610		{ メインプログラム }
591	611		begin
592	612		{ スレッドの初期設定 }
593	613		with tc.create(false) do
594	614		begin
595	615		waitfor;
596	616		free;
597	617		end;
598	618		{ ... コードが続く }
599	619		end.
600	620		```
601	621
602	622		(スレッドシステムの初期化が終わると、ランタイムライブラリはシステム変数 IsMultiThread を true にします。この変数はロックを行うのに FPC のルーチンのそこかしこで用いられます。この変数を手動で設定してはいけません。)
603	623
604	624		- なんらかの理由でこれが上手く行かなかったら、次のコードを外部スレッド関数の中で使ってみてください:
605	625
606	626		``` pascal
607	627		function ExternalThread(param: Pointer): LongInt; stdcall;
608	628		var
609	629		tm: TThreadManager;
610	630		begin
611	631		GetThreadManager(tm);
612	632		tm.AllocateThreadVars;
613	633		InitThread(1000000); // ここでスタックサイズの初期値を調節します
614	634
615	635		{ スレッド化されたなにかをここで実行する ... }
616	636
617	637		Result:=0;
618	638		end;
619	639		```
620	640
621	641		### 外部スレッドの確認
622	642
623	643		時として、外部スレッドを取り扱わねばならないのか、はっきり分からないことがあります（例えば、C ライブラリがコールバックを使用しているなど）。これは、以下のようにして解析することができます。
624	644
625	645		1\. アプリケーションの現在のスレッド ID を調べます。
626	646
627	647		``` pascal
628	648		Win32: GetCurrentThreadID();
629	649		Darwin: GetThreadID();
630	650		Linux: TThreadID(pthread_self);
631	651		```
632	652
633	653		2\. スレッド関数内部で再度現在のスレッド ID を調べ、ステップ 1 の結果と比較します。
634	654
635	655		### タイムスライスの放棄
636	656
637	657		ThreadSwitch 手続きを使ってください。
638	658
639	659		> Note: Windows の裏技であるような Sleep(0) は使わないでください。これはすべてのプラットフォーム上で動作するものではないのです。
640	660
641	661		（訳注：タイムスライスは、1 回のスレッド処理に割り当てられる時間のことです。ThreadSwitch を実行すると残りの時間を放棄して、待機スレッドがあればそれらを行ってから、なければすぐに制御が戻ってきます。）
642	662
643	663		## 関連項目
644	664
645	665		- [[Streaming components/ja\|コンポーネントをストリームする]]
646	666		- [[Manager Worker Threads System]]
647	667		- [[Example of multi-threaded application: array of threads/ja\|マルチスレッドアプリケーションの例：スレッドの配列]]
648	668		- [[Parallel procedures/ja\|並列手続き]]
649	669		- [[Main Loop Hooks/ja\|メインループフック]]
650	670		- [[Asynchronous Calls/ja\|非同期呼び出し]]
651	671
652	672		---
653	673		From the Free Pascal wiki, page "Multithreaded Application Tutorial/ja", as it stood on 2020-02-20 after a change by Trev, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history