是的,@synchronized
指令是可重入的。請參見「線程編程指南」中的Using the @synchronized Directive以及ObjC編程語言中的Threading。
也就是說,你應該幾乎從不在iOS中使用它。在大多數情況下,您可以避免各種類型的鎖,更不用說像重入式鎖那樣的重量級(緩慢)鎖。請參閱「併發編程指南」,特別是Migrating Away from Threads,以獲取iOS優於手動線程管理和鎖定的基於隊列的方法的詳細信息。
例如,讀/寫鎖的工作原理是這樣使用大中央調度:
- (id)init {
...
_someObjectQueue = dispatch_queue_create("com.myapp.someObject",
DISPATCH_QUEUE_CONCURRENT);
}
// In iOS 5 you need to release disptach_release(_someObjectQueue) in dealloc,
// but not in iOS 6.
- (id)someObject {
__block id result;
dispatch_sync(self.someObjectQueue, ^{
result = _someObject;
});
return result;
}
- (void)setSomeObject:(id)newValue {
dispatch_barrier_async(self.queue, ^{
_someObject = newValue;
});
這種方法允許無限制的並行讀者,以獨特的作家,同時確保作家從未捱餓,並且寫入和讀取的串行化,同時避免任何內核調用,除非存在實際的爭用。這就是說它非常快速簡單。
當閱讀器出現時,您排隊請求以讀取該值並等待其處理。當一個寫者出現時,它會對一個屏障請求進行排隊以更新它,這就要求當前沒有來自該隊列的其他請求正在運行。通過這個構造,開發人員不需要管理任何鎖。只需按照您希望它們運行的順序將事情放在隊列中即可。
'@ synchronized'可重入,但不支持多個讀卡器。 GCD將需要對我現有的代碼進行重大重組。 – Askable
你是正確的@synchronized不支持多讀者。這種方法在可可中並不常見,我不熟悉pthread_rwlock_init之外的一個很好的解決方案,我記得它不是可重入的。正如我所說的,這種鎖定效率非常低,iOS和現代Mac在GCD和NSOperationQueue中具有更快,更安全和更簡單的機制。在較老的Mac中,合作(runloop)多任務是強烈的首選。 .NET繼承了Java對線程和鎖的熱愛。 ObjC不鼓勵顯式線程。 Cocoa不像.NET,值得在iOS中學習Cocoa方法。 –
(是的,我知道這並不能真正回答你的問題,對不起。) –