Стратегия Grand Central для открытия нескольких файлов

Вы правы в том, что наверняка будете связаны вводом-выводом. И это будет усугубляться случайным доступом, когда несколько файлов открыты и активно читаются одновременно.

Таким образом, вам нужно найти немного баланса. Скорее всего, один файл не самый эффективный, как вы заметили.

Лично?

Я бы использовал семафор отправки.

Что-то типа:

@property(nonatomic, assign) dispatch_queue_t dataQueue;
@property(nonatomic, assign) dispatch_semaphore_t execSemaphore;

А также:

- (void) process:(NSData *)d {
    dispatch_async(self.dataQueue, ^{
        if (!dispatch_semaphore_wait(self.execSemaphore, DISPATCH_TIME_FOREVER)) {
            dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
                ... do calcualtion work here on d ...
                dispatch_async(dispatch_get_main_queue(), ^{
                    .... update main thread w/new data here ....
                });
                dispatch_semaphore_signal(self.execSemaphore);
            });
        }
    });
}

Где это начинается с:

self.dataQueue = dispatch_queue_create("com.yourcompany.dataqueue", NULL);
self.execSemaphore = dispatch_semaphore_create(3);
[self process: ...];
[self process: ...];
[self process: ...];
[self process: ...];
[self process: ...];
.... etc ....

Вам нужно будет определить, как лучше всего обрабатывать очереди. Если есть много элементов и есть понятие отмены, ставить все в очередь, вероятно, будет расточительно. Точно так же вы, вероятно, захотите поставить в очередь URL-адреса файлов для обработки, а не объекты NSData, как указано выше.

В любом случае вышеперечисленное будет обрабатывать три вещи одновременно, независимо от того, сколько из них поставлено в очередь.

Я бы использовал NSOperation для этого из-за простоты обработки как зависимостей, так и отмены.

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

Затем я добавлял операции чтения и записи в одну NSOperationQueue, «очередь ввода-вывода», с ограниченной шириной. Вычислительные операции я бы добавил в отдельную NSOperationQueue, «очередь вычислений», с неограниченной шириной.

Причина ограниченной ширины очереди ввода-вывода заключается в том, что ваша работа, скорее всего, будет связана с вводом-выводом; вы можете захотеть, чтобы его ширина была больше 1, но, скорее всего, это будет напрямую связано с количеством физических дисков, на которых находятся ваши входные файлы. (Возможно, что-то вроде 2x, вы захотите определить это экспериментально.)

Код будет выглядеть примерно так:

@implementation FileProcessor

static NSOperationQueue *FileProcessorIOQueue = nil;
static NSOperationQueue *FileProcessorComputeQueue = nil;

+ (void)inititalize
{
    if (self == [FileProcessor class]) {
        FileProcessorIOQueue = [[NSOperationQueue alloc] init];
        [FileProcessorIOQueue setName:@"FileProcessorIOQueue"];
        [FileProcessorIOQueue setMaxConcurrentOperationCount:2]; // limit width

        FileProcessorComputeQueue = [[NSOperationQueue alloc] init];
        [FileProcessorComputeQueue setName:@"FileProcessorComputeQueue"];
    }
}

- (void)processFilesAtURLs:(NSArray *)URLs
{
    for (NSURL *URL in URLs) {
        __block NSData *fileData = nil; // set by readOperation
        __block NSData *fileHashData = nil; // set by computeOperation

        // Create operations to do the work for this URL

        NSBlockOperation *readOperation =
            [NSBlockOperation blockOperationWithBlock:^{
                fileData = CreateDataFromFileAtURL(URL);
            }];

        NSBlockOperation *computeOperation =
            [NSBlockOperation blockOperationWithBlock:^{
                fileHashData = CreateHashFromData(fileData);
                [fileData release]; // created in readOperation
            }];

        NSBlockOperation *writeOperation =
            [NSBlockOperation blockOperationWithBlock:^{
                WriteHashSidecarForFileAtURL(fileHashData, URL);
                [fileHashData release]; // created in computeOperation
            }];

        // Set up dependencies between operations

        [computeOperation addDependency:readOperation];
        [writeOperation addDependency:computeOperation];

        // Add operations to appropriate queues

        [FileProcessorIOQueue addOperation:readOperation];
        [FileProcessorComputeQueue addOperation:computeOperation];
        [FileProcessorIOQueue addOperation:writeOperation];
    }
}

@end

Это довольно просто; вместо того, чтобы иметь дело с многоуровневыми синхронизирующими/асинхронными слоями, как в случае с dispatch_* API, NSOperation позволяет вам независимо определять единицы работы и зависимости между ними. В некоторых ситуациях это может быть проще для понимания и отладки.

Вы уже получили отличные ответы, но я хотел добавить пару моментов. Я работал над проектами, которые перечисляют все файлы в файловой системе и вычисляют хэши MD5 и SHA1 для каждого файла (в дополнение к другой обработке). Если вы делаете что-то подобное, где вы ищете большое количество файлов, и файлы могут иметь произвольное содержимое, то следует учитывать некоторые моменты:

• Как уже отмечалось, вы будете привязаны к вводу-выводу. Если вы читаете более 1 файла одновременно, это отрицательно скажется на производительности каждого вычисления. Очевидно, что целью планирования параллельных вычислений является загрузка диска между файлами, но вы можете подумать о том, чтобы структурировать свою работу по-другому. Например, настройте один поток, который перечисляет и открывает файлы, а второй поток получает дескрипторы открытых файлов из первого потока по одному и обрабатывает их. Файловая система будет кэшировать информацию каталога, поэтому перечисление не окажет серьезного влияния на чтение данных, которые фактически должны попасть на диск.

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

• Если у вас нет другого применения для данных, кроме вычисления хеша, то я предлагаю отключить кэширование файловой системы перед чтением данных.

При использовании NSFileHandles простой метод категории будет делать это для каждого файла:

@interface NSFileHandle (NSFileHandleCaching)
- (BOOL)disableFileSystemCache;
@end

#include <fcntl.h>

@implementation NSFileHandle (NSFileHandleCaching)
- (BOOL)disableFileSystemCache {
     return (fcntl([self fileDescriptor], F_NOCACHE, 1) != -1);
}
@end

• Если файлы sidecar небольшие, вы можете собрать их в памяти и записать их пакетами, чтобы свести к минимуму прерывание обработки.

• Файловая система (по крайней мере, HFS) хранит записи файлов для файлов в каталоге последовательно, поэтому просматривайте файловую систему в ширину (т. Е. Обрабатывайте каждый файл в каталоге перед входом в подкаталоги).

Вышеизложенное, конечно, только предложения. Вы захотите поэкспериментировать и измерить производительность, чтобы подтвердить фактическое влияние.

libdispatch фактически предоставляет API специально для этого! Проверьте dispatch_io; он будет обрабатывать распараллеливание ввода-вывода, когда это необходимо, и в противном случае сериализовать его, чтобы избежать перегрузки диска.

Следующая ссылка относится к проекту BitBucket, который я настроил, используя NSOperation и Grand Central Dispatch, используя примитивное приложение для проверки целостности файлов.

https://bitbucket.org/torresj/hashar-cocoa

Я надеюсь, что это поможет / использовать.