Очерки GCD вместо замков: чтение данных для CellForrowAtIndexPath

Question

Один сайт Apple, есть предложенный шаблон для использования очередей GCD вместо замков:

// Create queue early
queue = dispatch_queue_create("com.example.tweets", NULL);

// executed main thread
- (NSArray *)getTweets
{
    __block NSArray *a;
    dispatch_sync(queue, ^{
        a = [tweets copyTweets];
    });

    return a;
}

// executed on background thread
- (void)addTweet:(Tweet *)tw
{
    dispatch_async(queue, ^{
        [tweets addTweet:tw];
    });
}

Как вы справляетесь с замками и критическими разделами с GCD, когда у вас есть нить продюсера, добавляя много твитов одновременно, вместо одного за другим, и вам нужно читать по одному твиту за раз для CellFororaTindexPath?

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

Answer 1

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

Я бы не стал беспокоиться о «много ненужных блоков», если/пока профилирование не покажет, что накладные расходы на отправку блока на самом деле являются проблемой. В конце концов, CellForroborAtIndexPath будет вызван только для видимых клеток, поэтому «читать часто» означает что -то вроде десятков раз в секунду, а не тысячи или миллионы.