GCD Queues anstelle von Sperren: Lesen von Daten für Tableview des cellForRowAtIndexPath

Question

Ein Apple-Website, gibt Muster vorgeschlagen ist für die Verwendung von GCD Warteschlangen anstelle von Sperren:

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

Wie gehen Sie mit den Schlössern und kritische Abschnitte mit GCD umgehen, wenn Sie einen Producer-Thread haben eine Menge Tweets auf einmal hinzufügen, statt eins nach dem anderen und Sie brauchen einen Tweet zu einer Zeit für UITableView des cellForRowAtIndexPath zu lesen?

Wenn Sie den ‚sync‘ gehalten auf jeder ‚lesen‘, wird nicht, dass Ursache einer Menge unnötiger Blöcke? Das ist wirklich Schreib einmal in einer Weile, aber oft gelesen Szenario ..

Answer 1

Wenn Latenz ist ein Anliegen, vielleicht sollte der Produzent Tweets hinzufügen one-by-one, so dass die dispatch_sync Anrufe aus dem UI-Thread ansprechbar bleiben.

Ich würde nicht Sorge über „eine Menge unnötiger Blöcke“ es sei denn, / bis zeigt Profilieren, dass der Block Versandaufwand ist tatsächlich ein Problem. Immerhin geht cellForRowAtIndexPath nur für sichtbare Zellen genannt werden, so „lesen oft“ bedeutet so etwas wie dutzende Male eine zweite, nicht Tausende oder Millionen.