在单独的线程中同步与异步相同答案

【问题标题】：is synchronous in separate thread the same as asynchronous在单独的线程中同步与异步相同
【发布时间】：2016-01-24 16:34:54
【问题描述】：

最近，我正在快速学习并发。根据苹果在NSOperation class reference的文档：

当您将操作添加到操作队列时，队列会忽略异步属性的值并始终从单独的线程调用 start 方法。因此，如果您总是通过将操作添加到操作队列来运行操作，则没有理由使它们异步。

这是否意味着单独线程中的同步与异步相同？当我使用以下代码进行测试时，该操作确实不会阻塞当前的主线程。

let operationQueue = NSOperationQueue()
let operation = NSBlockOperation(){
    //do some task here
}
operationQueue.addOperation(operation)

如果是真的，那我们为什么要创建 NSOperation 的并发子类呢？

【问题讨论】：

标签： ios asynchronous nsoperation synchronous

【解决方案1】：

哦，NSOperation。你有这么离奇的历史。

NSOperation 相对较旧（在 iOS 方面；在 ObjC 方面相当现代）。它是在 OS X 10.5 中添加的。在 OS X 10.6/iOS 4 之前，没有 NSBlockOperation 对象。根本没有块。所以进行操作的唯一方法是继承或使用NSInvocationOperation。这两种方法都很麻烦，但仍然比直接使用NSThread 的旧方法更简单、更强大。

（正好在多核成为一个东西的时候。10.5以添加Core Animation而闻名，这是我相信Cocoa中第一个主要的抢占式多任务框架。在10.5之前，大多数事情都是通过runloop和协作完成的多任务，对于单核系统实际上是非常高效和有效的。但是它不能很好地扩展到多核系统。提供了像NSOperation 这样的工具来帮助我们编写更好的多核代码，但是 GCD 是所以强大得多，它完全支配了用 Cocoa 编写多任务代码的方式。）

当你继承NSOperation 时，你需要告诉系统你的操作是否是异步的。这不是异步运行您的请求。这是您的start 方法不会阻塞的承诺。这取决于您的 start 方法来确保操作确实是异步的。

这仅在您的NSOperation 是手动启动的情况下是必需的，即使这样通常也不需要它。如果你把它放在NSOperationQueue 上（你真的应该总是这样做），这个属性是无关紧要的。我记得当时它造成了很多混乱。

自从引入块以来，它变得更加无关紧要。使用NSBlockOperation（或dispatch_async）几乎总是比继承NSOperation 容易得多，要完全正确总是有点棘手。

以防万一你还没有读过，如果你想学习 Cocoa 并发，你肯定要从Concurrency Programming Guide开始。

【讨论】：

非常感谢。如果我理解正确，您的意思是在单独的线程中同步确实与异步相同。实际上，使用NSOperationQueue时不需要更改异步属性。
两点都正确。

【解决方案2】：

异步总是相对于发出请求的线程定义的。因此，如果线程 A 发出在线程 B 中运行的请求，使得线程 A 能够在线程 B 运行请求时执行其他工作，则请求相对于线程 A 是异步的。

如果线程 B 反过来将请求发送给线程 C，以便线程 B 能够在线程 C 运行请求时执行其他工作，那么第二个请求相对于线程 B 是异步的。

当然，一遍又一遍地异步地输出相同的工作元素是没有意义的。但是假设上述由线程 A 委托给线程 B 的工作可以拆分为多个较小的工作元素。线程 B 在线程 C、D 等上异步调用那些较小的工作元素是合理的。如果 B 向 A 提供服务而 A 不想/不需要知道工作方式的细节，则可能会发生这种情况完成；它只是希望异步完成工作。 B 知道细节，可以决定是否/如何通过较小的并行单元完成工作。

【讨论】：