應用程序里面多個線程的存在引發了多個執行線程安全訪問資源的潛在問題。兩個線程同時修改同一資源有可能以意想不到的方式互相干擾。比如，一個線程可能覆蓋其他線程改動的地方，或讓應用程序進入一個未知的潛在無效狀態。如果你幸運的話，受損的資源可能會導致明顯的性能問題或崩潰，這樣比較容易跟蹤并修復它。然而如果你不走運，資源受損可能導致微妙的錯誤，這些錯誤不會立即顯現出來，而是很久之后才出現，或者導致其他可能需要一個底層的編碼來顯著修復的錯誤。

但涉及到線程安全時，一個好的設計是最好的保護。避免共享資源，并盡量減少線程間的相互作用，這樣可以讓它們減少互相的干擾。但是一個完全無干擾的設計是不可能的。在線程必須交互的情況下，你需要使用同步工具，來確保當它們交互的時候是安全的。

Mac OS X和iOS提供了你可以使用的多個同步工具，從提供互斥訪問你程序的有序的事件的工具等。以下個部分介紹了這些工具和如何在代碼中使用他們來影響安全的訪問程序的資源。

1.同步工具

為了防止不同線程意外修改數據，你可以設計你的程序沒有同步問題，或你也可以使用同步工具。盡管完全避免出現同步問題相對更好一點，但是幾乎總是無法實現。以下個部分介紹了你可以使用的同步工具的基本類別。

1.1 原子操作

原子操作是同步的一個簡單的形式，它處理簡單的數據類型。原子操作的優勢是它們不妨礙競爭的線程。對于簡單的操作，比如遞增一個計數器，原子操作比使用鎖具有更高的性能優勢。

Mac OS X和iOS包含了許多在32位和64位執行基本的數學和邏輯運算的操作。這些操作都使用了原子版本來操作比較和交換，測試和設置，測試和清理等。查看支持原子操作的列表，參閱/user/include/libkern/OSAtomic.h頭文件和參見atomic主頁。

1.2 內存屏障和 Volatile 變量

為了達到最佳性能，編譯器通常會對匯編基本的指令進行重新排序來盡可能保持處理器的指令流水線。作為優化的一部分，編譯器有可能對訪問主內存的指令，如果它認為這有可能產生不正確的數據時，將會對指令進行重新排序。不幸的是，靠編譯器檢測到所有可能內存依賴的操作幾乎總是不太可能的。如果看似獨立的變量實際上是相互影響，那么編譯器優化有可能把這些變量更新位錯誤的順序，導致潛在不不正確結果。

內存屏障（memory barrier）是一個使用來確保內存操作按照正確的順序工作的非阻塞的同步工具。內存屏障的作用就像一個柵欄，迫使處理器來完成位于障礙前面的任何加載和存儲操作，才允許它執行位于屏障之后的加載和存儲操作。內存屏障同樣使用來確保一個線程（但對另外一個線程可見）的內存操作總是按照預定的順序完成。如果在這些地方缺少內存屏障有可能讓其他線程看到看似不可能的結果（比如，內存屏障的維基百科條目）。為了使用一個內存屏障，你只要在你代碼里面需要的地方簡單的調用OSMemoryBarrier函數。

Volatile 變量適用于獨立變量的另一個內存限制類型。編譯器優化代碼通過加載這些變量的值進入寄存器。對于本地變量，這通常不會有什么問題。但是如果一個變量對另外一個線程可見，那么這種優化可能會阻止其他線程發現變量的任何變化。在變量之前加上關鍵字volatile可以強制編譯器每次使用變量的時候都從內存里面加載。如果一個變量的值隨時可能給編譯器無法檢測的外部源更改，那么你可以把該變量聲明為volatile變量。

因為內存屏障和volatile變量降低了編譯器可執行的優化，因此你應該謹慎使用它們，只在有需要的地方時候，以確保正確性。關于更多使用內存屏障的信息，參閱OSMemoryBarrier主頁。

1.3 鎖

鎖是最常用的同步工具。你可以是使用鎖來保護臨界區(critical section)，這些代碼段在同一個時間只能允許被一個線程訪問。比如，一個臨界區可能會操作一個特定的數據結構，或使用了每次只能一個客戶端訪問的資源。

表4-1列出了程序最常使用的鎖。Mac OS X和iOS提供了這些鎖里面大部分類型的實現，但是并不是全部實現。對于不支持的鎖類型，說明列解析了為什么這些鎖不能直接在平臺上面實現的原因。

Table 4-1  Lock types

Lock	Description
Mutex [互斥鎖]	A mutually exclusive (or mutex) lock acts as a protective barrier around a resource. A mutex is a type of semaphore that grants access to only one thread at a time. If a mutex is in use and another thread tries to acquire it, that thread blocks until the mutex is released by its original holder. If multiple threads compete for the same mutex, only one at a time is allowed access to it.
Recursive lock [遞歸鎖]	A recursive lock is a variant on the mutex lock. A recursive lock allows a single thread to acquire the lock multiple times before releasing it. Other threads remain blocked until the owner of the lock releases the lock the same number of times it acquired it. Recursive locks are used during recursive iterations primarily but may also be used in cases where multiple methods each need to acquire the lock separately.
Read-write lock [讀寫鎖]	A read-write lock is also referred to as a shared-exclusive lock. This type of lock is typically used in larger-scale operations and can significantly improve performance if the protected data structure is read frequently and modified only occasionally. During normal operation, multiple readers can access the data structure simultaneously. When a thread wants to write to the structure, though, it blocks until all readers release the lock, at which point it acquires the lock and can update the structure. While a writing thread is waiting for the lock, new reader threads block until the writing thread is finished. The system supports read-write locks using POSIX threads only. For more information on how to use these locks, see the pthread man page.
Distributed lock [分布鎖]	A distributed lock provides mutually exclusive access at the process level. Unlike a true mutex, a distributed lock does not block a process or prevent it from running. It simply reports when the lock is busy and lets the process decide how to proceed.
Spin lock [自旋鎖]	A spin lock polls its lock condition repeatedly until that condition becomes true. Spin locks are most often used on multiprocessor systems where the expected wait time for a lock is small. In these situations, it is often more efficient to poll than to block the thread, which involves a context switch and the updating of thread data structures. The system does not provide any implementations of spin locks because of their polling nature, but you can easily implement them in specific situations. For information on implementing spin locks in the kernel, see Kernel Programming Guide.
Double-checked lock [雙重檢查鎖]	A double-checked lock is an attempt to reduce the overhead of taking a lock by testing the locking criteria prior to taking the lock. Because double-checked locks are potentially unsafe, the system does not provide explicit support for them and their use is discouraged.[注意系統不顯式支持該鎖類型]

注意：大部分鎖類型都合并了內存屏障來確保在進入臨界區之前它前面的加載和存儲指令都已經完成。

關于如何使用鎖的信息，參閱”使用鎖”部分。

1.4 條件

條件是信號量的另外一個形式，它允許在條件為真的時候線程間互相發送信號。條件通常被使用來說明資源可用性，或用來確保任務以特定的順序執行。當一個線程測試一個條件時，它會被阻塞直到條件為真。它會一直阻塞直到其他線程顯式的修改信號量的狀態。條件和互斥鎖(mutex lock)的區別在于多個線程被允許同時訪問一個條件。條件更多是允許不同線程根據一些指定的標準通過的守門人。

一個方式是你使用條件來管理掛起事件的池。事件隊列可能使用條件變量來給等待線程發送信號，此時它們在事件隊列中的時候。如果一個事件到達時，隊列將給條件發送合適信號。如果一個線程已經處于等待，它會被喚醒，屆時它將會取出事件并處理它。如果兩個事件到達隊列的時間大致相同，隊列將會發送兩次信號喚醒兩個線程。

系統通過幾個不同的技術來支持條件。然而正確實現條件需要仔細編寫代碼，因此你應該在你自己代碼中使用條件之前查看”使用條件”部分的例子。

1.5 執行Selector例程

Cocoa程序包含了一個在一個線程以同步的方式傳遞消息的方便方法。NSObject類聲明方法來在應用的一個活動線程上面執行selector的方法。這些方法允許你的線程以異步的方式來傳遞消息，以確保它們在同一個線程上面執行是同步的。比如，你可以通過執行selector消息來把一個從你分布計算的結果傳遞給你的應用的主線程或其他目標線程。每個執行selector的請求都會被放入一個目標線程的run loop的隊列里面，然后請求會按照它們到達的順序被目標線程有序的處理。

關于執行selector例程的總結和更多關于如何使用它們的信息，參閱Cocoa執行Selector源。

2.同步的成本和性能

同步幫助確保你代碼的正確性，但同時將會犧牲部分性能。甚至在無爭議的情況下，同步工具的使用將在后面介紹。鎖和原子操作通常包含了內存屏障和內核級別同步的使用來確保代碼正確被保護。如果，發生鎖的爭奪，你的線程有可能進入阻塞，在體驗上會產生更大的遲延。

表4-2列出了在無爭議情況下使用互斥鎖和原子操作的近似的相關成本。這些測試的平均值是使用了上千的樣本分析出的結果。隨著線程創建時間的推移，互斥采集時間（即使在無爭議情況下）可能相差也很大，這依賴于進程的加載，計算機的處理速度和系統和程序現有可用的內存。

Table 4-2  Mutex and atomic operation costs

Item	Approximate cost	Notes
Mutex acquisition time	Approximately 0.2 microseconds [0.2微秒]	This is the lock acquisition time in an uncontested case. If the lock is held by another thread, the acquisition time can be much greater. The figures were determined by analyzing the mean and median values generated during mutex acquisition on an Intel-based iMac with a 2 GHz Core Duo processor and 1 GB of RAM running Mac OS X v10.5.
Atomic compare-and-swap	Approximately 0.05 microseconds [0.05微秒]	This is the compare-and-swap time in an uncontested case. The figures were determined by analyzing the mean and median values for the operation and were generated on an Intel-based iMac with a 2 GHz Core Duo processor and 1 GB of RAM running Mac OS X v10.5.

當設計你的并發任務時，正確性是最重要的因素，但是也要考慮性能因素。代碼在多個線程下面正確執行，但比相同代碼在當線程執行慢，這是難以改善的。如果你是改造已有的單線程應用，你應該始終給關鍵任務的性能設置測量基線。當增加額外線程后，對相同的任務你應該采取新的測量方法并比較多線程和單線程情況下的性能狀況。在改變代碼之后，線程并沒有提高性能，你應該需要重新考慮具體的實現或同時使用線程。

關于性能的信息和收集指標的工具，參閱Performance Overview。關于鎖原子成本的特定信息，參閱”線程成本”部分。

3.線程安全和信號量

當涉及到多線程應用程序時，沒有什么比處理信號量更令人恐懼和困惑的了。信號量是底層BSD機制，它可以用來傳遞信息給進程或以某種方式操縱它。一些應用程序使用信號量來檢測特定事件，比如子進程的消亡。系統使用信號量來終止失控進程，和作為其他類型的通信消息。

使用信號量的問題并不是你要做什么，而是當你程序是多線程的時候它們的行為。在當線程應用程序里面，所有的信號量處理都在主線程進行。在多線程應用程序里面，信號量被傳遞到恰好運行的線程，而不依賴于特定的硬件錯誤（比如非法指令）。如果多個線程同時運行，信號量被傳遞到任何一個系統挑選的線程。換而言之，信號量可以傳遞給你應用的任何線程。

在你應用程序里面實現信號量處理的第一條規則是避免假設任一線程處理信號量。如果一個指定的線程想要處理給定的信號，你需要通過某些方法來通知該線程信號何時到達。你不能只是假設該線程的一個信號處理例程的安裝會導致信號被傳遞到同一線程里面。

關于更多信號量的信息和信號量處理例程的安裝信息，參見signal和sigaction主頁。

4.線程安全設計的技巧

同步工具是讓你代碼安全的有用方法，但是它們并非靈丹妙藥。使用太多鎖和其他同步的類型原語和非多線程相比明顯會降低你應用的線程性能。在性能和安全之間尋找平衡是一門需要經驗的藝術。以下各部分提供幫助你為你應用選擇合適的同步級別的技巧。

4.1 完全避免同步

對于你新的項目，甚至已有項目，設計你的代碼和數據結構來避免使用同步是一個很好的解決辦法。雖然鎖和其他類型同步工具很有用，但是它們會影響任何應用的性能。而且如果整體設計導致特定資源的高競爭，你的線程可能需要等待更長時間。

實現并發最好的方法是減少你并發任務之間的交互和相互依賴。如果每個任務在它自己的數據集上面操作，那它不需要使用鎖來保護這些數據。甚至如果兩個任務共享一個普通數據集，你可以查看分區方法，它們設置或提供拷貝每一項任務的方法。當然，拷貝數據集本身也需要成本，所以在你做出決定前，你需要權衡這些成本和使用同步工具造成的成本那個更可以接受。

4.2 了解同步的限制

同步工具只有當它們被用在應用程序中的所有線程是一致時才是有效的。如果你創建了互斥鎖來限制特定資源的訪問，你所有線程都必須在試圖操縱資源前獲得同一互斥鎖。如果不這樣做導致破壞一個互斥鎖提供的保護，這是編程的錯誤。

4.3 注意對代碼正確性的威脅

當你使用鎖和內存屏障時，你應該總是小心的把它們放在你代碼正確的地方。即使有條件的鎖（似乎很好放置）也可能會讓你產生一個虛假的安全感。以下一系列例子試圖通過指出看似無害的代碼的漏洞來舉例說明該問題。其基本前提是你有一個可變的數組，它包含一組不可變的對象集。假設你想要調用數組中第一個對象的方法。你可能會做類似下面那樣的代碼：

NSLock* arrayLock = GetArrayLock(); 
NSMutableArray* myArray = GetSharedArray(); 
id anObject; 
  
[arrayLock lock]; 
anObject = [myArray objectAtIndex:0]; 
[arrayLock unlock]; 
  
[anObject doSomething];  

因為數組是可變的，所有數組周圍的鎖防止其他線程修改該數組直到你獲得了想要的對象。而且因為對象限制它們本身是不可更改的，所以在調用對象的doSomething方法周圍不需要鎖。

但是上面顯式的例子有一個問題。如果當你釋放該鎖，而在你有機會執行doSomething方法前其他線程到來并從數組中刪除所有對象，那會發生什么呢？對于沒有使用垃圾回收的應用程序，你代碼用戶的對象可能已經釋放了，讓anObject對象指向一個非法的內存地址。了修正該問題，你可能決定簡單的重新安排你的代碼，讓它在調用doSomething之后才釋放鎖，如下所示：

NSLock* arrayLock = GetArrayLock(); 
NSMutableArray* myArray = GetSharedArray(); 
id anObject; 
  
[arrayLock lock]; 
anObject = [myArray objectAtIndex:0]; 
[anObject doSomething]; 
[arrayLock unlock]; 

通過把doSomething的調用移到鎖的內部，你的代碼可以保證該方法被調用的時候該對象還是有效的。不幸的是，如果doSomething方法需要耗費很長的時間，這有可能導致你的代碼保持擁有該鎖很長時間，這會產生一個性能瓶頸。

該代碼的問題不是關鍵區域定義不清，而是實際問題是不可理解的。真正的問題是由其他線程引發的內存管理的問題。因為它可以被其他線程釋放，最好的解決辦法是在釋放鎖之前retain anObject。該解決方案涉及對象被釋放，并沒有引發一個強制的性能損失。

NSLock* arrayLock = GetArrayLock(); 
NSMutableArray* myArray = GetSharedArray(); 
id anObject; 
  
[arrayLock lock]; 
anObject = [myArray objectAtIndex:0]; 
[anObject retain]; 
[arrayLock unlock]; 
  
[anObject doSomething]; 
[anObject release]; 

盡管前面的例子非常簡單，它們說明了非常重要的一點。當它涉及到正確性時，你需要考慮不僅僅是問題的表面。內存管理和其他影響你設計的因子都有可能因為出現多個線程而受到影響，所以你必須考慮從上到下考慮這些問題。此外，你應該在涉及安全的時候假設編譯器總是出現最壞的情況。這種意識和警惕性，可以幫你避免潛在的問題，并確保你的代碼運行正確。

關于更多介紹如何讓你應用程序安全的額外例子，參閱Technical Note TN2059:”Using Collection Classes Safely in Multithreaded Application”。

4.4 當心死鎖（Deadlocks）和活鎖(Livelocks)

任何時候線程試圖同時獲得多于一個鎖，都有可能引發潛在的死鎖。當兩個不同的線程分別保持一個鎖（而該鎖是另外一個線程需要的）又試圖獲得另外線程保持的鎖時就會發生死鎖。結果是每個線程都會進入持久性阻塞狀態，因為它永遠不可能獲得另外那個鎖。

一個活鎖和死鎖類似，當兩個線程競爭同一個資源的時候就可能發生活鎖。在發生活鎖的情況里，一個線程放棄它的第一個鎖并試圖獲得第二個鎖。一旦它獲得第二個鎖，它返回并試圖再次獲得一個鎖。線程就會被鎖起來，因為它花費所有的時間來釋放一個鎖，并試圖獲取其他鎖，而不做實際的工作。

避免死鎖和活鎖的最好方法是同一個時間只擁有一個鎖。如果你必須在同一時間獲取多于一個鎖，你應該確保其他線程沒有做類似的事情。

4.5 正確使用Volatile變量

如果你已經使用了一個互斥鎖來保護一個代碼段，不要自動假設你需要使用關鍵詞volatile來保護該代碼段的重要的變量。一個互斥鎖包含了內存屏障來確保加載和存儲操作是按照正確順序的。在一個臨界區添加關鍵字volatile到變量上面會強制每次訪問該變量的時候都要從內存里面從加載。這兩種同步技巧的組合使用在一些特定區域是必須的，但是同樣會導致顯著的性能損失。如果單獨使用互斥鎖已經可以保護變量，那么忽略關鍵字volatile。

為了避免使用互斥鎖而不使用volatile變量同樣很重要。通常情況下，互斥鎖和其他同步機制是比volatile變量更好的方式來保護數據結構的完整性。關鍵字volatile只是確保從內存加載變量而不是使用寄存器里面的變量。它不保證你代碼訪問變量是正確的。

別走開，下頁內容更精彩

#p#

5.使用原子操作

非阻塞同步的方式是用來執行某些類型的操作而避免擴展使用鎖。盡管鎖是同步兩個線程的很好方式，獲取一個鎖是一個很昂貴的操作，即使在無競爭的狀態下。相比，許多原子操作花費很少的時間來完成操作也可以達到和鎖一樣的效果。

原子操作可以讓你在32位或64位的處理器上面執行簡單的數學和邏輯的運算操作。這些操作依賴于特定的硬件設施（和可選的內存屏障）來保證給定的操作在影響內存再次訪問的時候已經完成。在多線程情況下，你應該總是使用原子操作，它和內存屏障組合使用來保證多個線程間正確的同步內存。

表4-3列出了可用的原子運算和本地操作和相應的函數名。這些函數聲明在/usr/include/libkern/OSAtomic.h頭文件里面，在那里你也可以找到完整的語法。這些函數的64-位版本只能在64位的進程里面使用。

Table 4-3  Atomic math and logic operations

 

大部分原子函數的行為是相對簡單的并應該是你想要的。然而列表4-1顯式了測試-設置和比較-交換操作的原子行為，它們相對復雜一點。OSAtomicTestAndSet 第一次調用展示了如何對一個整形值進行位運算操作，而它的結果和你預期的有差異。最后兩次調用OSAtomicCompareAndSwap32顯式它的行為。所有情況下，這些函數都是無競爭的下調用的，此時沒有其他線程試圖操作這些值。

Listing 4-1  Performing atomic operations

int32_t  theValue = 0; 
OSAtomicTestAndSet(0, &theValue); 
// theValue is now 128. 
  
theValue = 0; 
OSAtomicTestAndSet(7, &theValue); 
// theValue is now 1. 
  
theValue = 0; 
OSAtomicTestAndSet(15, &theValue) 
// theValue is now 256. 
  
OSAtomicCompareAndSwap32(256, 512, &theValue); 
// theValue is now 512. 
  
OSAtomicCompareAndSwap32(256, 1024, &theValue); 
// theValue is still 512. 

關于原子操作的更多信息，參見atomic的主頁和/usr/include/libkern/OSAtomic.h頭文件。

6.使用鎖

鎖是線程編程同步工具的基礎。鎖可以讓你很容易保護代碼中一大塊區域以便你可以確保代碼的正確性。Mac OS X和iOS都位所有類型的應用程序提供了互斥鎖，而Foundation框架定義一些特殊情況下互斥鎖的額外變種。以下個部分顯式了如何使用這些鎖的類型。

6.1 使用POSIX互斥鎖

POSIX互斥鎖在很多程序里面很容易使用。為了新建一個互斥鎖，你聲明并初始化一個pthread_mutex_t的結構。為了鎖住和解鎖一個互斥鎖，你可以使用pthread_mutex_lock和pthread_mutex_unlock函數。列表4-2顯式了要初始化并使用一個POSIX線程的互斥鎖的基礎代碼。當你用完一個鎖之后，只要簡單的調用pthread_mutex_destroy來釋放該鎖的數據結構。

Listing 4-2  Using a mutex lock

pthread_mutex_t mutex; 
void MyInitFunction() 
{ 
    pthread_mutex_init(&mutex, NULL); 
} 
  
void MyLockingFunction() 
{ 
    pthread_mutex_lock(&mutex); 
    // Do work. 
    pthread_mutex_unlock(&mutex); 
} 

注意：上面的代碼只是簡單的顯式了使用一個POSIX線程互斥鎖的步驟。你自己的代碼應該檢查這些函數返回的錯誤碼，并適當的處理它們。

6.2 使用NSLock類

在Cocoa程序中NSLock中實現了一個簡單的互斥鎖。所有鎖（包括NSLock）的接口實際上都是通過NSLocking協議定義的，它定義了lock和unlock方法。你使用這些方法來獲取和釋放該鎖。

除了標準的鎖行為，NSLock類還增加了tryLock和lockBeforeDate:方法。方法tryLock試圖獲取一個鎖，但是如果鎖不可用的時候，它不會阻塞線程。相反，它只是返回NO。而lockBeforeDate:方法試圖獲取一個鎖，但是如果鎖沒有在規定的時間內被獲得，它會讓線程從阻塞狀態變為非阻塞狀態（或者返回NO）。

下面的例子顯式了你可以是NSLock對象來協助更新一個可視化顯式，它的數據結構被多個線程計算。如果線程沒有立即獲的鎖，它只是簡單的繼續計算直到它可以獲得鎖再更新顯式。 

6.3 使用@synchronized指令

@synchronized指令是在Objective-C代碼中創建一個互斥鎖非常方便的方法。@synchronized指令做和其他互斥鎖一樣的工作（它防止不同的線程在同一時間獲取同一個鎖）。然而在這種情況下，你不需要直接創建一個互斥鎖或鎖對象。相反，你只需要簡單的使用Objective-C對象作為鎖的令牌，如下面例子所示：

- (void)myMethod:(id)anObj 
{ 
    @synchronized(anObj) 
    { 
        // Everything between the braces is protected by the @synchronized directive. 
    } 
} 

創建給@synchronized指令的對象是一個用來區別保護塊的唯一標示符。如果你在兩個不同的線程里面執行上述方法，每次在一個線程傳遞了一個不同的對象給anObj參數，那么每次都將會擁有它的鎖，并持續處理，中間不被其他線程阻塞。然而，如果你傳遞的是同一個對象，那么多個線程中的一個線程會首先獲得該鎖，而其他線程將會被阻塞直到第一個線程完成它的臨界區。

作為一種預防措施，@synchronized塊隱式的添加一個異常處理例程來保護代碼。該處理例程會在異常拋出的時候自動的釋放互斥鎖。這意味著為了使用@synchronized指令，你必須在你的代碼中啟用異常處理。了如果你不想讓隱式的異常處理例程帶來額外的開銷，你應該考慮使用鎖的類。

關于更多@synchronized指令的信息，參閱The Objective-C Programming Language。

6.4 使用其他Cocoa鎖

以下個部分描述了使用Cocoa其他類型的鎖。

使用NSRecursiveLock對象

NSRecursiveLock類定義的鎖可以在同一線程多次獲得，而不會造成死鎖。一個遞歸鎖會跟蹤它被多少次成功獲得了。每次成功的獲得該鎖都必須平衡調用鎖住和解鎖的操作。只有所有的鎖住和解鎖操作都平衡的時候，鎖才真正被釋放給其他線程獲得。

正如它名字所言，這種類型的鎖通常被用在一個遞歸函數里面來防止遞歸造成阻塞線程。你可以類似的在非遞歸的情況下使用他來調用函數，這些函數的語義要求它們使用鎖。以下是一個簡單遞歸函數，它在遞歸中獲取鎖。如果你不在該代碼里使用NSRecursiveLock對象，當函數被再次調用的時候線程將會出現死鎖。

NSRecursiveLock *theLock = [[NSRecursiveLock alloc] init]; 
void MyRecursiveFunction(int value) 
{ 
    [theLock lock]; 
    if (value != 0) 
    { 
        --value; 
        MyRecursiveFunction(value); 
    } 
    [theLock unlock]; 
} 
MyRecursiveFunction(5); 

注意：因為一個遞歸鎖不會被釋放直到所有鎖的調用平衡使用了解鎖操作，所以你必須仔細權衡是否決定使用鎖對性能的潛在影響。長時間持有一個鎖將會導致其他線程阻塞直到遞歸完成。如果你可以重寫你的代碼來消除遞歸或消除使用一個遞歸鎖，你可能會獲得更好的性能。

使用NSConditionLock對象

NSConditionLock對象定義了一個互斥鎖，可以使用特定值來鎖住和解鎖。不要把該類型的鎖和條件（參見“條件”部分）混淆了。它的行為和條件有點類似，但是它們的實現非常不同。

通常，當多線程需要以特定的順序來執行任務的時候，你可以使用一個NSConditionLock對象，比如當一個線程生產數據，而另外一個線程消費數據。生產者執行時，消費者使用由你程序指定的條件來獲取鎖（條件本身是一個你定義的整形值）。當生產者完成時，它會解鎖該鎖并設置鎖的條件為合適的整形值來喚醒消費者線程，之后消費線程繼續處理數據。

NSConditionLock的鎖住和解鎖方法可以任意組合使用。比如，你可以使用unlockWithCondition:和lock消息，或使用lockWhenCondition:和unlock消息。當然，后面的組合可以解鎖一個鎖但是可能沒有釋放任何等待某特定條件值的線程。

下面的例子顯示了生產者-消費者問題如何使用條件鎖來處理。想象一個應用程序包含一個數據的隊列。一個生產者線程把數據添加到隊列，而消費者線程從隊列中取出數據。生產者不需要等待特定的條件，但是它必須等待鎖可用以便它可以安全的把數據添加到隊列。

id condLock = [[NSConditionLock alloc] initWithCondition:NO_DATA]; 
  
while(true) 
{ 
    [condLock lock]; 
    /* Add data to the queue. */ 
    [condLock unlockWithCondition:HAS_DATA]; 
} 

因為初始化條件鎖的值為NO_DATA，生產者線程在初始化的時候可以毫無問題的獲取該鎖。它會添加隊列數據，并把條件設置為HAS_DATA。在隨后的迭代中，生產者線程可以把到達的數據添加到隊列，無論隊列是否為空或依然有數據。唯一讓它進入阻塞的情況是當一個消費者線程充隊列取出數據的時候。

因為消費者線程必須要有數據來處理，它會使用一個特定的條件來等待隊列。當生產者把數據放入隊列時，消費者線程被喚醒并獲取它的鎖。它可以從隊列中取出數據，并更新隊列的狀態。下列代碼顯示了消費者線程處理循環的基本結構。

while (true) 
{ 
    [condLock lockWhenCondition:HAS_DATA]; 
    /* Remove data from the queue. */ 
    [condLock unlockWithCondition:(isEmpty ? NO_DATA : HAS_DATA)]; 
  
    // Process the data locally. 
} 

使用NSDistributedLock對象

NSDistributedLock類可以被多臺主機上的多個應用程序使用來限制對某些共享資源的訪問，比如一個文件。鎖本身是一個高效的互斥鎖，它使用文件系統項目來實現，比如一個文件或目錄。對于一個可用的NSDistributedLock對象，鎖必須由所有使用它的程序寫入。這通常意味著把它放在文件系統，該文件系統可以被所有運行在計算機上面的應用程序訪問。

不像其他類型的鎖，NSDistributedLock并沒有實現NSLocking協議，所有它沒有lock方法。一個lock方法將會阻塞線程的執行，并要求系統以預定的速度輪詢鎖。以其在你的代碼中實現這種約束，NSDistributedLock提供了一個tryLock方法，并讓你決定是否輪詢。

因為它使用文件系統來實現，一個NSDistributedLock對象不會被釋放除非它的擁有者顯式的釋放它。如果你的程序在用戶一個分布鎖的時候崩潰了，其他客戶端簡無法訪問該受保護的資源。在這種情況下，你可以使用breadLock方法來打破現存的鎖以便你可以獲取它。但是通常應該避免打破鎖，除非你確定擁有進程已經死亡并不可能再釋放該鎖。

和其他類型的鎖一樣，當你使用NSDistributedLock對象時，你可以通過調用unlock方法來釋放它。

別走開，下頁內容更精彩

#p#

7.使用條件

條件是一個特殊類型的鎖，你可以使用它來同步操作必須處理的順序。它們和互斥鎖有微妙的不同。一個線程等待條件會一直處于阻塞狀態直到條件獲得其他線程顯式發出的信號。

由于微妙之處包含在操作系統實現上，條件鎖被允許返回偽成功，即使實際上它們并沒有被你的代碼告知。為了避免這些偽信號操作的問題，你應該總是在你的條件鎖里面使用一個斷言。該斷言是一個更好的方法來確定是否安全讓你的線程處理。條件簡單的讓你的線程保持休眠直到斷言被發送信號的線程設置了。

以下部分介紹了如何在你的代碼中使用條件。

7.1 使用NSCondition類

NSCondition類提供了和POSIX條件相同的語義，但是它把鎖和條件數據結構封裝在一個單一對象里面。結果是一個你可以像互斥鎖那樣使用的對象，然后等待特定條件。

列表4-3顯示了一個代碼片段，它展示了為等待一個NSCondition對象的事件序列。cocaoCondition變量包含了一個NSCondition對象，而timeToDoWork變量是一個整形，它在其他線程里面發送條件信號時立即遞增。

Listing 4-3  Using a Cocoa condition

[cocoaCondition lock]; 
while (timeToDoWork <= 0) 
    [cocoaCondition wait]; 
  
timeToDoWork--; 
  
// Do real work here. 
  
[cocoaCondition unlock]; 

列表4-4顯示了用于給Cocoa條件發送信號的代碼，并遞增他斷言變量。你應該在給它發送信號前鎖住條件。

Listing 4-4  Signaling a Cocoa condition

[cocoaCondition lock]; 
timeToDoWork++; 
[cocoaCondition signal]; 
[cocoaCondition unlock]; 

7.2 使用POSIX條件

POSIX線程條件鎖要求同時使用條件數據結構和一個互斥鎖。經管兩個鎖結構是分開的，互斥鎖在運行的時候和條件結構緊密聯系在一起。多線程等待某一信號應該總是一起使用相同的互斥鎖和條件結構。修改該成雙結構將會導致錯誤。

列表4-5顯示了基本初始化過程，條件和斷言的使用。在初始化之后，條件和互斥鎖，使用ready_to_go變量作為斷言等待線程進入一個while循環。僅當斷言被設置并且隨后的條件信號等待線程被喚醒和開始工作。

Listing 4-5  Using a POSIX condition

pthread_mutex_t mutex; 
pthread_cond_t condition; 
Boolean     ready_to_go = true; 
  
void MyCondInitFunction() 
{ 
    pthread_mutex_init(&mutex); 
    pthread_cond_init(&condition, NULL); 
} 
  
void MyWaitOnConditionFunction() 
{ 
    // Lock the mutex. 
    pthread_mutex_lock(&mutex); 
  
    // If the predicate is already set, then the while loop is bypassed; 
    // otherwise, the thread sleeps until the predicate is set. 
    while(ready_to_go == false) 
    { 
        pthread_cond_wait(&condition, &mutex); 
    } 
  
    // Do work. (The mutex should stay locked.) 
  
    // Reset the predicate and release the mutex. 
    ready_to_go = false; 
    pthread_mutex_unlock(&mutex); 
} 

信號線程負責設置斷言和發送信號給條件鎖。列表4-6顯示了實現該行為的代碼。在該例子中，條件被互斥鎖內被發送信號來防止等待條件的線程間發生競爭條件。

Listing 4-6  Signaling a condition lock

void SignalThreadUsingCondition() 
{ 
    // At this point, there should be work for the other thread to do. 
    pthread_mutex_lock(&mutex); 
    ready_to_go = true; 
  
    // Signal the other thread to begin work. 
    pthread_cond_signal(&condition); 
  
    pthread_mutex_unlock(&mutex); 
} 

注意：上述代碼是顯示使用POSIX線程條件函數的簡單例子。你自己的代碼應該檢測這些函數返回錯誤碼并恰當的處理它們。