Hva er forskjellen mellom atom og nonatomic attributter?

Dette er forklart i Apples dokumentasjon , men nedenfor er noen eksempler på hva som faktisk skjer. Merk at det ikke er "atomic" søkeord, hvis du ikke angir "nonatomic" da eiendommen er atom, men spesifiserer "atom" eksplisitt vil resultere i en feil.

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

- (UITextField *) userName {
    return userName;
}

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

Nå er atom varianten litt mer komplisert:

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

I utgangspunktet har atom versjon for å ta en lås for å garantere tråd sikkerhet, og også er bumping dommeren teller på objektet (og autoutgivelses teller for å balansere den) slik at objektet er garantert å eksistere for den som ringer, ellers er det er en potensiell rase tilstand hvis en annen tråd er å sette verdien, slik at ref tellingen for å falle til 0.

Det er faktisk et stort antall ulike varianter av hvordan disse tingene fungerer, avhengig av om egenskapene er skalare verdier eller objekter, og hvordan beholde, kopiere, skrivebeskyttet, nonatomic, etc samhandle. Generelt eiendommen synthesizere bare vet hvordan de skal gjøre det "rette" for alle kombinasjoner.

Atomisk

• er standard oppførsel
• vil sørge for den foreliggende prosessen blir fullført med CPU-enheten, før en annen prosess aksesserer den variable
• er ikke fast, da det sikrer at prosessen er fullført i sin helhet

Ikke-Atomic

• er IKKE standard oppførsel
• raskere (for syntetiserte kode, det vil si for variabler som er opprettet ved hjelp av @property og @synthesize)
• ikke trådsikre
• kan føre til uventet oppførsel, når to forskjellige prosess tilgang til den samme variable samtidig

Den beste måten å forstå forskjellen bruker følgende eksempel.

Anta at det er et atom streng egenskap kalt "navn", og hvis man kaller [self setName:@"A"]fra tråden A, ring [self setName:@"B"]fra tråden B, og ring [self name]fra tråden C, deretter ble alle operasjoner på forskjellige tråder blir utført i serie som betyr at hvis en tråd utfører en setter eller getter, og andre tråder vil vente.

Dette gjør eiendommen "navn" lese / skrive trygge, men hvis en annen tråd, D, kaller [name release]samtidig så denne operasjonen kan produsere en krasj fordi det er ingen setter / getter samtale involvert her. Hvilket betyr at et objekt er lese / skrive safe (ATOMIC), men ikke trådsikre som en annen tråder kan samtidig sende alle typer meldinger til objektet. Utbygger bør sikre tråd-sikkerhet for slike objekter.

Hvis egenskapen "navn" ble nonatomic, da alle tråder i eksempelet ovenfor - A, B, C og D vil utføre samtidig produsere noe uforutsigbar resultat. I tilfelle av atom, enten en av A, B eller C skal utføres først, men D kan likevel utføre i parallell.

Syntaks og semantikk er allerede godt definert av andre gode svar på dette spørsmålet. Fordi gjennomføring og resultater ikke er detaljert bra, vil jeg legge mitt svar.

Hva er den funksjonelle forskjellen mellom disse tre?

Jeg hadde alltid betraktet atom som standard ganske nysgjerrig. På abstraksjonsnivået vi arbeide på, ved hjelp av atom egenskaper for en klasse som et redskap for å oppnå 100% trådsikkerhet er et hjørne tilfelle. For virkelig riktige flertråders programmer, er intervensjon av programmerer nesten helt sikkert et krav. I mellomtiden, ytelse egenskaper og gjennomføring ennå ikke er beskrevet i dybden. Etter å ha skrevet noen tungt flertråders programmer gjennom årene, hadde jeg blitt erklære mine egenskaper som nonatomichele tiden fordi atom ikke var fornuftig uansett formål. Under diskusjonen av detaljene i atom og nonatomic egenskaper dette spørsmålet , jeg gjorde noen profilering oppstått noen nysgjerrige resultater.

Henrettelse

Ok. Det første jeg ønsker å rydde opp er at låse implementeringen er implementeringen definert og abstrahert. Louis bruker @synchronized(self)i sitt eksempel - Jeg har sett dette som en vanlig kilde til forvirring. Implementeringen ikke faktisk bruker @synchronized(self); den bruker objektnivåspinn låser . Louis illustrasjon er bra for et høyt nivå illustrasjon hjelp konstruerer vi alle er kjent med, men det er viktig å vite at det ikke bruker @synchronized(self).

En annen forskjell er at atom egenskaper vil beholde / utgivelsessyklus objektene innen getter.

Opptreden

Her er den interessante delen: Ytelse bruke atom eiendom åpner i ubestridt (f.eks single-threaded) tilfeller kan være veldig veldig fort i noen tilfeller. I mindre enn ideelle tilfeller, kan bruken av atom-aksesser koste mer enn 20 ganger toppstrømmen fra nonatomic. Mens omstridt tilfellet ved bruk av 7 tråder var 44 ganger langsommere for de tre-byte struct (2,2 GHz Core i7 fire kjerner, x86_64). De tre-byte struct er et eksempel på en svært langsom eiendom.

Digresjon: Brukerdefinerte accessors av tre-byte struct var 52 ganger raskere enn de syntetiserte atom accessors; eller 84% av hastigheten av syntetiserte nonatomic accessors.

Objekter i omstridt tilfeller kan også overstige 50 ganger.

På grunn av antall optimaliseringer og variasjoner i implementeringer, er det ganske vanskelig å måle reelle konsekvenser i disse sammenhenger. Du kan ofte høre noe sånt som "Stol på det, med mindre du profil og synes det er et problem". På grunn av abstraksjonsnivået, det er faktisk ganske vanskelig å måle faktiske effekten. Sanking faktiske kostnadene fra profiler kan være svært tidkrevende, og på grunn av abstraksjoner, ganske unøyaktig. I tillegg kan ARC vs MRC gjøre en stor forskjell.

Så la oss ta et skritt tilbake, ikke fokus på gjennomføringen av eiendom aksesser, vil vi inkludere de vanlige mistenkte som objc_msgSend, og undersøke noen virkelige verden høyt nivå resultater for mange samtaler til en NSStringgetter i ubestridt tilfeller (verdier i sekunder):

• MRC | nonatomic | manuelt iverk getters: 2
• MRC | nonatomic | syntetiseres getter: 7
• MRC | atomic | syntetiseres getter: 47
• ARC | nonatomic | syntetisert getter: 38 (Merk: ARC er å legge til dommeren teller sykling her)
• ARC | atomic | syntetiseres getter: 47

Som du sikkert har gjettet, er referanseantall aktivitet / sykling en betydelig bidragsyter med atomics og under ARC. Du vil også få se større forskjeller i omstridt tilfeller.

Selv om jeg følger nøye med på resultatene, jeg likevel si Semantics først! . I mellomtiden, er ytelsen en lav prioritet for mange prosjekter. Men vel vitende om gjennomføring detaljer og kostnader av teknologier du bruker sikkert ikke vondt. Du bør bruke riktig teknologi for dine behov, formål og evner. Forhåpentligvis vil dette spare deg noen timer med sammenligninger, og hjelpe deg å gjøre en bedre informert beslutning når du utformer programmer.

Atomic = tråd sikkerhet

Ikke-atom = Nei tråd sikkerhet

Tråd sikkerhet:

Instansvariabler er thread-safe hvis de oppfører seg riktig når den åpnes fra flere tråder, uavhengig av planlegging eller innfelling av utførelsen av disse trådene ved runtime miljø, og uten ekstra synkronisering eller annet samordning på den delen av ringer koden.

I vår sammenheng:

Hvis en tråd endrer verdien av forekomsten den endrede verdi være tilgjengelig for alle trådene, og bare en tråd kan endre verdien av gangen.

Hvor å bruke atomic:

Dersom forekomsten variabelen skal nås i en flertrådet miljø.

Implikasjon av atomic:

Ikke så fort som nonatomicpå grunn nonatomickrever ingen vaktbikkje arbeid på det fra runtime.

Hvor å bruke nonatomic:

Hvis instansvariabelen er ikke skal endres av flere tråder kan du bruke den. Det forbedrer ytelsen.

Jeg fant en ganske godt satt forklaring av atom og ikke-atom egenskaper her . Her er noen relevant tekst fra den samme:

'atom' betyr at det ikke kan brytes ned. I OS / programmering vilkår en atom funksjon samtale er en som ikke kan avbrytes - hele funksjonen må utføres, og ikke byttet ut av CPU av OS sin vanlige kontekst bytter før det er fullført. Bare i tilfelle du ikke visste: siden CPU kan bare gjøre en ting om gangen, roterer OS tilgang til CPU til alle prosesser som kjører i små tids skiver, for å gi illusjon av multitasking. CPU planleggeren kan (og gjør) avbryte en prosess på noe punkt i sin utførelse - selv i midten av funksjonskall. Så for handlinger som oppdaterer delte disk variabler der to prosesser kan forsøke å oppdatere den variable samtidig, må de bli henrettet 'atomically', det vil si, har hver oppdatering handling til slutt i sin helhet før noen annen prosess kan byttes på PROSESSOR.

Jeg vil derfor være gjette at atom i dette tilfellet betyr at attributten leseren metoder kan ikke bli avbrutt - i praksis betyr at den variable (r) blir lest av fremgangsmåten kan ikke endre sin verdi halvveis gjennom fordi noen andre tråden / call / funksjon får byttet på CPU.

Fordi atomicvariablene ikke kan avbrytes, den verdi som inneholdes ved dem på ethvert punkt er (tråd-lock) garantert å være uskadet , selv om, som sikrer denne tråd lås gjør tilgang til dem langsommere. non-atomicvariabler, på den annen side, gjør ingen slik garanti, men tilbyr luksusen av raskere tilgang. For å oppsummere det, gå med non-atomicnår du kjenner dine variabler vil ikke nås av flere tråder samtidig og fart ting opp.

Etter å ha lest så mange artikler, Stack Overflow innlegg og lage demo programmer for å sjekke variable eiendoms attributter, bestemte jeg meg for å sette alle attributtene informasjonen sammen:

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

I artikkelen Variable eiendoms attributter eller modifikatorer i iOS kan du finne alle de ovennevnte egenskaper, og som vil definitivt hjelpe deg.

1. atomic

   • atomic betyr bare en tråd adgang den variable (statisk type).
   • atomic er tråden sikker.
   • Men det er treg i ytelse
   • atomic er standard oppførsel
   • Atom accessors i et ikke søppel oppsamlet miljø (dvs. ved bruk av beholder / release / autoutgivelses) vil benytte en lås for å sikre at en annen tråd ikke kommer i konflikt med korrekt innstilling / får av verdien.
   • Det er faktisk ikke et nøkkelord.
     
     

   Eksempel:

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

2. nonatomic

   • nonatomic betyr multiple tråd adgang den variable (dynamisk type).
   • nonatomic er tråd-usikre.
   • Men den er rask i ytelse
   • nonatomicer ikke standard oppførsel. Vi må legge til nonatomicsøkeordet i eiendommen attributtet.
   • Det kan føre til uventet oppførsel, når to forskjellige prosess (tråder) tilgang til den samme variable samtidig.
     
     

   Eksempel:

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

Enkleste svaret først: Det er ingen forskjell mellom andre to eksempler. Som standard, eiendom accessors er atom.

Atom accessors i et ikke søppel oppsamlet miljø (dvs. ved bruk av beholder / release / autoutgivelses) vil benytte en lås for å sikre at en annen tråd ikke kommer i konflikt med korrekt innstilling / får av verdien.

Se " Ytelse og Threading " i Apples Objective-C 2,0 dokumentasjon for litt mer informasjon og for andre hensyn når du oppretter flertrådede programmer.

Atomic:

Atomic garanterer at tilgang til eiendommen vil bli utført i en atom måte. Eg er alltid returnere et fullt initialisert objekter, noen få / sett en eiendom på en tråd må fullføre før en annen kan få tilgang til det.

Hvis du forestille deg følgende funksjon skjer på to tråder samtidig kan du se hvorfor resultatene ikke ville være pen.

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

  ...
}

Pros: Return of fullt initialisert gjenstander hver gang gjør det beste valget i tilfelle av multi-threading.

Cons: Ytelse hit, gjør henrettelsen litt tregere

Non-Atomic:

I motsetning til Atomic, betyr det ikke sikre fullstendig initialisert objekt tilbake hver gang.

Pros: Ekstremt rask gjennomføring.

Cons: Sjansene for søppel verdi i tilfelle av multi-threading.

Atomic betyr bare en tråd aksesserer den variable (statisk type). Atomic er tråd-safe, men den er treg.

Nonatomic betyr flere tråder åpner den variable (dynamisk type). Nonatomic er tråd-usikre, men det er fort.

Atomic er tråden trygg , den er langsom og det brønn forsikrer (ikke garantert) at bare den låste verdi er gitt, uansett hvor mange tråder prøver adgang over samme sone. Ved bruk atom, en del av koden er skrevet i denne funksjonen blir den del av den kritiske seksjon, til hvilken kun en tråd kan utføre på en gang.

Det sikrer bare tråden sikkerhet; det garanterer ikke det. Det jeg mener er at du leie en ekspert driver for deg bil, likevel er det ikke garantier bilen vil ikke møte en ulykke. Imidlertid gjenstår sannsynlighet det minste.

Atomic - det kan ikke bli brutt ned, slik at resultatet er forventet. Med nonatomic - når en annen tråd adgang hukommelsessonen den kan modifisere den, slik at resultatet er uventet.

Kode Diskusjon:

Atomic gjøre getter og setter av eiendommen tråden trygg. for eksempel hvis u har skrevet:

self.myProperty = value;

er tråden sikker.

[myArray addObject:@"Abc"] 

IKKE tråden trygg.

Det finnes ingen slik ordet "atomic"

@property(atomic, retain) UITextField *userName;

Vi kan bruke de ovennevnte som

@property(retain) UITextField *userName;

Se Stack Overflow spørsmålet jeg får problemer hvis jeg bruker @property (atom, beholde) NSString * myString .

The Standard er atomic, dette betyr at det koster deg ytelse når du bruker eiendommen, men det er tråden trygt. Hva Objective-C har, er satt en lås, slik at bare selve tråden kan få tilgang til den variable, så lenge innstilleren / getter blir utført.

Eksempel med MRC av en eiendom med en ivar _internal:

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

Så disse to siste er den samme:

@property(atomic, retain) UITextField *userName;

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

På den annen side gjør nonatomiclegge noe i koden. Så det er bare tråden trygg hvis du koden sikkerhetsmekanisme selv.

@property(nonatomic, retain) UITextField *userName;

Søkeordene trenger ikke å være skrevet som første eiendom attributt i det hele tatt.

Ikke glem, betyr ikke dette at eiendommen som helhet er tråd-safe. Bare metodekallet av innstilleren / getter er. Men hvis du bruker en setter, og etter at en getter samtidig med 2 forskjellige tråder, kan det bli brutt også!

atom (standard)

Atomic er standard: Hvis du ikke skriver noe, er din eiendom atom. En atom eiendom er garantert at hvis du prøver å lese fra den, vil du få tilbake en gyldig verdi. Det gjør ikke noen garantier om hva denne verdien kan være, men du vil få tilbake gode data, ikke bare junk minne. Hva dette gjør at du kan gjøre er hvis du har flere tråder eller flere prosesser som peker på en enkelt variabel, kan en tråd lese og en annen tråd kan skrive. Hvis de treffer på samme tid, er leseren tråden garantert å få en av de to verdier: enten før eller etter endringen. Hva atom gir deg ikke er noen form for garanti om hvilke av disse verdiene kan du få. Atomic er virkelig ofte forveksles med å være tråd-safe, og det er ikke riktig. Du må garantere din tråd sikkerhets andre måter. Men atom vil garantere at hvis du prøver å lese, får du tilbake noen form for verdi.

nonatomic

På baksiden, ikke-atom, som du kan sikkert gjette, betyr bare, “ikke gjør som atom ting.” Det du mister er at garanti for at du alltid får tilbake noe. Hvis du prøver å lese i midten av en skrive, kan du komme tilbake søppel data. Men, på den annen side, du går litt raskere. Fordi atom egenskaper må gjøre noen magi for å garantere at du vil få tilbake en verdi, de er litt tregere. Hvis det er en egenskap som du har tilgang mye, kan det være lurt å droppe ned til nonatomic å sørge for at du ikke pådra seg at hastigheten straff.

Se mer her: https://realm.io/news/tmi-objective-c-property-attributes/

• -Atomic betyr bare en tråd adgang den variable (statisk type).
• -Atomic er tråden trygg.
• -men det er treg i ytelse

Hvordan å erklære:

Som atom er standard, slik,

@property (retain) NSString *name;

Og i gjennomføringen fil

self.name = @"sourov";

Anta at en oppgave i forbindelse med tre egenskaper

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

Alle eiendommer jobbe parallelt (som asynkront).

Hvis du kaller "navn" fra tråd A ,

Og

Samtidig hvis du ringer

[self setName:@"Datta"]

fra tråden B ,

Nå Hvis * navn Eiendommen er nonatomic da

• Det vil returnere verdien "Datta" for A
• Det vil returnere verdien "Datta" for B

Det er derfor ikke atom kalles tråd usikre, men men den er rask i ytelse på grunn av parallell kjøring

Nå Hvis * navn eiendommen er atom

• Det vil sikre verdi "Sourov" for A
• Så det vil returnere verdien "Datta" for B

Det er derfor atom kalles tråd Sikker og det er derfor det kalles skrive skrive trygg

En slik situasjon operasjonen vil utføre serielt. Og Slow i ytelse

- Nonatomic betyr multiple tråd adgang den variable (dynamisk type).

- Nonatomic er tråden usikre.

- men den er rask i ytelse

-Nonatomic er ikke standard atferd, vi må legge nonatomic søkeord i eiendom attributt.

For I Swift Bekrefter at Swift egenskaper er nonatomic i ObjC forstand. En grunn er slik at du tenke på om per eiendom atomicity er tilstrekkelig for dine behov.

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

Fro mer info kan du besøke nettstedet http://rdcworld-iphone.blogspot.in/2012/12/variable-property-attributes-or.html

Hvis du bruker din eiendom i multi-threaded kode så du ville være i stand til å se forskjellen mellom nonatomic og atom attributter. Nonatomic er raskere enn atom og atom er tråd-trygg, ikke nonatomic.

Vijayendra Tripathi har allerede gitt et eksempel for en multi-gjenge miljø.

Før du begynner: Du må vite at hvert objekt i minnet må deallocated fra minnet for en ny skrive å skje. Du kan ikke bare bare å skrive på toppen av noe som du gjør på papir. Du må først slette (dealloc) det og deretter kan du skrive på den. Hvis i øyeblikket at slette er gjort (eller halv gjort), og ingenting har ennå blitt skrevet (eller halv skrev) og du prøver å lese det kan være svært problematisk! Atomic og nonatomic hjelp du behandler dette problemet på forskjellige måter.

Først lese dette spørsmålet, og deretter lese Bbum svar . I tillegg så les min oppsummering.

atomic vil alltid garantere

• Hvis to forskjellige folk ønsker å lese og skrive på samme tid, vil papiret ikke bare brenne! -> Din søknad vil aldri krasje, selv i et løp tilstand.
• Hvis en person prøver å skrive, og har bare skrev 4 av de 8 brev til skriftlig, så ingen kan lese i midten, kan lesingen bare gjøres når alle 8 bokstaver er skrevet -> Nei lese (få) vil skje på 'en tråd som fortsatt skrive', dvs. hvis det er 8 byte til byte som skal skrives, og bare fire bytes er skrevet - opp til det øyeblikket, har du ikke lov til å lese fra den. Men siden jeg sa at det ikke vil krasje så det ville lese fra verdien av en autoreleased objekt.
• Hvis før du skriver du har slettet det som tidligere ble skrevet på papir og deretter noen ønsker å lese deg kan fortsatt lese. Hvordan? Du skal lese fra noe som ligner på Mac OS Trash bin (som papirkurven bin er ikke fortsatt 100% slettet ... det er i en limbo) ---> Hvis ThreadA er å lese mens ThreadB har allerede dealloced å skrive, ville du kunne enten få verdi fra den endelige fullt skrevet verdi av ThreadB eller få noe fra autoutgivelsesutvalg.

Beholde teller er måten minnet forvaltes i Objective-C. Når du oppretter et objekt, har det en beholder telling av 1. Når du sender et objekt en beholder melding, dens beholde teller økes med 1. Når du sender et objekt en utgivelse melding, er dens beholde telling reduseres med 1. Når du sende et objekt en autoutgivelses melding , er dens beholder verdiene redusert med en på et eller annet tidspunkt i fremtiden. Hvis en object's holde tellingen blir redusert til 0, blir det deallokert.

• Atomic ikke garantere tråd sikkerhet, men det er nyttig for å oppnå tråd sikkerhet. Tråd Sikkerhet er i forhold til hvordan du skriver en kode / hvilke gjenger køen du leser / skriver fra. Det garanterer eneste ikke-crashable multithreading.

Vent hva ?! Er multithreading og tråd sikkerhet annerledes?

Ja. Multithreading betyr: flere tråder kan lese en delt stykke data på samme tid, og vi vil ikke krasje, men det garanterer ikke at du ikke leser fra en ikke-autoreleased verdi. Med tråd sikkerhet, er det garantert at det du leser er ikke automatisk gitt ut. Grunnen til at vi ikke gjør alt atom som standard er, fordi det er en forestilling kostnader og for de fleste ting ikke egentlig trenger tråd sikkerhet. Noen deler av koden vår trenger det, og for de få delene vi trenger å skrive vår kode i en tråd sikker måte ved hjelp av låser, mutex eller synkronisering.

nonatomic

• Siden det ikke finnes noe slikt som Mac OS papirkurven, så ingen bryr seg om du alltid få en verdi (<- Dette kan potensielt føre til krasj), og heller ikke noen bryr seg hvis noen prøver å lese halvveis gjennom deg skriftlig (selv om halvveis skriver i minnet er svært forskjellig fra halvveis å skrive på papir, på minne den kan gi deg en gal dum verdi fra før, mens på papir du bare halvparten av hva som er blitt skrevet) -> garanterer ikke for å ikke krasje, fordi den ikke bruker autoutgivelsesmekanismen.
• Garanterer ikke fullstendig skrevet verdier som skal lese!
• Er raskere enn atom

Samlet de er forskjellige i 2 aspekter:

• Krasje eller ikke på grunn av å ha eller ikke ha autoutgivelsesutvalg.

• Slik at for å bli lest rett i midten av en ennå ikke ferdig skrive eller tom verdi "eller ikke tillate og bare tillater å lese når verdien er fullt skrevet.

Før diskutere om egenskapene til @property, bør du vite hva som er bruk av @property. @property tilbyr en måte å definere den informasjonen som en klasse er ment å kapsle. Hvis du definerer et objekt / variabel ved hjelp @property, så dette objektet / variable vil være tilgjengelig for andre klasser importerer sin klasse. Hvis du definerer et objekt ved hjelp @property i header-fil, så må du syntetisere den ved hjelp @synthesize i gjennomføringen filen.

Eksempel:

.h klasse

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

.m klasse

@implementation ExampleClass
   @synthesize name;
@end

Nå kompilatoren vil syntetisere tilbehør metoder for navn.

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

Liste over attributtene @property: atom. nonatomic. beholde. kopiere. skrivebeskyttet. Les Skriv. tildele. sterk.

atomic: Det er standard virkemåte. Dersom et objekt er deklarert som atomisk deretter blir det trådsikre. Tråd sikker måte, på et tidspunkt bare en tråd av en bestemt forekomst av klassen kan ha kontroll over det objekt.

eksempel:

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

nonatomic: Det er ikke thread-safe. Du kan bruke nonatomic eiendom attributtet for å angi at syntetiserte accessors bare satt eller returnere en verdi direkte, uten garantier for hva som skjer hvis den samme verdien er tilgjengelig samtidig fra forskjellige tråder. Av denne grunn er det raskere å få tilgang til en nonatomic eiendom enn et atom en. @property (nonatomic)NSString *name;

beholde: er nødvendig når attributtet er en peker til en object.The setter metode vil øke beholde telling av objektet, slik at det vil oppta minne i autoutgivelses bassenget. @property (retain)NSString *name;

kopi: Hvis du bruker kopiere, kan du ikke bruke beholde. Bruke kopi forekomst av klassen vil inneholde sin egen kopi. Selv om en foranderlig strengen er satt, og deretter endret, forekomsten fanger uansett verdi den har på det tidspunktet den er satt. Det er ingen Setter og getter metoder vil bli syntetisert.

@property (copy) NSString *name;

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

skrivebeskyttet: Hvis du ikke ønsker å tillate eiendommen skal endres via setter metoden, kan du erklære eiendommen skrivebeskyttet. @property (readonly) NSString *name;

Readwrite: er standard oppførsel. Du trenger ikke å spesifisere Readwrite attributt eksplisitt.

@property (readwrite) NSString *name;

tilordner: vil generere en sprøytestøper som tildeler verdien til forekomsten variable direkte, i stedet for å kopiere eller beholde den. Dette er best for primitive typer som NSInteger og CGFloat eller gjenstander du ikke direkte eier som delegater.

@property (assign) NSInteger year;

sterk: er en erstatning for beholder. @property (nonatomic, strong) AVPlayer *player;

unsafe_unretained: Det er noen klasser i Cocoa og Cocoa Touch som ikke støtter svake referanser, som betyr at du ikke kan erklære en svak eiendom eller svak lokal variabel for å holde styr på dem. Disse klassene omfatter NSTextView, NSFont og NSColorSpace, osv. Hvis du trenger å bruke en svak referanse til en av disse klassene, må du bruke en usikker referanse. En usikker referansen er lik en svak referanse i at det ikke holder tilhørende objekt i live, men det vil ikke bli satt til null hvis målet objektet er deallocated.

@property (unsafe_unretained) NSObject *unsafeProperty;

Atom egenskap sørger for å beholde en fullstendig initialisert verdi uavhengig av hvor mange tråder gjør getter og setter på den.

Den nonatomic egenskapen angir at syntetisert accessors bare sette eller returnere en verdi direkte, uten garantier for hva som skjer hvis den samme verdien er tilgjengelig samtidig fra forskjellige tråder.

Atomic betyr bare en tråd kan få tilgang til variabel på et tidspunkt (statisk type). Atomic er tråd-safe, men den er treg.

Nonatomic betyr at flere tråder kan få tilgang til den variable ved samme tidspunkt (dynamisk type). Nonatomic er tråd-usikre, men det er fort.

Hvis du bruker atomic, betyr det at tråden vil være trygt og skrivebeskyttet. Hvis du bruker nonatomic, betyr det at flere tråder tilgang til variable og er tråd usikre, men det er utført raskt, gjort en lese- og skriveoperasjoner; Dette er en dynamisk type.

Atomicity atom (standard)

Atomic er standard: Hvis du ikke skriver noe, er din eiendom atom. En atom eiendom er garantert at hvis du prøver å lese fra den, vil du få tilbake en gyldig verdi. Det gjør ikke noen garantier om hva denne verdien kan være, men du vil få tilbake gode data, ikke bare junk minne. Hva dette gjør at du kan gjøre er hvis du har flere tråder eller flere prosesser som peker på en enkelt variabel, kan en tråd lese og en annen tråd kan skrive. Hvis de treffer på samme tid, er leseren tråden garantert å få en av de to verdier: enten før eller etter endringen. Hva atom gir deg ikke er noen form for garanti om hvilke av disse verdiene kan du få. Atomic er virkelig ofte forveksles med å være tråd-safe, og det er ikke riktig. Du må garantere din tråd sikkerhets andre måter. Men atom vil garantere at hvis du prøver å lese, får du tilbake noen form for verdi.

nonatomic

På baksiden, ikke-atom, som du kan sikkert gjette, betyr bare, “ikke gjør som atom ting.” Det du mister er at garanti for at du alltid får tilbake noe. Hvis du prøver å lese i midten av en skrive, kan du komme tilbake søppel data. Men, på den annen side, du går litt raskere. Fordi atom egenskaper må gjøre noen magi for å garantere at du vil få tilbake en verdi, de er litt tregere. Hvis det er en egenskap som du har tilgang mye, kan det være lurt å droppe ned til nonatomic å sørge for at du ikke pådra seg at hastigheten straff. Adgang

høflighet https://academy.realm.io/posts/tmi-objective-c-property-attributes/

Atomicity egenskapattributter (atom og nonatomic) ikke er reflektert i den tilsvarende Swift egenskapen erklæring, men de atomiske garantier for Objective-C implementering den fortsatt holder når den importerte egenskapen er tilgjengelig fra Swift.

Så - hvis du definerer en atom eiendom i Objective-C vil det forbli atom når det brukes av Swift.

høflighet https://medium.com/@YogevSitton/atomic-vs-non-atomic-properties-crash-course-d11c23f4366c

Atomic egenskaper : - Når en variabel tilordnet med atom eiendom som betyr at den har bare en tråd tilgang, og det vil være tråden trygt og vil være bra i ytelse perspektiv, vil ha standard oppførsel.

Ikke Atomic Egenskaper : - Når en variabel tilordnet med atom eiendom som betyr at den har multi tråd tilgang, og det vil ikke bli tråden trygt og vil være treg i ytelse perspektiv, vil ha standard oppførsel, og når to forskjellige tråder vil ha tilgang til variabel på samme tid det vil gi uventede resultater.

Sannheten er at de bruker spin lås for å gjennomføre atom eiendom. Koden som følger:

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

For å forenkle hele forvirringen la oss forstå mutex lock.Mutex låsen som per navnet låser mutability av object.So hvis objektet er tilgjengelig for en klasse ingen andre klasse har tilgang til samme object.In iOS @sychronise også gi mutex lock.Now det tjene i FIFO-mode og sikrer at strømningen ikke er påvirket av to klasser som deler den samme instance.However hvis oppgave er på hovedtråden unngå å få tilgang til objektet ved hjelp av atom-egenskaper som det kan holde UI og redusere ytelsen

Atomic: Sikre trådsikkerhet ved å låse tråden med NSLOCK.

Ikke-atom: sikrer ikke trådsikkerhet da det ikke er noen gjenge-låsemekanisme.