Appleでは前回の並列処理の一つ一つをThread：スレッドと呼んでます。
その(232)でも説明したように、直訳すると「糸」なんですが、Macのダッシュボードの辞書で調べると「メーリングリストなどで, 同一主題についての一連のやりとり」なんて説明もあります。
アプリケーション起動時には、スレッドが1つ、OS側で用意され、このスレッド上でmain関数（ブートキャンプの4で説明したやつね）が実行されるわけですよ。
基本的に、この最初に作られたスレッド（一般にメインスレッドと呼びます）を主軸にしてアプリケーションは動いてくわけです。
ここらへんは、例えば前回のサンプルThumbnailView-5のmain.mのmain関数の頭にブレークポイント付けてRunすれば、すぐ確認できます。
↓こんな感じで、Thread 1のmainで止まってるよ～って表示される。
ちなみに、いったんStopボタン押して、今度はThumbnailViewController.mで、別スレッドとして実行させたThumbnailViewの-loadingimagesメソッドにブレークポイント付けてRun、画面をサムネイル画面に切り替えると～
てな感じでドバッとスレッドが増えたりもします。
って、俺、-loadingimagesスレッド（Thread 5ね）しか作ってないはずなのになんで？って思うかもしれないけど、ここで出てるThread 2～Thread 4はiOS側が暗黙裏に用意するスレッドなんですな。
話を元に戻す。
スレッドはそれぞれが個別に動作するので、関数の呼び出しの重なりがスレッドごとに変わる事になります。
そのためスタック（スタックがわからん人はブートキャンプ 3参照）をスレッドごとに持ってたりもするわけです。
なので、例えば同じ関数funcを別々のスレッドが同じタイミングで呼び出しても、スタック上に確保される引数の文字列はスレッドごとに異なるので問題ないようになってます。
ここらへんの動作原理はブートキャンプで説明したとおり。
なんですが、ヒープ側はどのスレッドも共有してる状態なわけですよ。
ま、それがスレッドの売りでもあるわけですが、おのおののスレッドが勝手気ままに同じグローバル変数やstatic変数（ヒープ上に確保される）をいじると、わけわからん事になるわけなんですな。
で、そうならないためにスレッド間の同期をどうやってとるかって問題が出てくるわけで、いろいろ工夫が必要なわけですよ。
先に紹介したGrand Central Dispatchは、この同期問題の一つの解決策としても機能するわけですが、実をいうと、その(232)でもすでに一つの同期機能を使用してます。
それが
その(232)でも説明したように、直訳すると「糸」なんですが、Macのダッシュボードの辞書で調べると「メーリングリストなどで, 同一主題についての一連のやりとり」なんて説明もあります。
アプリケーション起動時には、スレッドが1つ、OS側で用意され、このスレッド上でmain関数（ブートキャンプの4で説明したやつね）が実行されるわけですよ。
基本的に、この最初に作られたスレッド（一般にメインスレッドと呼びます）を主軸にしてアプリケーションは動いてくわけです。
ここらへんは、例えば前回のサンプルThumbnailView-5のmain.mのmain関数の頭にブレークポイント付けてRunすれば、すぐ確認できます。
↓こんな感じで、Thread 1のmainで止まってるよ～って表示される。
ちなみに、いったんStopボタン押して、今度はThumbnailViewController.mで、別スレッドとして実行させたThumbnailViewの-loadingimagesメソッドにブレークポイント付けてRun、画面をサムネイル画面に切り替えると～
てな感じでドバッとスレッドが増えたりもします。
って、俺、-loadingimagesスレッド（Thread 5ね）しか作ってないはずなのになんで？って思うかもしれないけど、ここで出てるThread 2～Thread 4はiOS側が暗黙裏に用意するスレッドなんですな。
こいつらはiOS バージョン4、アンド Mac OS X Snow Leopardで導入されたGrand Central Dispatch（GCD）が使うスレッドっぽい。
GCDは並列処理を効率よく記述できるようにAppleが用意した仕組みで、iOSアプリで並列処理を積極的に利用するなら、これを使う事になるってしろもんです。
最終的にはGCDを利用してみようと思ってるんですが、とりあえず、今は「そ～なんだ～」でいいです。興味のある人は千種菊里さんがSnow Leopardで導入されたGCDを紹介した記事なんかを読んでみてください。
マルチコア時代の新機軸！ Snow LeopardのGCD
ただし並列処理をある程度経験した人対象なんで「ロック」とか「排他処理」とか「アムダールの法則」で涙目にならないように。
GCDは並列処理を効率よく記述できるようにAppleが用意した仕組みで、iOSアプリで並列処理を積極的に利用するなら、これを使う事になるってしろもんです。
最終的にはGCDを利用してみようと思ってるんですが、とりあえず、今は「そ～なんだ～」でいいです。興味のある人は千種菊里さんがSnow Leopardで導入されたGCDを紹介した記事なんかを読んでみてください。
マルチコア時代の新機軸！ Snow LeopardのGCD
ただし並列処理をある程度経験した人対象なんで「ロック」とか「排他処理」とか「アムダールの法則」で涙目にならないように。
話を元に戻す。
スレッドはそれぞれが個別に動作するので、関数の呼び出しの重なりがスレッドごとに変わる事になります。
そのためスタック（スタックがわからん人はブートキャンプ 3参照）をスレッドごとに持ってたりもするわけです。
なので、例えば同じ関数funcを別々のスレッドが同じタイミングで呼び出しても、スタック上に確保される引数の文字列はスレッドごとに異なるので問題ないようになってます。
ここらへんの動作原理はブートキャンプで説明したとおり。
なんですが、ヒープ側はどのスレッドも共有してる状態なわけですよ。
ま、それがスレッドの売りでもあるわけですが、おのおののスレッドが勝手気ままに同じグローバル変数やstatic変数（ヒープ上に確保される）をいじると、わけわからん事になるわけなんですな。
で、そうならないためにスレッド間の同期をどうやってとるかって問題が出てくるわけで、いろいろ工夫が必要なわけですよ。
先に紹介したGrand Central Dispatchは、この同期問題の一つの解決策としても機能するわけですが、実をいうと、その(232)でもすでに一つの同期機能を使用してます。
それが
-performSelectorOnMainThread:withObject:waitUntilDone:
ちゅーわけなんですが、眠くなったので以下次回！