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

Question

Un site d'Apple, il y a modèle suggéré pour l'utilisation 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 traitez-vous avec les serrures et les sections critiques avec GCD lorsque vous avoir un thread producteur ajoutant beaucoup de tweets à la fois, au lieu d'un par un et vous devez lire un tweet à la fois pour cellForRowAtIndexPath de UITableView?

Si vous gardez la 'synchronisation' sur chaque 'lecture', cela ne causera-t-il pas beaucoup de blocs inutiles? Ceci est vraiment écrit une fois de temps en temps, mais lit souvent scénario ..

Answer 1

Si la latence est une préoccupation, peut-être que le producteur devrait ajouter tweets un par un, de sorte que les appels dispatch_sync du thread UI restent sensibles.

Je ne m'inquiéterais pas de "beaucoup de blocs inutiles" tant que le profilage ne montre pas que le surcoût de répartition des blocs est réellement un problème. Après tout, cellForRowAtIndexPath va seulement être appelé pour les cellules visibles, donc "lire souvent" signifie quelque chose comme des dizaines de fois par seconde, pas des milliers ou des millions.