Grand Central Dispatch 与 NSThreads? [英] Grand Central Dispatch vs NSThreads?
问题描述
我搜索了各种来源，但并没有真正理解使用 NSThreads 和 GCD 之间的区别.我对 OS X 平台完全陌生，所以我可能完全误解了这一点.
I searched a variety of sources but don't really understand the difference between using NSThreads and GCD. I'm completely new to the OS X platform so I might be completely misinterpreting this.
从我在网上读到的内容来看，GCD 似乎与基本线程(POSIX、NSThreads 等)做完全相同的事情，同时添加了更多技术术语(块").似乎只是将基本的线程创建系统(创建线程，运行函数)过于复杂.
From what I read online, GCD seems to do the exact same thing as basic threads (POSIX, NSThreads etc.) while adding much more technical jargon ("blocks"). It seems to just overcomplicate the basic thread creation system (create thread, run function).
GCD 到底是什么?为什么它比传统线程更受欢迎?什么时候应该使用传统线程而不是 GCD?最后是 GCD 奇怪的语法有原因吗?(块"而不是简单地调用函数).
What exactly is GCD and why would it ever be preferred over traditional threading? When should traditional threads be used rather than GCD? And finally is there a reason for GCD's strange syntax? ("blocks" instead of simply calling functions).
我使用的是 Mac OS X 10.6.8 Snow Leopard，我不是为 iOS 编程 - 我是为 Mac 编程.我在 Cocoa 中使用 Xcode 3.6.8，创建了一个 GUI 应用程序.
I am on Mac OS X 10.6.8 Snow Leopard and I am not programming for iOS - I am programming for Macs. I am using Xcode 3.6.8 in Cocoa, creating a GUI application.
推荐答案
Dispatch 的优势
这里主要概述了调度的优点:
The advantages of dispatch are mostly outlined here:
这个想法是你消除了你的工作，因为范式更容易适应大多数代码.
The idea is that you eliminate work on your part, since the paradigm fits MOST code more easily.
- 它减少了您的应用程序为在应用程序的内存空间中存储线程堆栈而付出的内存代价.
- 它消除了创建和配置线程所需的代码.
- 它消除了管理和安排线程工作所需的代码.
- 它简化了您必须编写的代码.
根据经验，使用 GCD 类型锁定而不是 @synchronized 大约快 80% 或更多，尽管微基准测试可能具有欺骗性.阅读更多此处，虽然我认为异步写入的建议在许多情况下并不适用，而且速度较慢(但它是异步的).
Empirically, using GCD-type locking instead of @synchronized is about 80% faster or more, though micro-benchmarks may be deceiving. Read more here, though I think the advice to go async with writes does not apply in many cases, and it's slower (but it's asynchronous).
线程的优势
你为什么要继续使用线程?来自同一个文档:
Why would you continue to use Threads? From the same document:
重要的是要记住，队列不是万能药更换螺纹.提供的异步编程模型queues 适用于延迟不成问题的情况.尽管队列提供了配置执行优先级的方法队列中的任务，更高的执行优先级并不能保证在特定时间执行任务.因此，线程仍然是一个在您需要最小延迟的情况下更合适的选择，例如就像在音频和视频播放中一样.
It is important to remember that queues are not a panacea for replacing threads. The asynchronous programming model offered by queues is appropriate in situations where latency is not an issue. Even though queues offer ways to configure the execution priority of tasks in the queue, higher execution priorities do not guarantee the execution of tasks at specific times. Therefore, threads are still a more appropriate choice in cases where you need minimal latency, such as in audio and video playback.
我个人还没有找到使用队列的理想解决方案的另一个地方是需要不断重新调度的守护进程.并不是说您不能重新安排它们，而是在 NSThread 方法中循环更简单(我认为).现在我确信即使在这种情况下，GCD 样式的锁定也会更快，而且您还可以在 GCD 调度的操作中执行循环.
Another place where I haven't personally found an ideal solution using queues is daemon processes that need to be constantly rescheduled. Not that you cannot reschedule them, but looping within a NSThread method is simpler (I think). Now I'm convinced that even in this context, GCD-style locking would be faster, and you could also do a loop within a GCD-dispatched operation.
Objective-C 中的块?
由于糟糕的语法，Objective-C 中的块真的很糟糕(尽管 Xcode 有时可以帮助自动完成，至少).如果您查看 Ruby(或几乎任何其他语言)中的块，您会发现它们用于调度操作是多么简单和优雅.我会说你会习惯 Objective-C 语法，但我真的认为你会习惯从你的例子中复制很多:)
Blocks are really horrible in Objective-C due to the awful syntax (though Xcode can sometimes help with autocompletion, at least). If you look at blocks in Ruby (or any other language, pretty much) you'll see how simple and elegant they are for dispatching operations. I'd say that you'll get used to the Objective-C syntax, but I really think that you'll get used to copying from your examples a lot :)
你可能会发现我的例子很有帮助，或者只是分散注意力.不确定.
You might find my examples from here to be helpful, or just distracting. Not sure.
这篇关于Grand Central Dispatch 与 NSThreads?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
