GCD colas en lugar de cerraduras: lectura de datos para cellForRowAtIndexPath de Tableview

Question

Uno de sitio de Apple, no hay patrón sugerido para el uso de colas de GCD en lugar de cerraduras:

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

¿Cómo hacer frente a las cerraduras y las secciones críticas con GCD cuando se tiene un hilo productor de la adición de una gran cantidad de tweets a la vez, en lugar de uno en uno y es necesario leer un tweet a la vez para cellForRowAtIndexPath de UITableView?

Si se queda con la 'sincronización' en cada 'leer', ¿no que causa una gran cantidad de bloques innecesarios? Esto es realmente escribir de vez en cuando, pero leer a menudo escenario ..

Answer 1

Si la latencia es una preocupación, tal vez el productor debe añadir los tweets de una en una, por lo que las llamadas dispatch_sync desde el hilo de interfaz de usuario siguen siendo sensibles.

Me no se preocupe por "una gran cantidad de bloques innecesarios" a menos que / hasta que perfilar muestra que el envío de bloques de arriba es en realidad un problema. Después de todo, cellForRowAtIndexPath sólo va a ser llamado para celdas visibles, por lo que "leer a menudo" significa algo así como docenas de veces un segundo, no miles o millones.