Multithreaded Application Tutorial/ja: what changed

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