синхронно в отдельной теме то же самое, что и асинхронно

Question

В последнее время я изучаю параллелизм в быстром. Согласно документу яблока в NSOperation class reference:

При добавлении операции в очередь операций, очередь игнорирует значение асинхронной собственности и всегда вызывает метод запуска из отдельного потока. Поэтому, если вы всегда запускаете операции, добавляя их в очередь операций, нет причин сделать их асинхронными.

Это означает, что синхронный в отдельной теме такой же, как асинхронный? и когда я делаю тест со следующим кодом, операция действительно не блокирует текущий основной поток.

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

поэтому, если это правда, то почему мы должны создавать подклассы параллелизма NSOperation?

Answer 1

Асинхронный всегда определяется относительно потока, который делает запрос. Таким образом, запрос является асинхронным относительно потока A, если поток A делает запрос, который выполняется в потоке B, так что поток A способен выполнять другую работу, в то время как поток B выполняет запрос.

Если поток В в свою очередь, из ферм просьбой нить С таким образом, что поток В может делать другую работу в то время как поток C работает запрос, то, что второй запрос является асинхронной по отношению к резьбы B.

Это не имеет смысла просто продолжать анимировать один и тот же элемент работы снова и снова, конечно. Но предположим, что работа, делегированная потоком A в поток B, описанный выше, может быть разделена на несколько меньших элементов работы. Было бы разумно, чтобы поток B вызывал эти меньшие элементы работы асинхронно на потоках C, D и т. Д. Это может произойти, если B предоставляет услугу A, так что A не хочет/не должен знать информацию о том, как работает завершается; он просто хочет, чтобы работа выполнялась асинхронно. B знает подробности и может решить, выполнить ли/как выполнить работу с помощью небольших параллельных блоков.

Answer 2

О, 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, вам нужно сообщить системе, является ли ваша операция ази nchronous. Это не запрос для асинхронного запуска. Это обещание, что ваш метод start не будет блокироваться. Это зависит от вашего метода start, чтобы убедиться, что операция действительно асинхронна.

Это необходимо только в том случае, если ваш NSOperation запускается вручную, и даже тогда он часто не нужен. Если вы положили его на номер NSOperationQueue (и вы действительно должны это делать), это свойство не имеет значения. Я помню, что это создавало много путаницы в то время.

Это стало еще более неуместным с момента введения блоков. Почти всегда гораздо проще использовать NSBlockOperation (или dispatch_async), чем для подкласса NSOperation, что всегда было довольно сложно, чтобы получить совершенно правильное решение.

На всякий случай, если вы еще не прочитали его, если вы хотите изучить параллелизм Cocoa, вы определенно хотите начать с Concurrency Programming Guide.