Was ist der Unterschied zwischen den atomaren und nicht-atomaren Attributen?

https://stackoverflow.com/questions/588866

09-09-2019
|

Frage

Was atomic und nonatomic in Eigenschaftsdeklarationen bedeuten?

@property(nonatomic, retain) UITextField *userName;
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName;

Was ist der operative Unterschied zwischen diesen drei?

Lösung

Die letzten beiden sind identisch; „Atomare“ ist das Standardverhalten ( ~~beachten Sie, dass es nicht wirklich ein Schlüsselwort ist, es durch das Fehlen von nonatomic nur angegeben~~ - atomic wurde als Schlüsselwort in der letzten Versionen von llvm / Klirren hinzugefügt).

Unter der Annahme, dass Sie die Methode Implementierungen @synthesizing, Atom vs. nicht-atomaren Änderungen der generierte Code. Wenn Sie Ihren eigenen Setter / Getter schreiben, Atom / nonatomic / behalten / assign / copy sind lediglich beratenden Charakter haben. (Hinweis: @synthesize ist jetzt das Standardverhalten in der letzten Versionen von LLVM Es gibt auch keine Notwendigkeit, Instanzvariablen zu erklären, werden sie automatisch synthetisiert werden, auch, und haben eine _ ihren Namen vorangestellt versehentlichen direkten Zugriff zu verhindern.).

Mit „atomic“, die synthetisierte Setter / Getter wird sichergestellt, dass ein ganz Wert immer aus dem Getter oder gesetzt durch den Setter zurückgeführt wird, unabhängig von der Setter-Aktivität auf einem anderen Thread. Das heißt, wenn Thread A in der Mitte des Getter ist, während Thread B die Setter nennt, ein tatsächlicher tragfähige Wert - ein Autoreleased Objekt, höchstwahrscheinlich -. Wird den Anrufer in A zurückgeführt wird

In nonatomic werden keine solche Garantien. Somit ist nonatomic wesentlich schneller als „atomaren“.

Was "atomic" hat nicht zu tun ist keine Garantien über die Thread-Sicherheit machen. Wenn Thread A wird das Getter gleichzeitig mit Gewinde B anruft und C der Setter mit unterschiedlichen Werten nennen, kann Thread A erhalten eine der drei Werte zurückgeführt - die eine vor irgendwelchen setters aufgerufen wird oder eine der beiden Werte in die Einrichter weitergegeben Ebenfalls in B und C kann das Objekt mit dem Wert von B oder C, keine Möglichkeit, am Ende zu erzählen.

Sicherstellung der Datenintegrität - eine der primären Herausforderungen der Multi-Threaded-Programmierung -. Durch andere Mittel erreicht wird

Rechnet man dazu:

atomicity eine einzige Eigenschaft auch nicht Thread-Sicherheit garantieren, wenn mehrere abhängigen Eigenschaften im Spiel sind.

Bedenken Sie:

 @property(atomic, copy) NSString *firstName;
 @property(atomic, copy) NSString *lastName;
 @property(readonly, atomic, copy) NSString *fullName;

In diesem Fall könnte Thread A das Objekt Umbenennung von setFirstName: aufrufen und dann setLastName: aufrufen. In der Zwischenzeit kann Thread B fullName zwischen Thread A die beiden Anrufe anrufen und den neuen Vornamen mit dem alten Nachnamen gekoppelt erhalten.

Um dies zu adressieren, müssen Sie ein Transaktionsmodell . D. h eine andere Art von Synchronisation und / oder Ausschluss, dass man Zugang zu fullName ausschließen kann, während die abhängigen Eigenschaften aktualisiert werden.

Andere Tipps

Dies ist in Apples Dokumentation erklärt , unten aber sind einige Beispiele dafür, was wirklich geschieht. Beachten Sie, dass es kein „atomares“ Schlüsselwort, wenn Sie „nonatomic“ nicht angeben, dann ist die Eigenschaft, atomar, aber die Angabe „atomare“ ausdrücklich zu einem Fehler führen wird.

//@property(nonatomic, retain) UITextField *userName;
//Generates roughly

- (UITextField *) userName {
    return userName;
}

- (void) setUserName:(UITextField *)userName_ {
    [userName_ retain];
    [userName release];
    userName = userName_;
}

Nun wird die Atom Variante ist etwas komplizierter:

//@property(retain) UITextField *userName;
//Generates roughly

- (UITextField *) userName {
    UITextField *retval = nil;
    @synchronized(self) {
        retval = [[userName retain] autorelease];
    }
    return retval;
}

- (void) setUserName:(UITextField *)userName_ {
    @synchronized(self) {
      [userName_ retain];
      [userName release];
      userName = userName_;
    }
}

Grundsätzlich ist die Atom-Version hat eine Sperre zu ergreifen, um die Thread-Sicherheit zu gewährleisten, und auch auf dem Objekt die ref Zählung stoßen (und die Autorelease Zählung es zu balancieren), so dass das Objekt gewährleistet ist für den Anrufer existieren , sonst gibt es eine mögliche race-Bedingung, wenn ein anderer Thread den Wert einstellt, wodurch der Verweiszähler auf 0 fallen.

Es gibt tatsächlich eine große Anzahl von verschiedenen Varianten, wie diese Dinge funktionieren, je nachdem, ob die Eigenschaften sind skalare Werte oder Objekte und wie zu behalten, zu kopieren, nur lesbar, nonatomic usw. interagieren. Im Allgemeinen weiß die Eigenschaft Synthesizern, wie das „Richtige“ für alle Kombinationen zu tun.

Atomic

ist das Standardverhalten
wird das vorliegende Verfahren gewährleistet ist, die durch die CPU abgeschlossen, bevor ein anderer Prozess die Variable
nicht schnell ist, da es den Prozess stellt sicher, vollständig abgeschlossen

Non-Atomic

ist nicht das Standardverhalten
schneller (für synthetisierte Code, das heißt, für Variablen @property und @synthesize erstellt)
nicht thread-safe
zu unerwartetem Verhalten führen kann, wenn zwei verschiedene Verfahren Zugriff auf die gleiche Variable zugleich

Der beste Weg, um die Differenz wird mit dem folgenden Beispiel zu verstehen.

Angenommen, es gibt eine Atom String-Eigenschaft „name“ genannt, und wenn man [self setName:@"A"] von Thread A nennen, [self setName:@"B"] von Thread B nennen, und [self name] aus Thread C aufrufen, werden alle Operationen auf verschiedenen Threads werden seriell durchgeführt werden, was bedeutet, wenn ein Faden oder ein setter Getter ausgeführt wird, dann andere Threads warten.

Das macht Eigenschaft „name“ lesen / schreiben sicher, aber wenn ein anderer Thread, D, ruft [name release] gleichzeitig dann könnte dieser Vorgang einen Absturz erzeugen, weil es keine Setter / Getter Anruf hier beteiligt ist. Das heißt, ein Objekt gelesen wird / Schreib Safe (ATOMIC), aber nicht threadsicher als eine andere Threads gleichzeitig jede Art von Nachrichten an das Objekt senden können. Der Entwickler sollte Thread-Sicherheit für solche Objekte gewährleisten.

Wenn die Eigenschaft „name“ nonatomic war, dann werden alle Fäden in obigen Beispiel - A, B, C und D wird ausgeführt, gleichzeitig jede unberechenbare Ergebnis. Im Fall eines Atom entweder ein von A, B oder C wird ausgeführt, die erste, aber noch D parallel ausführen können.

Die Syntax und Semantik sind bereits gut definiert durch andere hervorragende Antworten auf diese Frage. Da Ausführung und Leistung ist nicht gut detailliert, ich werde meine Antwort hinzuzufügen.

Was ist der funktionelle Unterschied zwischen diesen 3?

Ich würde immer atomar betrachtet als Standard recht neugierig. An der Abstraktionsebene arbeiten wir bei Verwendung von atomaren Eigenschaften für eine Klasse als ein Fahrzeug 100% gewinde Sicherheit eine Ecke Fall zu erreichen ist. Für wirklich richtig multithreaded Programme ist Intervention durch den Programmierer mit ziemlicher Sicherheit eine Voraussetzung. Inzwischen Leistungseigenschaften und die Ausführung noch nicht eingehend detailliert worden. Nachdem sie einige stark multithreaded Programme im Laufe der Jahre geschrieben, hatte ich meine Eigenschaften wie nonatomic die gesamte Zeit wurde erklärt, weil Atom für jeden Zweck nicht sinnvoll war. Bei der Diskussion der Details der atomaren und nicht-atomarer Eigenschaften diese Frage , ich habe einige Profilierung einige merkwürdige Ergebnisse gestoßen.

Ausführung

Ok. Das erste, was würde Ich mag zu klären ist, dass die Verriegelungs Implementierung ist die Implementierung definiert und abstrahiert. Louis verwendet @synchronized(self) in seinem Beispiel - ich dies als eine gemeinsame Quelle der Verwirrung gesehen habe. Die Umsetzung nicht wirklich Verwendung @synchronized(self); es nutzt Objektebene Spin-Locks . Louis Abbildung ist gut für eine High-Level-Darstellung unter Verwendung von Konstrukten wir alle kennen, aber es ist wichtig zu wissen, dass es nicht @synchronized(self) nicht verwendet.

Ein weiterer Unterschied besteht darin, dass atomare Eigenschaften behalten / Release-Zyklus Ihre Objekte innerhalb des Getter.

Performance

Hier ist der interessante Teil: Leistungsatom Eigenschaft mit Zugriffen in unbestrittenen (z single-threaded) Fällen kann in einigen Fällen wirklich sehr schnell sein. In weniger als idealen Fällen kann die Verwendung von Atom Zugriffen kostet mehr als 20-mal den Aufwand für nonatomic. Während der Contested Fall unter Verwendung von 7 Fäden betrug 44 mal langsamer für den Drei-Byte-struct (2,2 GHz Core i7 Quad-Core, x86_64). Die Drei-Byte-Struktur ist ein Beispiel für eine sehr langsame Eigenschaft.

Interessante Randnotiz: Benutzerdefinierte Accessoren der Drei-Byte-Struktur waren 52-mal schneller als die synthetisierten Atom Accessoren; oder 84% der Geschwindigkeit des synthetisierten nonatomic Accessoren.

Gegenstände in streitigen Fällen übersteigen auch 50-mal.

Aufgrund der Anzahl von Optimierungen und Variationen in Implementierungen, ist es ziemlich schwierig, reale Auswirkungen in diesen Kontexten zu messen. Sie hören vielleicht oft so etwas wie „es Vertrauen, wenn Sie das Profil und finden es ist ein Problem“. Aufgrund der Abstraktionsebene, es ist eigentlich ziemlich schwierig tatsächliche Auswirkungen zu messen. Nachlese tatsächlich Kosten von Profilen kann sehr zeitaufwendig sein, und aufgrund Abstraktionen, ziemlich ungenau. Wie gut, ARC vs MRC kann einen großen Unterschied machen.

So ist Schritt zurück lassen, nicht über die Umsetzung der Eigenschaft Fokussierung Zugriffe werden wir die üblichen Verdächtigen wie objc_msgSend umfassen, und untersuchen einige der realen Welt High-Level-Ergebnisse für viele Anrufe an eine NSString Getter in unbestrittenen Fälle (Werte in Sekunden):

MRC | nonatomic | manuell implementiert Getter: 2
MRC | nonatomic | synthetisierten Getter: 7
MRC | Atom | synthetisierten Getter: 47
ARC | nonatomic | synthetisierten Getter: 38 (Anmerkung: ARC Zugabe von Ref Anzahl Radtouren)
ARC | Atom | synthetisierten Getter: 47

Wie Sie wahrscheinlich schon erraten haben, Referenzzähler Aktivität / Radfahren ist ein wichtiger Beitrag mit atomics und unter ARC. Sie würden auch greate sehenr Unterschiede in strittigen Fällen.

Obwohl ich aufmerksam auf die Leistung zahlen, sage ich immer noch Semantics zuerst! . Inzwischen ist die Leistung eine niedrige Priorität für viele Projekte. Aber zu wissen, die Ausführungsdetails und Kosten von Technologien, die Sie sicherlich nicht verwenden verletzt. Sie sollten die richtige Technologie für Ihre Bedürfnisse, Zwecke und Fähigkeiten nutzen. Hoffentlich wird Ihnen ein paar Stunden Vergleiche speichern, und helfen Ihnen, eine fundiertere Entscheidung, wenn Ihre Programme zu entwerfen.

Atomic = Thread-Sicherheit

Nicht-Atom = No Thread-Sicherheit

Thread-Sicherheit:

Instanzvariablen sind Thread-sicher, wenn sie korrekt verhalten, wenn sie von mehreren Threads zugegriffen wird, unabhängig von der Terminplanung oder Verschachtelung der Ausführung dieser Themen von der Laufzeitumgebung, und ohne zusätzliche Synchronisation oder andere Koordination auf Seiten des rufenden Code.

In unserem Zusammenhang:

Wenn ein Thread ändert den Wert der Instanz des geändertene Wert zu allen Themen zur Verfügung steht, und nur ein Thread den Wert zu einer Zeit ändern kann.

Wo `atomic` verwenden:

, wenn die Instanz-Variable würde in einer Multithread-Umgebung zugegriffen werden.

Verwicklung von `atomic`:

Nicht so schnell wie nonatomic weil nonatomic erfordert keine Watchdog-Arbeit an, dass von der Laufzeit.

Wo `nonatomic` verwenden:

Wenn die Instanz-Variable werde nicht von mehreren Threads geändert werden können Sie es verwenden. Es verbessert die Leistung.

ich eine ziemlich gut setzen Erklärung von atomaren und nicht-atomaren Eigenschaften gefunden

so viele Artikel Nach dem Lesen, Stack-Überlauf-Beiträge und machen Demo-Anwendungen variable Eigenschaft Attribute zu überprüfen, entschied ich mich Informationen über alle Attribute zusammen zu stellen:

atomic // Standard
nonatomic
strong = retain // Standard
weak = unsafe_unretained
retain
assign // Standard
unsafe_unretained
copy
readonly
readwrite // Standard

Im Artikel Variable Eigenschaft Attribute oder Modifikatoren in iOS können Sie alle oben genannten Attribute finden, und das wird definitiv helfen.

atomic
- atomic bedeutet, nur ein Thread Zugriff auf die Variable (statischen Typ).
- atomic ist Thread-sicher.
- Aber es ist langsam in der Leistung
- atomic ist das Standardverhalten
- Atomic Accessoren in einer nicht Müll gesammelt Umgebung (das heißt, wenn behalten Verwendung / release / Autorelease) wird eine Sperre, um sicherzustellen, dass ein anderer Thread nicht mit der richtigen Einstellung / getting des Wertes nicht stört.
- Es ist nicht wirklich ein Schlüsselwort.
Beispiel:
```
    @property (retain) NSString *name;

    @synthesize name;
```
nonatomic
- bedeutet nonatomic mehrere Threadzugriff die Variable (dynamic-Typ).
- nonatomic ist faden unsicher.
- Aber es ist schnell in der Leistung
- nonatomic ist nicht das Standardverhalten. Wir brauchen das nonatomic Schlüsselwort in der Eigenschaft Attribute hinzuzufügen.
- Es kann zu unerwartetem Verhalten führen, wenn zwei verschiedene Verfahren (Threads) die gleiche Variable in der gleichen Zeit zugreifen.
Beispiel:
```
    @property (nonatomic, retain) NSString *name;

    @synthesize name;
```

Atomic:

Atomic garantiert, dass auf die Eigenschaft zugreifen in einer atomaren Weise durchgeführt werden. Z.B. es zurückgeben immer ein vollständig initialisiert Objekte, jede get / set einer Eigenschaft auf einem Thread durchführen müssen, bevor ein anderer darauf zugreifen können.

Wenn Sie die folgende Funktion vorstellen auftretenden auf zwei Threads auf einmal Sie sehen, warum die Ergebnisse nicht schön sein würde.

-(void) setName:(NSString*)string
{
  if (name)
  {
    [name release]; 
    // what happens if the second thread jumps in now !?
    // name may be deleted, but our 'name' variable is still set!
    name = nil;
  }

  ...
}

Vorteile: Rückkehr der vollständig initialisierte Objekte jedes Mal ist es die beste Wahl bei Multi-Threading.

Nachteile: Performance-Einbußen, macht die Ausführung etwas langsamer

Nicht-Atomic:

Im Gegensatz zu Atomic, es sicherzustellen, nicht vollständig initialisierte Objekt jedes Mal zurück.

Vorteile: Extrem schnelle Ausführung.

Nachteile: Die Chancen von Müll Wert bei Multi-Threading.

Die einfachste Antwort zuerst: Es gibt keinen Unterschied zwischen den zweiten zwei Beispielen. Standardmäßig sind, Eigenschaftenaccessoren Atom.

Atomic Accessoren in einer nicht Müll gesammelt Umgebung (das heißt, wenn behalten Verwendung / release / Autorelease) wird eine Sperre, um sicherzustellen, dass ein anderer Thread nicht mit der richtigen Einstellung nicht stört / getting des Wertes.

Siehe „ Leistung und Threading “Abschnitt für einige weiteren Informationen Objective-C 2.0-Dokumentation von Apple und für andere Überlegungen bei Multi-threaded-Anwendungen zu schaffen.

Atomic bedeutet, nur ein Thread die Variable (statischen Typ) zugreift. Atomic ist Thread-sicher, aber es ist langsam.

nichtatomare bedeutet, mehrere Threads die Variable (dynamic-Typ) zuzugreifen. Nonatomic ist faden unsicher, aber es ist schnell.

Atomic ist Threadsicherheit , es ist langsam und gut versichert (nicht garantiert) , dass nur der gesperrte Wert egal vorgesehen ist wie viele Threads Zugriff auf die gleichen Zone versucht. Beim atomic Verwendung Code ein Stück innerhalb dieser Funktion geschrieben wird, den Teil des kritischen Abschnitts, an dem nur ein Thread zu einem Zeitpunkt ausführen kann.

Es sichert nur die Thread-Sicherheit; es nicht, dass gewährleisten. Was ich meine ist, dass Sie einen Experten Fahrer für Sie Autovermietung, noch ist es nicht garantiert, Auto nicht einen Unfall treffen. Allerdings Wahrscheinlichkeit bleibt die geringste.

Atomic - es ist nicht aufgeschlüsselt werden kann, so das Ergebnis zu erwarten ist. Mit nonatomic -., Wenn ein anderer Thread Zugriff auf die Speicherzone es es ändern kann, so das Ergebnis unerwartet

Code-Diskussion:

Atomic Getter und Setter der Immobilie Thread-sicher machen. zum Beispiel, wenn u haben geschrieben:

self.myProperty = value;

ist Thread-sicher.

[myArray addObject:@"Abc"]

ist nicht Thread-sicher.

Es gibt kein solches Schlüsselwort "atomic"

@property(atomic, retain) UITextField *userName;

Wir können die oben verwenden wie

@property(retain) UITextField *userName;

Siehe Frage Stack-Überlauf Ich bekomme Probleme, wenn ich @property verwenden (atomar, retain) NSString * myString .

Die Standard ist atomic, dies bedeutet es Ihnen Leistung kostet, wenn Sie die Eigenschaft verwenden, aber es ist Thread-sicher. Was für Objective-C ist, wird eine Sperre gesetzt, so dass nur der tatsächliche Thread die Variable zugreifen kann, solange die setter / Getter ausgeführt wird.

Beispiel mit MRC einer Immobilie mit einem Ivar _internal:

[_internal lock]; //lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;

So die letzten beiden sind die gleichen:

@property(atomic, retain) UITextField *userName;

@property(retain) UITextField *userName; // defaults to atomic

Auf der anderen Seite tut nonatomic nichts, um Ihren Code hinzufügen. So ist es nur Thread-sicher, wenn Sie Sicherheitsmechanismus Code selbst.

@property(nonatomic, retain) UITextField *userName;

Die Schlüsselwörter haben gar nicht als erste Eigenschaft Attribut geschrieben werden.

Vergessen Sie nicht, dies nicht bedeutet, dass die Eigenschaft als Ganzes ist Thread-sicher. Nur der Aufruf der Methode des Setter / Getter ist. Aber wenn Sie einen Setter verwenden und danach ein Getter zur gleichen Zeit mit zwei verschiedenen Threads, könnte es auch gebrochen werden!

Atom (default)

Atomic ist der Standard: Wenn Sie nichts geben Sie, Ihr Eigentum ist   atomar. Eine atomare Eigenschaft ist garantiert, dass, wenn Sie versuchen, lesen von   es wird Sie einen gültigen Wert zurück. Es macht keine Garantien   über das, was könnte dieser Wert sein, aber Sie werden gute Daten zurückbekommen, nicht   nur Junk-Speicher. Was dies ermöglicht es Ihnen zu tun ist, wenn Sie mehrere haben   Gewinde oder mehr Prozesse in einer einzigen Variablen zeigen, ein   Thread kann lesen und ein anderer Thread schreiben. Wenn treffen sie auf dem gleichen   Zeit wird der Leser Thread garantiert einen der beiden Werte zu erhalten:   entweder vor der Änderung oder nach der Änderung. Was für Atom nicht   Sie sind jede Art von Garantie über Sie, welche diesen Wert   vielleicht bekommen. Atomic ist wirklich häufig verwechselt mit dem Sein Thread-sicher,   und das ist nicht richtig. Sie benötigen eine Thread-Sicherheit zu gewährleisten,   andere Möglichkeiten. Atom wird jedoch garantieren, dass, wenn Sie zu lesen versuchen,   Sie irgendeine Art von Wert zurück.

nonatomic

Auf der anderen Seite, nicht-atomar, wie Sie wahrscheinlich erraten kann, bedeutet nur,   „Tun das nicht atomar Sachen.“ Was Sie verlieren ist, dass Garantie, dass Sie   immer etwas zurück. Wenn Sie versuchen, in der Mitte eines lesen   schreiben Sie Müll Daten könnten zurück. Aber auf der anderen Seite, gehen Sie   ein bisschen schneller. Da atomare Eigenschaften haben etwas Magie zu tun   zu garantieren, dass Sie einen Wert zurückbekommen werden, sind sie ein wenig langsamer. Wenn   es ist eine Eigenschaft, die Ihnen eine Menge zugreifen, Sie fallen können möchten   bis auf die nicht-atomare, um sicherzustellen, dass Sie nicht, dass die Geschwindigkeit entstehen   Strafe.

Sehen Sie mehr hier: https://realm.io/news/tmi-objective-c- property-Attribut /

Wenn Sie Ihre Immobilie in Multi-Threaded-Code verwenden, dann würden Sie in der Lage sein, den Unterschied zwischen nonatomic und atomaren Eigenschaften zu sehen. Nonatomic ist schneller als Atom- und Atom ist Thread-sicher, nicht nonatomic.

Vijayendra Tripathi hat bereits ein Beispiel für eine Multi-Threaded-Umgebung gegeben.

-Atomic bedeutet, nur ein Thread Zugriff auf die Variable (statischen Typ).
-Atomic ist Thread-sicher.
-aber es langsam in der Leistung

Wie deklarieren:

Als Atom ist standardmäßig so,

@property (retain) NSString *name;

UND in Implementierungsdatei

self.name = @"sourov";

eine Aufgabe zu drei Eigenschaften im Zusammenhang Angenommen sind

 @property (retain) NSString *name;
 @property (retain) NSString *A;
 @property (retain) NSString *B;
 self.name = @"sourov";

Alle Objekte arbeiten parallel (wie asynchron).

Wenn Sie rufen "name" aus Thread A ,

und

Zur gleichen Zeit, wenn Sie anrufen

[self setName:@"Datta"]

vom Faden B

Jetzt Wenn * Name Eigenschaft ist nonatomic und

Es wird Rückgabewert "Datta" für A
Es wird Rückgabewert "Datta" für B

Das ist, warum nicht atomar Thread unsichere genannt Aber, aber es ist schnell in der Leistung wegen der parallelen Ausführung

Jetzt Wenn * Name Eigenschaft ist Atom

Es wird sicherstellen Wert "Sourov" für A
Dann wird es Rückgabewert "Datta" für B

Deshalb Atom heißt Threadsicherheit und Aus diesem Grund heißt es read-write sicher

Eine solche Situation Operation wird seriell auszuführen. und langsam in der Leistung

- bedeutet, nichtatomare mehrere Threadzugriff der Variable (dynamische Typ)

- nichtatomare ist Thread unsichere

- aber es ist schnell in der Leistung

-Nonatomic NICHT Standardverhalten, müssen wir nonatomic Stichwort in Eigenschaft Attribute hinzuzufügen.

In Swift Bestätigung, dass Swift Eigenschaften nonatomic im ObjC Sinne sind. Ein Grund dafür ist, so dass Sie darüber nachdenken, ob pro-Eigenschaft Unteilbarkeit ist für Ihre Bedürfnisse ausreichend.

Referenz: https://forums.developer.apple.com/thread/25642

Fro weitere Informationen besuchen Sie bitte die Website http://rdcworld-iphone.blogspot.in/ 2012/12 / Variable-Eigenschaft-Attribute-or.html

Bevor Sie beginnen: Sie müssen wissen, dass jedes Objekt im Speicher aus dem Speicher werden muss freigegeben für einen neuen Schriftsteller zu geschehen. Sie können nicht nur einfach oben auf etwas schreiben, wie Sie es auf Papier tun. Sie muss ersten Lösch (dealloc) es und dann können Sie auf sie schreiben. Wenn im Moment, dass der Lösch erfolgt (oder halb fertig) und nichts hat noch geschrieben worden ist (oder die Hälfte geschrieben hat) und Sie versuchen, zu lesen, könnte es sehr problematisch sein! Atomic und nonatomic Hilfe Sie dieses Problem auf unterschiedliche Weise behandeln.

Lesen Sie zuerst Frage href="https://stackoverflow.com/questions/21098494/atomic-properties-vs-thread-safe-in-objective-c"> und lesen dann BBUM Antwort . Darüber hinaus lesen dann meine Zusammenfassung.

atomic wird immer garantieren,

Wenn zwei verschiedene Personen zur gleichen Zeit lesen und schreiben wollen, Ihr Papier wird nicht nur brennen! -.> Ihre Bewerbung wird nie abstürzen, auch in einem Race-Bedingung
Wenn eine Person zu schreiben versucht und hat nur 4 der 8 Buchstaben geschrieben zu schreiben, dann in der Mitte nicht lesen kann, kann das Lesen nur dann erfolgen, wenn alle acht Buchstaben geschrieben -> Kein Lesen (get) geschehen wird auf ‚einen Thread, der noch zu schreiben ist‘, das heißt, wenn es 8 Bytes Bytes geschrieben werden, und nur 4 Bytes geschrieben werden - bis zu diesem Moment, Sie sind nicht lesen von ihm erlaubt. Aber da ich sagte, es wird nicht abstürzen, dann wäre es aus dem Wert eines lesen Autoreleased Objekt.
Wenn vor Schreiben Sie Haben gelöscht, was vorher auf Papier geschrieben und dann jemand will Sie lesen noch lesen. Wie? Sie werden von etwas ähnlich wie Mac OS Papierkorb lesen werden (als Papierkorb wird nicht noch 100% gelöscht ... es in einem Schwebezustand ist) ---> Wenn ThreadA zu lesen ist, während ThreadB bereits zu schreiben hat freigegeben, würden Sie bekommen ein Wert von entweder den letzten vollständig geschriebenen Wert von ThreadB oder etwas von Autofreigabepool erhalten.

Bewahren zählt, sind die Art und Weise, in dem Speicher in Objective-C verwaltet wird. Wenn Sie ein Objekt erstellen, hat es eine Anzahl von 1. behalten, wenn Sie senden ein Objekt einer Nachricht halten, wird sein Beibehaltungszähler um 1 erhöht, wenn Sie ein Objekt einer Release-Nachricht senden, wird sie behalten dekrementiert von 1. Wenn Sie ein Objekt einer Autofreigabe Nachricht senden , seine Beibehaltungszähler um 1 zu einem bestimmten Zeitpunkt in der Zukunft verringert. Wenn ein object's behalten Zahl wird auf 0 reduziert, wird aufgehoben.

Atomic nicht Garantie Thread-Sicherheit, obwohl es für die Erreichung Thread-Sicherheit nützlich ist. Thema Sicherheit ist in Bezug auf, wie Sie Ihren Code schreiben, / die Thread-Warteschlange Sie Lesen / Schreiben aus. Es garantiert nur nicht-zerbrechbare Multithreading.

Was ?! Sind Multithreading und Thread-Sicherheit anders?

Ja. Multithreading bedeutet: mehrere Threads ein gemeinsames Stück von Daten zur gleichen Zeit lesen können und wir werden nicht abstürzen, aber es garantiert nicht, dass Sie nicht von einem Nicht-Autoreleased Wert lesen. Mit Thread-Sicherheit, es ist garantiert, dass das, was Sie lesen nicht automatisch freigegeben ist. Der Grund, dass wir nicht alles Atomstandardmäßig machen, ist, dass es eine Performance-Kosten und für die meisten Dinge nicht wirklich Thread-Sicherheit benötigen. Einige Teile unseres Code benötigen sie und für die wenigen Teile, müssen wir unseren Code in einem Thread-sichere Art und Weise mit Schlössern, Mutex oder Synchronisation.

schreiben

nonatomic

Da gibt es so etwas wie Mac OS Mülleimer nein, dann kümmert sich niemand, ob Sie immer einen Wert bekommen (<- dies unter Umständen zu einem Absturz führen könnte), noch jemand interessiert sich, wenn jemand zu lesen versucht, auf halbem Weg durch Ihre Schreiben (obwohl auf halber Strecke in memor schreibeny ist sehr verschieden von der Hälfte auf Papier zu schreiben, auf das Gedächtnis es Sie verrückt dumm Wert von vor geben konnte, während auf dem Papier Sie nur die Hälfte von dem, was) geschrieben worden -> kann keine Gewähr für nicht abstürzen, weil es doesn t Gebrauch Autofreigabemechanismus.
Ist voll geschriebenen Werte nicht garantieren, gelesen werden!
Ist schneller als Atom

Insgesamt sind sie unterschiedlich in zwei Aspekten:

Crashing oder nicht, weil der mit oder ohne einen Autorelease Pool.
Unter Berücksichtigung in der Mitte eines ‚noch nicht fertig Schreib- oder leeren Wert‘ oder nicht erlaubt und nur zu lesen erlaubt zu lesen, wenn der Wert voll geschrieben.

Die atomare Eigenschaft sorgt für eine vollständig initialisierte Wert unabhängig von behalten, wie viele Threads Getter & Setter auf es tun.

Die nonatomic Eigenschaft gibt synthetisiert, dass Accessoren einfach eingestellt oder direkt einen Wert zurückgeben, ohne Garantien über das, was passiert, wenn diese denselben Wert gleichzeitig von verschiedenen Threads zugegriffen wird.

Atomic bedeutet, nur ein Thread die Variable zu einer Zeit (statischen Typ) zugreifen kann. Atomic ist Thread-sicher, aber es ist langsam.

nichtatomare bedeutet, mehrere Threads die Variable zur gleichen Zeit zugreifen können (dynamisch-Typ). Nonatomic ist faden unsicher, aber es ist schnell.

Atomicity Atom (Standard)

Atomic ist der Standard: Wenn Sie nichts geben Sie, Ihr Eigentum ist atomar. Eine atomare Eigenschaft ist garantiert, dass, wenn Sie versuchen, lesen von es wird Sie einen gültigen Wert zurück. Es macht keine Garantien über das, was könnte dieser Wert sein, aber Sie werden gute Daten zurückbekommen, nicht nur Junk-Speicher. Was dies ermöglicht es Ihnen zu tun ist, wenn Sie mehrere haben Gewinde oder mehr Prozesse in einer einzigen Variablen zeigen, ein Thread kann lesen und ein anderer Thread schreiben. Wenn treffen sie auf dem gleichen Zeit wird der Leser Thread garantiert einen der beiden Werte zu erhalten: entweder vor der Änderung oder nach der Änderung. Was für Atom nicht Sie sind jede Art von Garantie über Sie, welche diesen Wert vielleicht bekommen. Atomic ist wirklich häufig verwechselt mit dem Sein Thread-sicher, und das ist nicht richtig. Sie benötigen eine Thread-Sicherheit zu gewährleisten, andere Möglichkeiten. Atom wird jedoch garantieren, dass, wenn Sie zu lesen versuchen, Sie irgendeine Art von Wert zurück.

nonatomic

Auf der anderen Seite, nicht-atomar, wie Sie wahrscheinlich erraten kann, bedeutet nur, „Tun das nicht atomar Sachen.“ Was Sie verlieren ist, dass Garantie, dass Sie immer etwas zurück. Wenn Sie versuchen, in der Mitte eines lesen schreiben Sie Müll Daten könnten zurück. Aber auf der anderen Seite, gehen Sie ein bisschen schneller. Da atomare Eigenschaften haben etwas Magie zu tun zu garantieren, dass Sie einen Wert zurückbekommen werden, sind sie ein wenig langsamer. Wenn es ist eine Eigenschaft, die Ihnen eine Menge zugreifen, Sie fallen können möchten bis auf die nicht-atomare, um sicherzustellen, dass Sie nicht, dass die Geschwindigkeit entstehen Strafe. Zugang

https://academy.realm.io/posts / TMI-Ziel-c-Objekt-Attribut /

Atomicity Eigenschaft Attribute (Atom- und nonatomic) sind nicht in der entsprechenden Swift Eigenschaft Erklärung reflektiert, aber die Unteilbarkeit Garantien für die Objective-C-Implementierung noch halten, wenn die importierte Eigenschaft von Swift zugegriffen wird.

So -., Wenn Sie eine Atom Eigenschaft in Objective-C definieren wird es Atom bleiben, wenn sie von Swift verwendet

Mit freundlicher Genehmigung https://medium.com/@YogevSitton/ Atom-vs-nicht-atomar-Eigenschaften-Crash-Kurs-d11c23f4366c

Wenn Sie Atom verwenden, bedeutet dies, der Faden sicher sein wird und schreibgeschützt. Wenn Sie die nicht-atomare verwenden, bedeutet dies, die mehrere Threads auf die Variable zugreifen und ist Thread unsicher, aber es wird schnell ausgeführt, eine Lese- und Schreiboperationen durchgeführt; Dies ist ein dynamischer Typ.

Die Wahrheit ist, dass sie Spin-Lock verwenden Atom Eigenschaft zu implementieren. Der Code wie folgt:

 static inline void reallySetProperty(id self, SEL _cmd, id newValue, 
      ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy) 
    {
        id oldValue;
        id *slot = (id*) ((char*)self + offset);

        if (copy) {
            newValue = [newValue copyWithZone:NULL];
        } else if (mutableCopy) {
            newValue = [newValue mutableCopyWithZone:NULL];
        } else {
            if (*slot == newValue) return;
            newValue = objc_retain(newValue);
        }

        if (!atomic) {
            oldValue = *slot;
            *slot = newValue;
        } else {
            spin_lock_t *slotlock = &PropertyLocks[GOODHASH(slot)];
            _spin_lock(slotlock);
            oldValue = *slot;
            *slot = newValue;        
            _spin_unlock(slotlock);
        }

        objc_release(oldValue);
    }

Atomic Eigenschaften : -. Wenn eine Variable mit Atom-Eigenschaft zugewiesen, die es nur ein Thread Zugriff bedeutet hat, und es wird Thread-sicher sein und wird in Hinblick auf die Leistung gut sein, wird das Standardverhalten haben

Nicht Atomeigenschaften : - Wenn eine Variable mit atomaren Eigenschaft zugeordnet, bedeutet dies, Multi-Thread-Zugang hat, und es wird nicht sicher sein Gewinde und wird in Hinblick auf die Leistung langsam sein, wird das Standardverhalten haben und wenn zwei verschiedene Threads wollen bei gleichzeitig Variable zuzugreifen es zu unerwarteten Ergebnissen führen wird.

die ganze Verwirrung zu vereinfachen, lassen Sie uns Mutex-Sperre verstehen.

Mutex-Sperre, nach dem Namen, sperrt die Veränderlichkeit des Objekts. Also, wenn das Objekt durch eine Klasse zugegriffen wird, kann keine andere Klasse das gleiche Objekt zuzugreifen.

In iOS, @sychronise bietet auch die Mutex-Sperre .Jetzt es in FIFO-Modus dient und sorgt für die Strömung nicht durch zwei Klassen betroffen ist die gleiche Instanz zu teilen. Wenn jedoch die Aufgabe auf Hauptthread ist, vermeiden Sie den Zugriff auf Objekt mit atomaren Eigenschaften, wie sie können Ihre UI halten und die Leistung beeinträchtigen.

Atomic. Sicherstellen fade Sicherheit durch den Faden NSLOCK mit Sicherungs

Nicht Atom. Hat nicht Thread-Sicherheit gewährleistet, da es keinen Gewindesicherungsmechanismus ist

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow