Mi a különbség az atom- és nonatomic attribútumok?

Ennek magyarázata az Apple dokumentációt , de az alábbi néhány példa, hogy mi történik valójában. Vegyük észre, hogy nincs „atomi” kulcsszó, ha nem adja meg a „nonatomic”, akkor a tulajdonság atomi, de meghatározó „atomos” kifejezetten eredményez hibát.

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

- (UITextField *) userName {
    return userName;
}

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

Most, az atomi variáns egy kicsit bonyolultabb:

//@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_;
    }
}

Alapvetően az atomi változat, hogy a zár garantálása érdekében szál biztonsági, valamint döccen a ref száma az objektum (és a autorelease száma az egyensúly it), így a tárgy garantáltan létezik a hívó, különben nem potenciális versenyhelyzet, ha egy másik szál értékének beállítására, így a játékvezető száma csökken 0-ra.

Vannak valójában számos különböző változatai mennek ezek a dolgok attól függően, hogy az ingatlanok skalárnak vagy tárgyak, és hogyan megtartani, másolás, olvasható, nonatomic stb kölcsönhatásba lépnek. Általában az ingatlan szintetizátorok csak tudja, hogyan kell csinálni a „helyes dolgot” minden kombináció.

Atom

• az alapértelmezett viselkedés
• biztosítani fogja a jelen eljárás befejeződött a CPU, mielőtt egy másik folyamat hozzáfér a változó
• nem gyors, mivel ez biztosítja a folyamat befejeződik teljesen

Nem Atomic

• nem az alapértelmezett viselkedés
• gyorsabb (szintetizált kód, azaz a változók segítségével létrehozott @property és @synthesize)
• Nem szálbiztosak
• eredményeként váratlan viselkedése, amikor két különböző folyamat eléréséhez ugyanazon változó ugyanabban az időben

A legjobb módja annak, hogy megértsük a különbséget a következő példa.

Tegyük fel, hogy van egy atomi karaktersorozat tulajdonság az úgynevezett „név”, és ha hívjuk [self setName:@"A"]csavarmenetstoppal A, hívja [self setName:@"B"]csavarmenetstoppal B, és hívja [self name]csavarmenetstoppal C, akkor minden művelet a különböző szálak fogják elvégezni sorozatosan ami azt jelenti, ha egy szál végrehajt egy szetter vagy getter, akkor más szálak fog várni.

Ez teszi tulajdon „name” írható / olvasható biztonságos, de ha egy másik szál, D, felhívja [name release]egyszerre akkor ez a művelet lehet készíteni összeomlás, mert nincs szetter / getter hívás itt szó. Ami azt jelenti, egy objektum írni / olvasni széf (ATOMIC), de nem szálbiztosak, mint egy másik szál egyszerre küld bármilyen típusú üzeneteket a tárgy. A fejlesztő biztosítania kell szál-biztonsági ilyen tárgyakat.

Ha a tulajdonság „nevet” volt nonatomic, majd minden menetet fenti példában - az A, B, C és D végrehajtja egyidejűleg állítanak elő semmilyen előre nem megjósolható eredményeket. Abban az esetben, atomi, vagy az egyik A, B vagy C végrehajtja első, de a D még mindig végre párhuzamosan.

A szintaktikai és szemantikai már jól meghatározott más kiváló választ erre a kérdésre. Mivel kivitelezés és a teljesítmény nem részletezi is, majd add hozzá a választ.

Mi a funkcionális különbség a 3?

Én mindig úgy atomi alapértelmezett meglehetősen furcsa. Az absztrakciós szinten dolgozik, az atomi tulajdonságok egy osztály, mint egy jármű, hogy 100% szál-biztonság egy szöglet esetén. Az igazán helyes többszálú programok beavatkozása a programozó szinte biztosan követelmény. Eközben teljesítménye és végrehajtása még nem részletezett mélységben. Miután írt néhány erősen többszálú programok az évek során, én már nyilvánításáról én tulajdonságokat nonatomica teljes időt, mert atomi nem volt érzékelhető bármilyen célra. Alatt részleteinek tárgyalásába atomi és nonatomic tulajdonságai ezt a kérdést tettem néhány profilalkotás felmerült néhány érdekes eredménnyel.

Végrehajtás

Rendben. Az első dolog, amit szeretnék tisztázni, hogy a záró végrehajtási megvalósítástól függ, és eltekintettem. Louis használja @synchronized(self)az ő példája - Én már láttam ezt egy közös forrásból az összetévesztés veszélye. A végrehajtás nem a ténylegesen használni @synchronized(self); használja objektum szintű pörgés zárak . Louis illusztráció jó a magas szintű illusztráció segítségével konstrukciók mindannyian ismerik, de fontos tudni, hogy nem használ @synchronized(self).

További különbség, hogy atomi ingatlan megőrzi / kiadási ciklus a tárgyakat a getter.

Teljesítmény

Itt jön az érdekes rész: Teljesítmény atomi tulajdonság nem fér vitatott (pl egyszálú) esetben lehet igazán nagyon gyorsan bizonyos esetekben. A kevesebb, mint ideális esetben használata atomi hozzáférések többe kerül, mint 20-szor overhead nonatomic. Míg a megtámadott esetben alkalmazásával 7 szálak volt 44-szer lassabb a három bájtos struct (2,2 GHz-es Core i7 Quad Core, x86_64). A három bájtos struct egy példa egy nagyon lassú tulajdon.

Érdekes megjegyzés: A felhasználó által definiált accessors a három bájtos struct-ben 52-szer gyorsabb, mint a szintetizált atomi accessors; vagy 84% a sebesség a szintetizált nonatomic akcesszoraival.

Tárgyak megtámadott esetben is maximum 50 alkalommal.

Mivel a számos optimalizációt és variációk megvalósítások, elég nehéz mérni a valós hatások ebben a kontextusban. Lehet, hogy gyakran hallani olyasmit, hogy „Higgy, hacsak nem profil, és találja meg a probléma.” Mivel a absztrakciós szinten, ez valóban nagyon nehéz mérni a tényleges hatást. Gleaning tényleges költségeinek profilokat lehet nagyon időigényes, és mivel absztrakciók, meglehetősen pontatlanok. Csakúgy, ARC vs MRC tehet egy nagy különbség.

Úgyhogy hátrébb, nem összpontosítva végrehajtásáról ingatlan hozzáférések, és mi felvesszük a szokásos gyanúsítottakat, mint objc_msgSend, és megvizsgálja, néhány valós magas szintű eredménye számos hívásokat egy NSStringgetter vitatott esetekben (az értékek másodpercben):

• MRC | nonatomic | manuálisan végrehajtott getter: 2
• MRC | nonatomic | szintetizált getter: 7
• MRC | atomi | szintetizált getter: 47
• ARC | nonatomic | szintetizált getter: 38 (megjegyzés: az ARC hozzátéve ref száma kerékpáros itt)
• ARC | atomi | szintetizált getter: 47

Ahogy már bizonyára kitalálta, hivatkozási száma aktivitás / kerékpáros jelentős mértékben járul hozzá a atomfegyvert alatt ARC. Azt is látni nagyobb különbségek megtámadott esetben.

Bár én kiemelt figyelmet szenteljen a teljesítmény, még mindig azt szemantika első! . Eközben a teljesítmény egy alacsony prioritású számos projekt. Ugyanakkor, ismerve végrehajtás részleteit és költségeit technológiát használja biztosan nem árt. Akkor érdemes használni a megfelelő technológia az Ön igényeinek, célokra, és képességeit. Remélhetőleg ez fogja megmenteni néhány órával összehasonlítások, és segít jobban informált döntést tervezése során a programokat.

Atomic = szál biztonsági

Nem atomi = Nem szál biztonsági

Menet biztonság:

Például a változók szálbiztosságát ha helyes viselkedésre, amikor eléri a több szálat, függetlenül attól, hogy az ütemezés vagy interieavingjébői végrehajtását e szálak a futtató környezet, valamint további szinkronizációs vagy más koordinációs részéről a hívó kód.

A mi esetünkben:

Ha egy szál értékét megváltoztatja az esetben a megváltoztatott érték áll rendelkezésre, hogy minden szálat, és csak egy szál lehet változtatni az értékét egy időben.

Hol használható atomic:

Ha a példány változó lesz elérhető az többszálú környezetben.

Következménye atomic:

Nem olyan gyors, mint nonatomicazért, mert nonatomicnem igényel semmilyen watchdog munkát, hogy a futásidejű.

Hol használható nonatomic:

Ha a példány változó nem lesz módosítható több szál tudja használni. Ez javítja a teljesítményt.

Találtam egy elég jól fel magyarázata atomi és nem atomi tulajdonságokkal itt . Itt van néhány fontos szöveget ugyanaz:

„atomi” azt jelenti, hogy nem lehet lebontani. Az OS / programozás szempontjából atomi függvényhívás az egyik, hogy nem lehet megszakítani - a teljes funkció végre kell hajtani, és nem cserélték ki a CPU az operációs rendszer szokásos kontextusváltás amíg már befejeződött. Csak abban az esetben, ha nem tudja: mivel a CPU csak egy dolgot egy időben, az operációs rendszer forog hozzáférést biztosít a CPU minden futó folyamatok kevés idő-szeleteket, így a csalódás a multitasking. A CPU ütemező (és meg) megszakítja a folyamat bármely pontján annak végrehajtását - még a közepén függvényhívás. Tehát tevékenységek, mint módosítsa a megosztott számláló változót, ahol két folyamat megpróbálja frissíteni a változó ugyanabban az időben, akkor végre kell hajtani „atomi”, azaz minden frissítés akciót befejezni teljes egészében, mielőtt bármilyen más eljárás is cserélték fel a PROCESSZOR.

Tehát lennék találgatás, hogy atomi ebben az esetben azt jelenti, hogy az attribútum olvasó módszerekkel nem lehet megszakítani - gyakorlatilag azt jelenti, hogy a változó (k) által olvasott módszerrel nem tudja megváltoztatni az értéket felénél, mert egy másik szál / call / funkció kap cserélték fel a CPU-t.

Mivel a atomicváltozók nem lehet megszakítani, az érték tartalmazza az általuk bármely ponton (thread-lock) garantáltan hibátlan , bár ezt biztosító menetes zár teszi az azokhoz való hozzáférést lassabb. non-atomicváltozók, másrészt, hogy nincs ilyen garancia, de nem kínálnak a luxust, gyorsabb hozzáférést. Összefoglalva, megy non-atomic, ha tudja, hogy a változó nem érhető el több szál egyidejű és gyorsítsák fel a dolgokat.

Elolvasása után oly sok cikk, Veremtúlcsordulás üzenetét, és így demóalkalmazásokban ellenőrizni változó tulajdon attribútumok, úgy döntött, hogy az összes attribútum információkat együttesen:

1. atomic // Alapértelmezett
2. nonatomic
3. strong = retain // Alapértelmezett
4. weak = unsafe_unretained
5. retain
6. assign // Alapértelmezett
7. unsafe_unretained
8. copy
9. readonly
10. readwrite // Alapértelmezett

A cikkben változó tulajdonság attribútumai vagy módosítók iOS megtalálja az összes fent említett tulajdonságokat, és hogy biztosan segít.

1. atomic

   • atomic azt jelenti, csak egy szál hozzáférést a változó (statikus típus).
   • atomic thread biztonságos.
   • De ez lassú teljesítmény
   • atomic az alapértelmezett viselkedés
   • Atomic accessors egy nem szemetet gyűjtött környezet (vagyis ha megtartják / release / autorelease) fogja használni a zárat, hogy egy másik szál nem zavarja a helyes beállítást / kapok az értéket.
   • Ez valójában nem egy kulcsszót.
     
     

   Példa:

       @property (retain) NSString *name;
   
       @synthesize name;
   

2. nonatomic

   • nonatomic azt jelenti, több szál hozzáférést a változó (dinamikus típus).
   • nonatomic thread-nem biztonságos.
   • De ez gyors teljesítmény
   • nonatomicNEM alapértelmezett viselkedés. Meg kell adni a nonatomickulcsszót a tulajdonság tulajdonság.
   • Ez eredményeként váratlan viselkedése, amikor két különböző eljárás (szálak) eléréséhez ugyanazon változó ugyanabban az időben.
     
     

   Példa:

       @property (nonatomic, retain) NSString *name;
   
       @synthesize name;
   

Legegyszerűbb válasz az első: Nincs különbség a második két példát. Alapértelmezésben ingatlan akcesszorokkal atomi.

Atomic accessors egy nem szemetet gyűjtött környezet (vagyis ha megtartják / release / autorelease) fogja használni a zárat, hogy egy másik szál nem zavarja a helyes beállítást / kapok az értéket.

Lásd a „ Teljesítmény és Threading ” részben az Apple Objective-C 2.0 dokumentációját még több információt és egyéb szempontok létrehozásakor többszálas alkalmazások.

Atomic:

Atomic garantálja, hogy a hozzáférést a tulajdon lesz végre egy atomi módon. Pl mindig visszatér egy teljesen inicializálni tárgyak, bármilyen get / set egy ingatlan egy szálat kell töltenie, mielőtt egy másik tud hozzáférni.

Ha képzelni a következő függvény előforduló két szál egyszerre láthatja, hogy miért az eredmény nem lenne elég.

-(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;
  }

  ...
}

Előnyök: Return teljesen inicializálni tárgyak minden alkalommal teszi legjobb választás esetén a multi-threading.

Hátrányok: Performance hit teszi kivitelezés egy kicsit lassabb

Nem Atomic:

Ellentétben Atomic, mivel nem biztosítja teljes mértékben inicializálni tárgy visszatér minden egyes alkalommal.

Előnyök: Rendkívül gyors végrehajtását.

Hátrányok: esélyei szemetet érték esetén multi-threading.

Atomic azt jelenti, csak egy szál hozzáfér a változó (statikus típus). Atomic thread-safe, de ez lassú.

Nonatomic azt jelenti, több szálat eléréséhez a változó (dinamikus típus). Nonatomic thread-biztonságos, de gyors.

Atomic van thread safe , hogy lassú , és ez jól szerint biztosítja (nem garantált) , hogy csak a zárolt érték megadása nem számít, hány szálat próbál hozzáférést ugyanebben az övezetben. Ha atom, egy darab kódot írt belül ez a funkció lesz a része a kritikus szakasz, amelyre csak egy szál képes végrehajtani egy időben.

Csak biztosítja a menet biztonságát; ez nem garantálja, hogy a. Arra gondolok, hogy felveszel egy szakértő meghajtót, autó, még nem garantálja, autó nem felel meg egy baleset. Azonban a valószínűsége továbbra is a legkisebb.

Atomic - nem lehet lebontani, így az eredmény várható. A nonatomic - ha egy másik szál hozzáférést a memória terület nem lehet módosítani, így az eredmény nem volt várható.

Kód Talk:

Atomic hogy getter és setter az ingatlan menet biztonságos. például ha u írt:

self.myProperty = value;

thread biztonságos.

[myArray addObject:@"Abc"] 

nem szál biztonságos.

Nincs olyan kulcsszó „atomi”

@property(atomic, retain) UITextField *userName;

Tudjuk használni a fenti hasonlók

@property(retain) UITextField *userName;

Lásd Veremtúlcsordulás kérdést kapok kérdéseket, ha használom @property (atom-, megtartani) NSString * sajatString .

Az alapértelmezett az atomic, ez azt jelenti, hogy nem kerülni teljesítményt, amikor használni az ingatlan, de ez menet biztonságos. Mi Objective-C-nek, be van állítva a zár, így csak a tényleges szál férhet hozzá a változó, mindaddig, amíg a szetter / getter kerül végrehajtásra.

Példa MRC egy tulajdonság egy Ivar _internal:

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

Tehát az utóbbi két egyforma:

@property(atomic, retain) UITextField *userName;

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

Másrészt nem nonatomichozzá semmit a kódot. Tehát csak menet biztonságos, ha kódolni biztonsági mechanizmus magad.

@property(nonatomic, retain) UITextField *userName;

A kulcsszavak nem kell írni, mint az első ingatlan tulajdonság egyáltalán.

Ne felejtsük el, ez nem jelenti azt, hogy az ingatlan egésze szálkezelésre. Csak a módszer hívás a szetter / getter. De ha egy szetter, majd az a getter egyidejűleg 2 különböző szálak, akkor lehet törni is!

atomi (alapértelmezett)

Atomic az alapértelmezett: ha nem írjon semmit, a tulajdon atomi. Atomi tulajdonság garantálja, hogy ha megpróbálja olvasni belőle, akkor kap vissza érvényes értéket. Ez nem tesz semmilyen garanciát arról, hogy mi érték lehet, de akkor kap vissza a jó adat, nem csak junk memóriát. Mi ez lehetővé teszi, hogy nem az, ha több szálat vagy több folyamat, mutatva egy változó, egy szál lehet olvasni és a másik szál írhat. Ha megüt egy időben, az olvasó szál garantáltan kap egy a két érték: vagy a változás előtt vagy után a változást. Mi atomi nem ad bármilyen fajta garanciát arra vonatkozóan, amely ezeket az értékeket lehet kapni. Atomic valóban gyakran összekeverik, hogy szálbiztosak, és ez nem helyes. Be kell, hogy garantálja a szál biztonsági más módon. Azonban atomi garantálja, hogy ha megpróbálja olvasni, akkor kap vissza valamilyen értéket.

nonatomic

Az érem másik oldala, nem atomi, mivel valószínűleg kitalálni, csak azt jelenti, hogy „ne csináld, hogy az atomos cucc.” Mit veszít az, hogy garantálja, hogy mindig vissza valamit. Ha megpróbálja olvasni a közepén egy írási, akkor kap vissza értelmetlen adatokat. De másfelől, akkor menjen egy kicsit gyorsabb. Mivel atomi tulajdonságokkal kell csinálni néhány mágikus garantálni, hogy kapsz vissza egy értéket, akkor egy kicsit lassabb. Ha ez egy olyan tulajdonság, amit használnak egy csomó, akkor érdemes legördülő nonatomic, hogy megbizonyosodjon arról, hogy nem keletkeznek, hogy a sebesség büntetést.

Bővebben itt: https://realm.io/news/tmi-objective-c-property-attributes/

• -Atomic azt jelenti, csak egy szál hozzáférést a változó (statikus típus).
• -Atomic thread biztonságos.
• but ez lassú teljesítmény

Hogyan állapítsa meg:

Mivel atomi az alapértelmezett igen,

@property (retain) NSString *name;

És végrehajtása fájl

self.name = @"sourov";

Tegyük fel, hogy egy feladat kapcsolódó három tulajdonságok

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

Minden tulajdonság működik párhuzamosan (például aszinkron).

Ha hívja a „név” csavarmenetstoppal A ,

És

Ugyanakkor, ha a hívás

[self setName:@"Datta"]

a menet B ,

Most Ha a * neve tulajdonság nonatomic majd

• Vissza fog térni érték „Datta” egy
• Vissza fog térni érték „Datta” B

Amit miért nem atomi hívják menet biztonságos De, de ez gyors teljesítmény, mert a párhuzamos végrehajtás

Most Ha a * neve tulajdonság atomi

• Ez biztosítani fogja érték „Sourov” egy
• Akkor visszatérési értéke „Datta” B

Ezért atomi hívják menet Biztonságos és ez az, amiért ez az úgynevezett read-write biztonságos

Ilyen helyzet művelet elvégzi sorozatban. És lassú teljesítmény

- Nonatomic azt jelenti, többszörös fonalból hozzáférést a változó (dinamikus típus).

- Nonatomic thread biztonságos.

-, de ez gyors teljesítmény

-Nonatomic NEM alapértelmezett viselkedés, mi kell hozzá nonatomic kulcsszót tulajdonság tulajdonság.

In Swift megerősítve, hogy Swift tulajdonságok nonatomic a ObjC értelemben. Ennek egyik oka, így arra gondolok, hogy egy-tulajdonság atomicitás elegendő az Ön igényeinek.

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

Fro További információkért kérjük látogasson el a honlapon http://rdcworld-iphone.blogspot.in/2012/12/variable-property-attributes-or.html

Ha használja az ingatlan több szálon kódot, akkor képes lesz látni a különbséget nonatomic és az atomi attribútumokat. Nonatomic gyorsabb, mint az atomi és atom thread-safe, nem nonatomic.

Vijayendra Tripathi már adott egy példát egy többszálú környezetben.

Mielőtt elkezdené: Tudni kell, hogy minden tárgy a memóriában kell felszabadítva a memóriából egy új írási történni. Nem lehet csak úgy egyszerűen írjuk felül valami, mint te papíron. Meg kell először törölnie (dealloc), és akkor írhat rá. Ha abban a pillanatban, hogy a törlés történik (vagy félig kész), és semmi még nem írt (vagy fél írta), és megpróbál olvasni lehet nagyon problémás! Atomic és nonatomic segít kezelni ezt a problémát különböző módokon.

Először olvassa el ezt a kérdést, majd olvassa Bbum válasza . Ezen felül, akkor olvassa el a gyűjtő.

atomic mindig garantálja

• Ha két különböző ember akar írni és olvasni, ugyanakkor, a papír nem csak éget! -> Az alkalmazás soha nem összeomlik, még versenyhelyzet.
• Ha valaki megpróbál írni, és még csak azt írta 4. 8 leveleket írt, akkor nem tudja olvasni a közepén, az olvasás csak akkor lehet megvalósítani, ha mind a 8 betű van írva -> Nem olvasható (get) fog történni „a téma, hogy még mindig írásban”, vagyis ha van 8 byte byte írandó, és csak 4 bájtot - akár abban a pillanatban, akkor nem szabad olvasni belőle. De mivel én azt mondta, hogy nem fog összeomlani akkor lenne olvasni az értéke egy autoreleased objektumot.
• Ha előtt írásban meg nem törlik azt, amit korábban írt a papírra, majd valaki meg akarja olvasni tud még olvasni. Hogyan? Lesz olvasás valami hasonló a Mac OS Lomtárba (a Lomtárba nem mindig 100% törlik ... ez egy börtön) ---> Ha ThreadA van olvasni, miközben ThreadB már dealloced írni, akkor lenne tudott sem kap értéket a végső teljes egészében leírásra értéket ThreadB vagy kap valamit autorelease medence.

Őrizze az számít, hogy milyen módon memória kezelése Objective-C. Amikor létrehoz egy objektumot, hogy van egy megtartják száma 1. Ha küld egy objektum egy megtartja üzenetet, annak megtartása száma növekszik az 1. Amikor elküld egy objektum egy felszabadítási üzenetet, annak megtartása száma szerint csökkentjük 1. Ha Levél egy objektum egy autorelease üzenetet , annak megtartása száma szerint csökkentjük 1 bizonyos szakaszában a jövőben. Ha egy object's megtartják száma 0-ra csökken, akkor felszabadításra.

• Atomic nem garantálja szál biztonsági, de hasznos eléréséhez menet biztonságát. Menet biztonság képest hogyan írjuk meg kód / amely menet sorban az olvasott / írsz. Csak nem garantálja crashable többszálú.

Várj, mi?! Vannak többszálas és szál biztonsági más?

Igen. A többszálas jelenti: több szálat tud olvasni egy megosztott adat ugyanakkor, és mi nem fog összeomlani, de még nem garantálja, hogy nem olvassa el egy nem autoreleased értéket. A szálak biztonságos, akkor garantált, hogy mit olvas, nem automatikus megjelent. Ennek az az oka, hogy nem mindent atomi alapértelmezés szerint, mert van egy teljesítmény költség és a legtöbb dolog nem igazán szükség menet biztonságát. Néhány rész a kód kell, és azok számára, kevés alkatrészből kell írnunk a kódot egy szál biztonságos módon használja zárak, mutexek a szinkronizációt.

nonatomic

• Mivel nincs olyan dolog, mint a Mac OS szemétkosárba, akkor senki sem törődik-e vagy sem, hogy mindig egy értéket (<- Ez potenciálisan összeomlást okoz), és nem is érdekel senkit, ha valaki megpróbálja olvasni felénél írsz (bár félúton írásban memória nagyon eltér félig írásban papíron, a memória lehetett adni egy őrült hülye értéket előtt, míg a papíron mindig csak a fele annak, amit a már írtam) -> nem garantált, hogy nem baleset, mert nem használja fel az automata mechanizmus.
• Nem garantálja a teljes írásbeli értékeket kell olvasni!
• Gyorsabb, mint az atomi

Összességében ezek különböző szempontok 2:

• Összeomlik, vagy sem, mert a rendelkező vagy nem rendelkező autorelease medence.

• Amely lehetővé teszi, hogy olvasni kellős közepén egy „még nem fejeződött be írási vagy üres érték”, vagy nem teszi lehetővé, és csak így olvasni, amikor az érték teljesen megírva.

Mielőtt rátérnénk a attribútumait @property, tudni kell, mi a használata @property. @property nyújt arra, hogy meghatározza az információt, hogy egy osztály célja, hogy magukba. Ha nyilvánítja tárgy / változó segítségével @property, akkor az objektum / változó elérhető lesz más osztályokba importáló saját kategóriájában. Ha nyilvánítja egy tárgy segítségével @property a header fájlban, akkor meg kell szintetizálni segítségével @synthesize a végrehajtás fájlt.

Példa:

vh osztály

@interface ExampleClass : NSObject
   @property (nonatomic, retain) NSString *name;
@end

.m osztály

@implementation ExampleClass
   @synthesize name;
@end

Most a fordító szintetizálni elérési módszereket nevét.

ExampleClass *newObject=[[ExampleClass alloc]init];
NSString *name1=[newObject name]; // get 'name'
[obj setName:@“Tiger”];

Listája attribútumok @property: atomic. nonatomic. megtartják. másolat. csak olvasható. ír olvas. hozzárendelni. erős.

atomi: Ez az alapértelmezett viselkedés. Ha egy objektumot nyilvánított atomi akkor válik szálbiztosak. Szálbiztosak eszközzel, egy időben csak egy szál egy adott példányára osztálynak a felett, hogy a tárgyat.

Példa :

@property NSString *name; //by default atomic
@property (atomic)NSString *name; // explicitly declared atomic

nonatomic: Ez nem thread-safe. Használhatja a nonatomic tulajdonság tulajdonság azt adja meg hogy szintetizált accessors egyszerűen beállítani vagy vissza értéket közvetlenül, garanciák nélkül, hogy mi történik, ha ugyanez az érték érhető egyidejűleg különböző szálak. Emiatt ez gyorsabb eléréséhez nonatomic tulajdonság, mint az atomi egyet. @property (nonatomic)NSString *name;

megtartani: van szükség, ha az attribútum egy mutató egy objektumot.A szetter módszer növeli megtartja száma az objektumot, úgy, hogy elfoglalja memória autorelease medencében. @property (retain)NSString *name;

másolat: Ha másolatot, akkor nem tudja használni megtartani. Másolás például az osztály tartalmazza a saját példányát. Még ha egy változékony húr van állítva, és a későbbiekben változott, a példány ragadja bármilyen érték van abban az időben van beállítva. Nem setter és getter módszerek szintetizáljuk.

@property (copy) NSString *name;

NSMutableString *nameString = [NSMutableString stringWithString:@"Liza"];    
xyzObj.name = nameString;    
[nameString appendString:@"Pizza"];

readonly: Ha nem szeretné, hogy az ingatlan lehet változtatni szetter módszer, akkor állapítsa meg az ingatlan csak olvasható. @property (readonly) NSString *name;

Olvasási és írási: az alapértelmezett viselkedés. Nem kell megadni Csak olvasási tulajdonság kifejezetten.

@property (readwrite) NSString *name;

rendelni: generál szetter, amely kijelöli az értéket a példány változót közvetlenül, hanem a másolás vagy annak fenntartása. Ez a legjobb primitív típusok, mint NSInteger és CGFloat, vagy tárgyak nem közvetlenül a saját, mint a küldöttek.

@property (assign) NSInteger year;

erős: egy helyettesítő megtartják. @property (nonatomic, strong) AVPlayer *player;

unsafe_unretained: Van néhány osztály Kakaó és Cocoa Touch, hogy még nem támogatják a gyenge referenciák, ami azt jelenti, hogy nem nyilvánítja gyenge tulajdon vagy gyenge helyi változót nyomon követni őket. Ezek az osztályok felölelik NSTextView, NSFont és NSColorSpace stb. Ha kell használni egy gyenge utalást egy ilyen osztály, akkor kell használni egy nem biztonságos hivatkozást. Egy biztonságos hivatkozás hasonló gyenge utalás, hogy nem tartja meg a kapcsolódó tárgy él, de ez nem lehet állítani, hogy nulla, ha a cél objektum felszabadításra.

@property (unsafe_unretained) NSObject *unsafeProperty;

Az atomi tulajdonság biztosítja, hogy megtartja a teljes inicializált értéke, függetlenül attól, hogy hány szálat csinálnak getter és setter rajta.

A nonatomic tulajdonság meghatározza, hogy a szintetizált accessors egyszerűen beállítani vagy vissza értéket közvetlenül, garanciák nélkül, hogy mi történik, ha ugyanez az érték érhető egyidejűleg különböző szálak.

Atomic jelenti, hogy csak egy szál férhet hozzá a változó egy időben (statikus típus). Atomic thread-safe, de ez lassú.

Nonatomic azt jelenti, több szálat elérheti a variábilis egyszerre (dinamikus típus). Nonatomic thread-biztonságos, de gyors.

Ha az atomi, ez azt jelenti, a szál biztonságos lesz, és csak olvasható. Ha használja nonatomic, az azt jelenti, több szálon elérni a változó és menet biztonságos, de végre gyors, végzett olvasási és írási műveletek; ez egy dinamikus típusú.

Atomicity atomi (alapértelmezett)

Atomic az alapértelmezett: ha nem írjon semmit, a tulajdon atomi. Atomi tulajdonság garantálja, hogy ha megpróbálja olvasni belőle, akkor kap vissza érvényes értéket. Ez nem tesz semmilyen garanciát arról, hogy mi érték lehet, de akkor kap vissza a jó adat, nem csak junk memóriát. Mi ez lehetővé teszi, hogy nem az, ha több szálat vagy több folyamat, mutatva egy változó, egy szál lehet olvasni és a másik szál írhat. Ha megüt egy időben, az olvasó szál garantáltan kap egy a két érték: vagy a változás előtt vagy után a változást. Mi atomi nem ad bármilyen fajta garanciát arra vonatkozóan, amely ezeket az értékeket lehet kapni. Atomic valóban gyakran összekeverik, hogy szálbiztosak, és ez nem helyes. Be kell, hogy garantálja a szál biztonsági más módon. Azonban atomi garantálja, hogy ha megpróbálja olvasni, akkor kap vissza valamilyen értéket.

nonatomic

Az érem másik oldala, nem atomi, mivel valószínűleg kitalálni, csak azt jelenti, hogy „ne csináld, hogy az atomos cucc.” Mit veszít az, hogy garantálja, hogy mindig vissza valamit. Ha megpróbálja olvasni a közepén egy írási, akkor kap vissza értelmetlen adatokat. De másfelől, akkor menjen egy kicsit gyorsabb. Mivel atomi tulajdonságokkal kell csinálni néhány mágikus garantálni, hogy kapsz vissza egy értéket, akkor egy kicsit lassabb. Ha ez egy olyan tulajdonság, amit használnak egy csomó, akkor érdemes legördülő nonatomic, hogy megbizonyosodjon arról, hogy nem keletkeznek, hogy a sebesség büntetést. Hozzáférés

jóvoltából https://academy.realm.io/posts/tmi-objective-c-property-attributes/

Atomicity tulajdon attribútumok (atom- és nonatomic) nem jelennek meg a megfelelő Swift vagyonnyilatkozatokkal, de a atomicitás garantálja a Objective-C végrehajtását még mindig tart, amikor az importált ingatlan elérhetik Swift.

Így - ha meg atomi tulajdonság Objective-C marad atomi ha használt Swift.

jóvoltából https://medium.com/@YogevSitton/atomic-vs-non-atomic-properties-crash-course-d11c23f4366c

Atomic tulajdonságok : - Ha egy változó rendelt atomi tulajdonság azt jelenti, hogy csak egy szál hozzáférést, és ez lesz menet biztonságos és jó lesz a teljesítmény szempontjából lesz alapértelmezett.

Nem Atomic Tulajdonságok : - Ha egy változó rendelt atomi tulajdonság azt jelenti, hogy van több szál hozzáférést és nem lesz szál biztonságos és lassú lesz a teljesítmény szempontjából lesz alapértelmezett viselkedés, és amikor két különböző szálak az elérni kívánt változót egyszerre akkor nem a várt eredményeket.

Az igazság az, hogy az általuk használt spin-lock végrehajtásához atomi tulajdonság. A kód az alábbiak szerint:

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

Egyszerűsítése érdekében a teljes zűrzavar értsük mutexek lock.Mutex zár, mint egy a neve zárolja a változékonysága object.So ha a tárgy elérhető egy osztály nincs más osztály érheti el ugyanazt object.In iOS @sychronise is biztosítja a mutex lock.Now azt szolgálja FIFO üzemmódban, és biztosítja az áramlás nem befolyásolja a két osztály ugyanazokat az instance.However ha a feladat a fő szál elkerül elérésével objektumot atomi tulajdonságokkal tarthat meg a kezelőfelület és lerontják

Atomic: Biztosítani szál-biztonsági zárolja a szálat NSLOCK.

Nem atomi: nem biztosítja szál-biztonság, mivel nincs menet-zárszerkezet.