dispatch_queue_set_specific vs. immer die aktuelle Warteschlange

Ich versuche, meinen Kopf um die Differenz und der Nutzung zwischen diese 2:

static void *myFirstQueue = "firstThread";

dispatch_queue_t firstQueue = dispatch_queue_create("com.year.new.happy", DISPATCH_QUEUE_CONCURRENT);

dispatch_queue_set_specific(firstQueue, myFirstQueue, (void*) myFirstQueue, NULL);

Frage #1

Was ist der Unterschied zwischen diesem:

dispatch_sync(firstQueue, ^{

    if(dispatch_get_specific(myFirstQueue))
    {
        //do something here
    }
});

sowie die folgenden:

dispatch_sync(firstQueue, ^{

    if(firstQueue == dispatch_get_current_queue())
    {
       //do something here
    }
});

?

Frage #2:

Anstatt mithilfe der oben genannten (void*) myFirstQueue im

dispatch_queue_set_specific(firstQueue, myFirstQueue, (void*) myFirstQueue, NULL);

Können wir static int * myFirstQueue = 0; statt ?

Meine Argumentation basiert auf der Tatsache, dass:

dispatch_once_t ist auch 0 (gibt es eine Korrelation hier? Übrigens, ich weiß noch nicht so Recht, warum dispatch_once_t muss initialisiert werden auf 0, obwohl ich bereits gelesen haben, Fragen hier SO).

Frage #3

Können, die Sie zitieren mich ein Beispiel von GCD Deadlock hier?

Frage #4

Diese vielleicht ein wenig zu viel verlangt; ich werde Sie trotzdem bitten, im Fall jemand wissen, geschieht dies außerhalb der auf der Oberseite des Kopfes. Wenn nicht, wäre es OK zu verlassen, ist dieser Teil offen.

Habe ich noch nicht ausprobiert, weil ich wirklich nicht weiß, wie. Aber mein Konzept ist dieses:

Ist es auf jeden Fall können wir "den Griff" in irgendeiner Warteschlange, ermöglicht es uns immer noch zurückhalten, Griff es und somit in der Lage sein zu erkennen, wenn ein deadlock tritt auf, nachdem die queue abgeschleudert wird; und wenn es ist, und da haben wir ein handle der queue, die wir zuvor eingestellt haben, konnten wir irgendwie etwas tun, um zu entsperren den deadlock?

Wieder, wenn das ist zu viel zu beantworten, entweder das, oder wenn meine Argumentation ist vollständig ANNULLIERBAR /off hier (in Frage #4), fühlen Sie sich frei, lassen Sie diesen Teil unbeantwortet.

Glückliches Neues Jahr.


@san.t

Mit static void *myFirstQueue = 0;

Wir dies tun:

dispatch_queue_set_specific(firstQueue, &myFirstQueue, &myFirstQueue, NULL);

Völlig verständlich.

Aber wenn wir das tun:

static void *myFirstQueue = 1; 
//or any other number other than 0, it would be OK to revert back to the following?
dispatch_queue_set_specific(firstQueue, myFirstQueue, (void*) myFirstQueue, NULL);

Über dispatch_once_t:

Können Sie erläutern, wie mehr dazu:

Warum muss dispatch_once_t ersten sein 0, und wie und warum würde er so tun müssen, als einen boolean zu einem späteren Zeitpunkt? Hat das mit Erinnerung zu tun /Sicherheit oder die Tatsache, dass die Vorherige Speicheradresse besetzt war, die durch andere Objekte wurden nicht 0 (nil)?

Wie bei Frage #3:

Sorry, da ich vielleicht nicht ganz klar: habe ich das nicht gemeint ich bin in eine Sackgasse. Ich meinte, ob oder nicht, kann jemand mir zeigen, ein Szenario im code mit GCD, das führt zu einem deadlock.

Schließlich:

Ich hoffe, Sie Antworten konnte, Frage #4. Wenn nicht, wie bereits erwähnt, ist es OK.

  • dispatch_get_current_queue ist veraltet. Es hat sich gezeigt, dass ernsthafte zugrunde liegenden Probleme. Es ist nicht sicher. Benutze es nie.
  • Ich bin verwirrt, warum Sie überprüfen, welche Warteschlange Sie gleich nach Sie haben explizit ausgelöst, der block auf die Warteschlange. Sie müssen eine solche Prüfung vor dem Versand nicht nach, wie ich versuchte, dies zu tun in meinem helper-Funktion in dieser Frage: stackoverflow.com/questions/12806506/... . Möchten Sie vielleicht zu Lesen Rob ' s Antwort, und einige der Kommentare darunter ist es für einige subtile Unterschiede zwischen den veralteten dispatch_get_current_queue() und dispatch_get_specific().
  • Ich bin nicht so wirklich; es dient nur als ein Beispiel für mich zu Fragen, in Frage. Danke für den link; wird auf jeden Fall Lesen.
  • Apple hat sich sehr klar in einem Ihrer WWDC-videos darüber, warum Sie veraltet dispatch_get_current_queue. Die details sind kompliziert. Dies ist threading im kernel-Ebene, nachdem alle. Aber der Punkt ist, diese Besondere Missbilligung ist nicht nur ein "serviervorschlag". Es ist ernst.
  • Winken das Problem Weg, als "es ist kompliziert" tut Programmierer einen Bärendienst, denke ich. Die konzeptionelle Mängel der rekursive sperren sind in der Tat subtil, aber verstehen Sie, wirft Sie eine Tonne von Licht auf, wie zu tun, concurrent programming effektiv.
  • Es gibt keine Notwendigkeit, Welle entfernt - die Nutzlosigkeit von dispatch_get_current_queue ist leicht zu erklären: Es gibt keine einheitliche Antwort auf die Frage "was Warteschlange bin ich momentan auf?" in den Allgemeinen Fall. Dispatch-Warteschlangen sind eine Hierarchie, die Böden in einer Reihe von undurchsichtigen, globalen Warteschlangen. Es können auch beliebige Warteschlange Hierarchien gebaut mit dispatch_set_target_queue. Wenn Sie wissen möchten, wenn Sie auf die Haupt-queue verwenden [NSThread isMainThread]. Wenn Sie versuchen, verwenden Sie Warteschlangen zu implementieren rekursive sperren, einfach aufhören. Warteschlangen und sperren sind zwei verschiedene Dinge.
  • FWIW, ich habe erklärt dispatch_get/set_specific im detail hier: stackoverflow.com/questions/19833744/... ich habe auch Taube in großem detail auf die null-ness-Anforderungen dispatch_once_t hier: stackoverflow.com/questions/19832150/...

InformationsquelleAutor Unheilig | 2013-12-31
Schreibe einen Kommentar