GCD Queues au lieu de serrures: lecture de données pour la cellForRowAtIndexPath de Tableview

Question

Le site d'Apple One, il est suggéré d'utiliser modèle des files d'attente GCD au lieu de serrures:

// 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];
    });
}

Comment traiter les serrures et les sections critiques avec GCD lorsque vous avez un fil de producteur en ajoutant beaucoup de tweets à la fois, au lieu d'un par un et vous devez lire un tweet à la fois pour la cellForRowAtIndexPath de UITableView?

Si vous avez conservé la « synchronisation » sur chaque « lire », ne sera pas cette cause beaucoup de blocs inutiles? C'est vraiment écrire de temps en temps, mais souvent lu le scénario ..

Answer 1

Si la latence est un problème, peut-être le producteur devrait ajouter tweets un par un, de sorte que les appels dispatch_sync du thread d'interface utilisateur restent sensibles.

Je ne voudrais pas vous soucier de « beaucoup de blocs inutiles » à moins / jusqu'à ce que le profilage montre que l'envoi de bloc est en tête en fait un problème. Après tout, cellForRowAtIndexPath ne va être appelé pour les cellules visibles, donc des moyens « lire souvent » quelque chose comme des dizaines de fois par seconde, et non pas des milliers ou des millions.