dispatch_sync против dispatch_async в основной очереди

Это распространенная проблема, связанная с дисковым вводом-выводом и GCD. По сути, GCD, вероятно, порождает один поток для каждого файла, и в определенный момент у вас становится слишком много потоков, чтобы система могла обслуживать их за разумное время.

Каждый раз, когда вы вызываете dispatch_async() и в этом блоке пытаетесь выполнить какой-либо ввод-вывод (например, похоже, что вы читаете здесь какие-то файлы), вполне вероятно, что поток, в котором выполняется этот блок кода, заблокируется. (приостанавливается операционной системой), пока он ожидает чтения данных из файловой системы. Принцип работы GCD таков: когда он видит, что один из его рабочих потоков заблокирован при вводе-выводе, а вы все еще просите его выполнять дополнительную работу одновременно, он просто создаст новый рабочий поток. Таким образом, если вы попытаетесь открыть 50 файлов в параллельной очереди, вполне вероятно, что вы в конечном итоге заставите GCD породить ~ 50 потоков.

Это слишком много потоков для осмысленного обслуживания системой, и в конечном итоге вы лишите свой основной поток ресурсов ЦП.

Способ исправить это — использовать последовательную очередь вместо параллельной очереди для выполнения операций с файлами. Это легко сделать. Вы захотите создать последовательную очередь и сохранить ее как ivar в своем объекте, чтобы не создавать несколько последовательных очередей. Итак, удалите этот вызов:

dispatch_queue_t taskQ = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

Добавьте это в свой метод инициализации:

taskQ = dispatch_queue_create("com.yourcompany.yourMeaningfulLabel", DISPATCH_QUEUE_SERIAL);

Добавьте это в свой метод Dealloc:

dispatch_release(taskQ);

И добавьте это как ivar в объявление вашего класса:

dispatch_queue_t taskQ;

Я считаю, что Райан на правильном пути: просто слишком много потоков создается, когда в проекте 1500 файлов (количество, которое я решил протестировать).

Итак, я переработал приведенный выше код, чтобы он работал следующим образом:

- (void) establishImportLinksForFilesInProject:(LPProject *)aProject
{
        dispatch_queue_t taskQ = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

     dispatch_async(taskQ, 
     ^{

     // Create a new Core Data Context on this thread using the same persistent data store    
     // as the main thread. Pass the objectID of aProject to access the managedObject
     // for that project on this thread's context:

     NSManagedObjectID *projectID = [aProject objectID];

     for (LPFile *fileToCheck in [backgroundContext objectWithID:projectID] memberFiles])
     {
        if (//Some condition is met)
        {
                // Here, we do the scanning for @import statements. 
                // When we find a valid one, we put the whole path to the 
                // imported file into an array called 'verifiedImports'. 

                // Pass this ID to main thread in dispatch call below to access the same
                // file in the main thread's context
                NSManagedObjectID *fileID = [fileToCheck objectID];


                // go back to the main thread and update the model 
                // (Core Data is not thread-safe.)
                dispatch_async(dispatch_get_main_queue(), 
                ^{
                    for (NSString *import in verifiedImports)
                    {  
                       LPFile *targetFile = [mainContext objectWithID:fileID];
                       // Add the relationship to targetFile. 
                    }
                 });//end block
         }
    }
    // Easy way to tell when we're done processing all files.
    // Could add a dispatch_async(main_queue) call here to do something like UI updates, etc

    });//end block
    }

Итак, по сути, теперь мы создаем один поток, который читает все файлы, а не один поток для каждого файла. Кроме того, оказывается, что вызов dispatch_async() для main_queue является правильным подходом: рабочий поток отправит этот блок в основной поток и НЕ будет ждать его возврата, прежде чем приступить к сканированию следующего файла.

Эта реализация, по сути, устанавливает «последовательную» очередь, как предложил Райан (цикл for является ее последовательной частью), но с одним преимуществом: когда цикл for заканчивается, мы закончили обработку всех файлов и можем просто вставить очередь. Блок dispatch_async(main_queue) там, чтобы делать все, что мы хотим. Это очень хороший способ узнать, когда задача параллельной обработки завершена, и этого не было в моей старой версии.

Недостатком здесь является то, что немного сложнее работать с Core Data в нескольких потоках. Но этот подход кажется пуленепробиваемым для проектов с 5000 файлов (это самый высокий показатель, который я тестировал).

Я думаю, что это более легко понять с диаграммой:

Для ситуации, описанной автором:

|задачаQ| ************старт|

|dispatch_1 ***********|---------

|dispatch_2 *************|---------

.

|dispatch_n ****************************|----------

|основная очередь(синхронизация)|**начать отправку в основную|

************************|--dispatch_1--|--dispatch_2--|--dispatch3--|****** ***********************|--dispatch_n|,

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