閱讀The Complete Friday Q&A:Volume I第一天
關(guān)于多線程編程和并行方式有以下幾種方式：

1、分布式計算。對于Mac開發(fā)人員來說，最明顯的例子是Xcode中的分布式構(gòu)建。對于開發(fā)者來說費時費力，因此最沒有用處。與您在單臺計算機上獲得的帶寬和延遲相比，計算機之間的帶寬和延遲微乎其微，因此很難通過編程來提升運行速度。 Xcode可以避免使用它，因為它（通常）會對它處理的每一位數(shù)據(jù)進行大量處理。除了獲得速度上的困難外，您還必須應(yīng)對更容易出錯的環(huán)境。如果用戶徘徊在wifi范圍之外，您希望從容恢復(fù)，而不丟失大量數(shù)據(jù)。在大多數(shù)情況下，這樣做是不值得的，特別是如果您要交付消費級軟件。

2、GPGPU-通用圖形處理器?；旧鲜褂靡曨l卡進行計算。這就是GPULife所做的。它具有巨大的力量。如果使用正確的程序，則頂級視頻卡可以輕松勝過頂級CPU的50倍。這同樣很難實現(xiàn)。 GPU高度并行化，并且具有與CPU截然不同的體系結(jié)構(gòu)，因此很難對其進行編碼，而使其快速運行則更加困難。 （盡管由于可用的功能強大，即使很慢的GPU代碼也可以非?？斓剡\行。）諸如CUDA和OpenCL之類的技術(shù)有望使這種事情變得更好，盡管您總是要面對這樣一個事實：具有完全不同的性能特征的大規(guī)模并行系統(tǒng)。我在這里的建議是等待Snow Leopard，然后希望OpenCL兌現(xiàn)諾言。

3、多進程。同樣，Xcode是此方法的一個突出示例，您可以看到它在編譯時產(chǎn)生了多個gcc實例。與OS相比，這通常被認為是一種比多線程更容易，更安全的方法，因為OS可以保護進程之間的相互影響，并可以更好地分離問題。我個人不這樣認為。對于幾乎所有不平凡的程序，一個死子進程將意味著整個程序崩潰，而將其拆分為多個進程所做的所有事情都使得調(diào)試變得更加困難。更糟糕的是，操作系統(tǒng)對進程數(shù)量的限制往往非常之低，因此您的程序?qū)⑿枰咨铺幚頍o法產(chǎn)生所需數(shù)量的子進程。 （以及系統(tǒng)上的所有其他應(yīng)用程序也將需要?。?/p>

4、多線程。標準技術(shù)。通常很難正確使用，也很難調(diào)試，但是就性能而言可能非常有意義。線程還可以幫助更好地組織程序。將長時間運行的處理或阻塞操作放到一個單獨的線程中通常比將它們多路復(fù)用在一起要干凈得多。

多線程是我們最熟悉的一種，也是最有用的一種。它非常通用，因此很有用，因此您可以使用多種方式使用多線程來實際完成工作：

• 鎖。 “標準”多線程。您具有受鎖保護的共享數(shù)據(jù)。在修改數(shù)據(jù)之前先獲取鎖。通常用于制造更復(fù)雜的系統(tǒng)。達到這個級別可能很困難，因此我建議您盡可能避免使用它，并在需要的地方盡量少使用它來構(gòu)建更好的抽象。

• 消息傳遞。通過消息傳遞，您可以避免共享數(shù)據(jù)，并讓線程使用消息隊列進行通信。 （消息隊列內(nèi)部通常共享數(shù)據(jù)，但這是一個實現(xiàn)細節(jié)。）Cocoa通過-performSelectorOnMainThread：...和performSelector：onThread：...調(diào)用為此提供了一些不錯的功能。重線程語言Erlang廣泛使用此模型，是其多線程功能背后的主要力量。

• 操作單元。這有點像消息傳遞，只是操作只是飛走并在使用視圖外線程的隊列上執(zhí)行。當(dāng)設(shè)置為一次僅執(zhí)行一個操作時，隊列就可以充當(dāng)同步點，以通常更易于使用的方式替換鎖。 NSOperationQueue提供了此功能，并且有傳言稱，雪豹的Grand Central Dispatch將提供類似的功能。

• 原子/交易對象。您可以構(gòu)建使用事務(wù)進行操作的對象，而不是使用互斥（鎖定，隊列）來避免破壞共享數(shù)據(jù)。抓取快照，進行更改，然后提交。 （通常這是作為一個循環(huán)實現(xiàn)的：快照，更改，嘗試提交并在中間發(fā)生某些更改時嘗試使用新快照重新開始。）TransactionKit是可可上下文中此類事件的一個很好的例子。

關(guān)于使用什么，這是我的想法。除非您的代碼將由具有大量可用硬件的單個客戶端運行，否則請避免使用分布式計算。能夠通過閑置在用戶家中的硬件來減少CPU周期聽起來很酷，但大部分時間并沒有得到回報。除非您有非常好的應(yīng)用程序，否則在Mac上避免使用GPGPU，直到Snow Leopard出貨為止。 OpenCL將使GPGPU更加實用和靈活，因此，今天嘗試將計算量大的代碼插入GLSL或CoreImage中似乎并不值得.

如果已經(jīng)編寫了子程序，則使用多個進程是一個好主意。如果將gcc作為子進程調(diào)用，則在四個文件上而不是一個一個地同時調(diào)用它是很容易的。如果您是從頭開始編寫代碼，除非您有其他充分的理由來編寫子流程，否則我不建議您這樣做，因為這很困難，而且回報還不存在。

對于多線程，請專注于消息傳遞和操作。多線程從來都不是一件容易的事，但是它們可以極大地簡化和減少錯誤。好的OO設(shè)計在這里也會有很大幫助。對已經(jīng)被分解為具有明確定義的接口以及它們之間的松散耦合的簡單對象的應(yīng)用程序進行多線程處理要容易得多。