Eine threadsichere statische Variablen Ziel c

Gibt es eine Möglichkeit in objective C kann ich definieren einer statischen int, das ist thread-sicher?

zum Beispiel, wenn ich die Klasse genannt-Sitzung:

static unsigned int session_id = 1000;

- (int) generateSessionID{
        return session_id++;
}

Ich bin konstruieren session-Objekte aus verschiedenen threads, jedes session-Objekt
sollte eine eindeutige id.

  • Müssen Sie irgendeine Art von sperren Semantik. Das Problem ist Sie wollen die operation atomar. Aber Bedenken Sie, dass "++" ist nicht atomar, es ist ein paar Operationen auf einmal.
  • möglich ist dann, surround meiner Rückkehr session_id++ mit synchronized(self){return session_id++}. Allerdings bin ich nicht sicher, ob diese sperren, die Klasse oder das Objekt, das es selbst.
  • wie geschrieben, es würde sperren Sie die Instanz, nicht die Klasse (nicht das, was Sie wollen). Vielleicht "@synchronized([self class])"?
  • Gelhar: Nein, synchronisieren nicht auf [self class] weil Instanzen von Unterklassen würde synchronisieren, die auf unterschiedliche Objekte der Klasse. Synchronisieren auf eine explizite Klasse z.B. [MyClass class]
InformationsquelleAutor Unis | 2010-10-28
  1. 5

    Wenn Sie im Gespräch Kakao, den mutex-Funktionen wird zur Verfügung gestellt von NSLock und NSRecursiveLock.

    Um richtig zu schützen Sie nicht-atomaren Ressourcen, die Sie benötigen, diese Mutexe, damit nicht mehrere threads können versuchen, ändern Sie die Daten in der gleichen Zeit (führt zu Korruption) oder die Daten in einem halb-Zustand geändert (führt zu ungültigen Daten).

    Dein code würde wie folgt Aussehen:

    static NSLock session_id_lock;
static unsigned int session_id = 1000;

- (int) generateSessionID{
    int new_id;
    [myLock lock];
    new_id = session_id++;
    [myLock unlock];
    return new_id;
}

    Wenn Sie nicht mit dem Kakao (oder was kleines Cocoa-Programmierung habe ich mich von meinem kurzen Intermezzo mit einem iMac ist so schwach erinnern, dass es in der Nähe nutzlos ist), nutzen Sie einfach das Konzept, die übersetzungen in irgendeiner Sprache oder framework, das Sie haben:

    • Sperre den mutex bevor Sie Sie verwenden oder ändern einer geschützten Ressource.
    • verwenden, oder ändern Sie die Ressource.
    • entsperren des mutex.
    • bonus Tipp 1: sperren der mutex-so spät wie möglich und entsperren Sie es so bald wie möglich.
    • bonus Tipp 2: nur sperren, was Sie brauchen, so dass Sie vermeiden unnötige Verzögerungen.

    Erklären, dass der Letzte Punkt etwas mehr: wenn Sie für die Synchronisation auf self für zwei völlig unabhängige Dinge (z.B. eine session-ID und eine Benutzer-ID), werden Sie sich gegenseitig blockieren trotz der Tatsache, dass es ist nicht notwendig, dies zu tun. Ich würde lieber zwei separate Mutexe zu halten, die Granularität gering.

    Natürlich, wenn Sie nur ein mutex auf die session-ID alleine (aber siehe unten für caveat), fühlen Sie sich frei zu verwenden synchronized(self) aber ich würde es vorziehen, es zu tun meinen Weg, so würde ich mich nicht erwischt, das hinzufügen eines weiteren geschützten Ressource später.

    In jedem Fall (das ist der Nachteil erwähnt), werden Sie wahrscheinlich feststellen, dass die Synchronisierung auf self würde nicht ausreichend schützen, eine statische variable, die würde geteilt auf mehrere Objekte. Die mutex sollte gehören zu den Daten statt, was ist die Verwendung es.

    • Ich komme aus der Java-Welt, wo Sie einfach tun können: static synchronized int generateID(){return sessionId++}. ist dieser kompatibel ist, wenn ich tun -(int) generateSessionID{synchronized(self){return session_id++;}}?
    • Ich würde denken, dass funktionieren würde, aber okay, eine Sperre auf sich selbst (das Objekt) ist wohl breiter als ich es tun würde. Stattdessen würde ich lieber eine spezielle mutex, um zu vermeiden, mutex Verzögerungen, die überflüssig waren (siehe my added bonus Tipp).
    • In der Nähe, aber Sie nicht wollen, zu synchronisieren self für eine Instanz-Methode, die den Zugriff auf eine statische variable; vielleicht sync auf [self class] oder auf ein Objekt, das in direktem Zusammenhang mit dem Wert, den Sie gerade Bearbeiten (z.B. wickeln Sie das int in ein NSNumber-und sync-auf der NSNumber).
    • Ah, guter Punkt, ich vergaß, es war statisch so genutzt werden könnte mehrere Objekte - ich werde passen Sie die Antwort.
    • David, ich sehe Ihren Punkt, und ich dachte, der Verpackung und der Deklaration der ein NSNumber statt int, aber wo/Wann genau man entbinden den NSNumber, wie es sein wird (werden kann) abgerufen werden, durch den Bau von anderen Objekten zu erzeugen, deren ids.
    • Ich würde nicht denken, Sie würden sich sorgen machen müssen Sie es freigeben. Sie könnte es schaffen & initialisieren es mit 0 eine +initialize method (siehe stackoverflow.com/questions/992070/...); aber einmal erstellt, geht es nicht Weg.
    • Erwägen Sie die Verwendung GCD ' s dispatch_semaphore_create statt NSLock. Diese können gesperrt und entsperrt werden aus jedem thread, im Gegensatz zu NSLock, die verwendet werden auf dem gleichen thread immer.
    • laut @JeremyP in einem Kommentar auf die Frage, sollten Sie die Synchronisierung auf [MyClass class], nicht [self class]. Es scheint @JeremyP sagt [self class] zurückkehren wird, ein anderes Objekt zu jeder Zeit, nicht um ein singleton.
    • was JeremyP sagt, ist nicht, dass [self class] gibt ein anderes Objekt jedes mal. Er sagt, dass, wenn Sie eine Unterklasse MySubclass, der erbt von MyClass, [self class] zurück [MySubclass class] aufgerufen, wenn eine Instanz von MySubclass. Es ist ein Gültiger Punkt.

    InformationsquelleAutor paxdiablo
  2. 9

    Ich denke, du bist besser dran mit Atomare Operationen zu ändern session_id. Ein Vorherige Frage Gespräche über Atomare Inkrement/Dekrement-Operationen für OS X, und auf dieser Seite spricht über die OSAtomic header-Datei. Atomare Operationen auf ganze zahlen, etwas, das leicht die hardware-unterstützte, wird wohl wesentlich schneller als mit Verriegelung konstruiert.

    InformationsquelleAutor Wyatt Anderson
  3. 2

    Antwort 4 Jahre später jetzt in iOS8. :o)
    Das beste für mich ist die Verwendung einer singleton-Klasse wie folgt :

    (yourFile.h)

    #import <Foundation/Foundation.h>

@interface singletonSessionId : NSObject

+ (singletonMsgNbr*)sharedSingleton;

- (void)generateSessionId;

@property NSInteger value;

@end

    =====================================================
    (yourFile.m)

    #import "singletonSessionId.h"

@implementation singletonSessionId
@synthesize value = _value;

+ (singletonMsgNbr*)sharedSingleton {

    static singletonSessionId *instance = nil;

    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        instance = [[singletonSessionId alloc]init];
        instance.value = 1000;
    });

    return instance;
}

- (void)generateSessionId {
    _value += 1;
}

@end

    Müssen Sie nur rufen Sie die Methode 'generateSessionId' für jede neue Id-Wert.
    Die Verwendung dieser Klasse für die Generierung der session-Ids sollten weit genug, denke ich.

    Hoffe, es wird helfen, die Leser von diesem post. :o)

    BEARBEITEN

    Wie bereits von einigen Lesern, die NSInteger 'Wert' ist nicht thread sicher Folgen diesem Weg, nur das singleton ist.

    Erhalten Sie eine komplette thread-safe 'Wert' instance variable ändern Sie dessen Typ NSInteger in NSNumber (werden umgewandelt in 'int' mit entsprechenden Methoden) das ist vollständig thread-sichere laut apples Dokumentation.

    Dies ist möglicherweise der einfachste und Schnellste Weg zu bekommen, was gewünscht ist.

    • ja und das ist genau das, was es bedeutete, zu tun =>', Sie brauchen nur zu rufen Sie die Methode 'generateSessionId' für jede neue Id-Wert'.
    • Sorry für die späte Antwort, es funktioniert wie ein Charme, ich habe einen Fehler gemacht nur.
    • Ist dieser thread sicher? Angenommen, thread1 Anrufe generateSessionID, dann Thread2 verzahnt Anrufe generateSessionID, bevor thread1 hat hatte eine chance, um den Wert abzurufen? Würden Sie nicht beide mit der gleichen id? Und wenn Sie beide rufen Sie die Methode in der gleichen Zeit, ist da nicht Potenzial für Speicher-Korruption, da keine Synchronisierung-tool verwendet wird?
    • dispatch_once blockiert alle Anrufe, bis einer von Ihnen erfolgreich ist. Die docs sagen ", Wenn es gleichzeitig von mehreren threads, diese Funktion wartet, synchron, bis der block fertig ist." In der Tat, die Methode wurde speziell für diesen Anwendungsfall: "Diese Funktion ist nützlich für die Initialisierung von globalen Daten (singletons) in einer Anwendung. Immer rufen Sie diese Funktion vor der Verwendung oder Prüfung keine Variablen initialisiert werden, die durch den block."
    • Dies ist nicht thread-sicher aus genau dem Grund, dass @jk7 Staaten. Die dispatch_once hat nichts damit zu tun, weil es nicht aufgerufen wird, wenn der Aufruf generateSessionId
    • ist die richtige. Damals dachte ich, mit einer perfekten thread-sichere singleton war genug, um zu generieren und das Inkrement einer variable in einem thread-sichere Weise. Das ist definitiv nicht der Fall. Meiner Ansicht nach, der beste Weg, um Lesen und schreiben einer Instanzvariablen die mit keiner race-condition ist der "dispatch_barriers' - Funktion zur Verfügung gestellt von Grand Central Dispatch. Paar Dinge werden umgesetzt, aber zu einem Ergebnis, das 100% sicher.

    InformationsquelleAutor XLE_22
  4. 1

    Es gibt viele Optionen, einschließlich (von high-level auf low-level) @synchronized Objective-C RichtlinieNSLock, pthread_mutex_lock und Atomare Operationen.

    Lesen Sie die "Synchronisierung" der Threading Programming Guide für details.

    InformationsquelleAutor David Gelhar
Schreibe einen Kommentar