iOS URL 请求。信号量问题答案

【问题标题】：iOS URL Requests. Semaphore issuesiOS URL 请求。信号量问题
【发布时间】：2016-06-19 11:03:23
【问题描述】：

我进入并发编程时遇到了一些信号量问题。我的函数首先从服务器加载数据，分析接收到的信息，然后在必要时向服务器发出第二个请求。

我尝试了不同的方法让它运行，但没有一个做得很好。我当前的代码 FOR ME 似乎是正确的，但在第二次请求时它只是锁定（可能像死锁）并且最后一个日志是“<__nscflocaldatatask:>{ taskIdentifier: 2 } {suspended }”

请告诉我我不知道什么。也许有更优雅的方式来完成这些目的？

提前谢谢你！

var users = [Int]()
let linkURL = URL.init(string: "https://bla bla")
let session = URLSession.shared()
let semaphore = DispatchSemaphore.init(value: 0)
let dataRequest = session.dataTask(with:linkURL!) { (data, response, error) in
    let json = JSON (data: data!)
    if (json["queue"]["numbers"].intValue>999) {
        for i in 0...999 {
            users.append(json["queue"]["values"][i].intValue)
        }
        for i in 1...lround(json["queue"]["numbers"].doubleValue/1000) {
            let session2 = URLSession.shared()
            let semaphore2 = DispatchSemaphore.init(value: 0)
            let linkURL = URL.init(string: "https://bla bla")
            let dataRequest2 = session2.dataTask(with:linkURL!) { (data, response, error) in
                let json = JSON (data: data!)
                print(i)
                semaphore2.signal()
            }
            dataRequest2.resume()
            semaphore2.wait(timeout: DispatchTime.distantFuture)
        }
    }
    semaphore.signal()
}
dataRequest.resume()
semaphore.wait(timeout: DispatchTime.distantFuture)

附：我为什么要这样做。服务器返回有限数量的数据。为了获得更多，我必须使用偏移量。

【问题讨论】：

为什么需要信号量？基本上你需要在第一次调用的闭包内运行第二个服务器请求，第二个闭包（内部）应该通过另一个闭包发送结果。如果你认为这是你需要的，我会给你一个代码片段。
@OhadM 据我所知，闭包在不同的线程上运行，因此主线程不会等待闭包中的代码完成。就我而言，它甚至没有开始执行。操场就停了。这就是我使用信号量的原因。
1.如果你告诉闭包在不同的线程上运行，闭包将在不同的线程上运行，因此它们也可以在主线程上运行。 2. 你为什么用操场？你需要在整个应用环境中测试你的代码
@OhadM in Playground 我测试我的应用程序模块，它比编译整个应用程序要快。好的，所以闭包默认在后台运行并在主线程上运行，我只需要使用 dispatch..get_global_queue 告诉它，并进行两次：第一个请求和第二个请求？
闭包在你创建它们的线程上运行，除非函数在不同的线程上显式调用回调。在这种情况下，除非您另有说明，否则它们都将在主线程上运行。

标签： ios swift concurrency semaphore

【解决方案1】：

这是死锁，因为您正在等待URLSession 的delegateQueue 上的信号量。默认委托队列不是主队列，而是串行后台队列（即OperationQueue 和maxConcurrentOperationCount 的1）。因此，您的代码正在等待同一串行队列上的信号量，该串行队列应该发出信号量。

战术性修复是确保您没有在会话的完成处理程序正在运行的同一个串行队列上调用wait。有两个明显的修复：

不要使用shared 会话（其delegateQueue 是串行队列），而是实例化您自己的URLSession 并将其delegateQueue 指定为您创建的并发OperationQueue：

let queue = OperationQueue()
queue.name = "com.domain.app.networkqueue"

let configuration = URLSessionConfiguration.default()
let session = URLSession(configuration: configuration, delegate: nil, delegateQueue: queue)

或者，您可以通过将带有信号量的代码分派到其他队列来解决此问题，例如

let mainRequest = session.dataTask(with: mainUrl) { data, response, error in
    // ...
    DispatchQueue.global(attributes: .qosUserInitiated).async {
        let semaphore = DispatchSemaphore(value: 0)

        for i in 1 ... n {
            let childUrl = URL(string: "https://blabla/\(i)")!
            let childRequest = session.dataTask(with: childUrl) { data, response, error in
                // ...
                semaphore.signal()
            }
            childRequest.resume()
            _ = semaphore.wait(timeout: .distantFuture)
        }
    }
}
mainRequest.resume()

为了完整起见，我会指出您可能根本不应该使用信号量来发出这些请求，因为您最终会因发出一系列连续请求而付出实质性的性能损失（加上您'正在阻塞一个线程，这通常是不鼓励的）。

为此而对代码进行的重构更为可观。它基本上需要发出一系列并发请求，可能使用“下载”任务而不是“数据”任务来最小化内存影响，然后当所有请求完成后，最后根据需要将它们拼凑在一起（由任一触发Operation“完成”操作或调度组通知）。

【讨论】：