Wat doen atomicen nonatomicbetekenen in verklaringen woning?
@property(nonatomic, retain) UITextField *userName;
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName;
Wat is het operationele verschil tussen deze drie?
De laatste twee zijn identiek; "atomic" is het standaard gedrag ( er rekening mee dat het niet echt een trefwoord, het is alleen gespecificeerd door de afwezigheid van - nonatomicatomicwerd als zoekwoord toegevoegd in recente versies van llvm / clang).
Ervan uitgaande dat u @synthesizing de methode implementaties, atomaire versus niet-atomaire verandert de gegenereerde code. Als u het schrijven van uw eigen setter / getters, atomaire / nonatomic / behouden / toewijzen / copy zijn louter adviserende. (Let op: @ synthetiseren is nu de standaard gedrag in recente versies van LLVM Er is ook geen noodzaak om bijvoorbeeld variabelen te verklaren, ze zullen automatisch worden gesynthetiseerd, ook, en een zal hebben. _Toegevoegd aan hun naam aan toevallige directe toegang te voorkomen).
Met "atomic", zal het gesynthetiseerde setter / getter ervoor dat een gehele waarde altijd terug uit de getter of ingesteld door de aanbrenginrichting, ongeacht zetter activiteit op andere thread. Dat wil zeggen, als draad A is in het midden van de getter, terwijl draad B de setter, een feitelijke haalbare waarde noemt - een autoreleased object, waarschijnlijk - zal worden teruggegeven aan de beller in A.
In nonatomiczijn er geen dergelijke garanties gemaakt. Aldus nonatomicis aanzienlijk sneller dan "atomic".
Wat "atomic" doet niet doen, is geen garanties over de draad veiligheid. Als een draad van de getter gelijktijdig bellen met schroefdraad B en C roept de aanbrenginrichting met verschillende waarden kan draad A krijgt een van de drie waarden terug - degene vóór elke setters gebeld of één van de waarden overgegaan in setters in B en C. op dezelfde wijze kan het voorwerp eindigen met de waarde van B en C, geen manier om te vertellen.
Betrouwbaarheid van de gegevens - een van de belangrijkste uitdagingen van multi-threaded programmeren - wordt bereikt met andere middelen.
Het toevoegen van deze:
atomicity van een enkele woning kan ook geen garantie voor veiligheid draad wanneer meerdere afhankelijke eigenschappen in het spel zijn.
Overwegen:
@property(atomic, copy) NSString *firstName;
@property(atomic, copy) NSString *lastName;
@property(readonly, atomic, copy) NSString *fullName;
In dit geval kan een draad worden hernoemen het object door het aanroepen setFirstName:en vervolgens bellen setLastName:. In de tussentijd kan draad B bellen fullNametussen thread A's twee gesprekken en zal de nieuwe naam in combinatie met de oude achternaam ontvangen.
Om dit aan te pakken, moet u een transactionele model . Ie een andere vorm van synchronisatie en / of uitsluiting die toelaat om toegang uit te sluiten fullName, terwijl de afhankelijke eigenschappen worden bijgewerkt.
Dit wordt uitgelegd in Apple's documentatie , maar hieronder zijn enkele voorbeelden van wat er daadwerkelijk gebeurt. Merk op dat er geen "atomic" keyword, als je het niet "nonatomic" geef dan het pand is atoom, maar het opgeven van "atomaire" expliciet zal resulteren in een fout.
//@property(nonatomic, retain) UITextField *userName;
//Generates roughly
- (UITextField *) userName {
return userName;
}
- (void) setUserName:(UITextField *)userName_ {
[userName_ retain];
[userName release];
userName = userName_;
}
Nu, de atomaire variant is een beetje ingewikkelder:
//@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_;
}
}
Kortom, de atomaire versie heeft om een slot te nemen om de veiligheid te draad te waarborgen, en ook stoten de ref telling op het object (en de autorelease tellen om het evenwicht te brengen), zodat het object wordt gegarandeerd te bestaan voor de beller, omdat er anders is een potentiële conflictsituatie als een andere thread wordt de waarde, waardoor de ref telling dalen tot 0.
Er zijn eigenlijk een groot aantal verschillende varianten van hoe deze dingen werken, afhankelijk van de vraag of de eigenschappen zijn scalaire waarden of voorwerpen, en hoe te behouden, kopiëren, alleen-lezen, nonatomic, etc met elkaar omgaan. In het algemeen is het pand synthesizers weet precies hoe de "juiste ding" te doen voor alle combinaties.
De beste manier om het verschil te begrijpen is met behulp van het volgende voorbeeld.
Stel dat er een atoom tekenreekseigenschap genaamd "naam", en als je belt [self setName:@"A"]van draad A, bellen [self setName:@"B"]van draad B en bellen [self name]van de draad C, worden alle bewerkingen op verschillende schroefdraden serieel worden uitgevoerd wat betekent dat als één thread uitvoert setter of getter, dan andere threads zal wachten.
Dit maakt eigenschap "naam" lezen / schrijven veilig, maar als een andere thread, D, noemt [name release]gelijktijdig dan is deze operatie kan een crash te produceren omdat er geen setter / getter call hier betrokken. Wat betekent dat een voorwerp lezen / schrijven safe (ATOMIC), maar niet thread veilig andere threads gelijktijdig elk soort berichten kan verzenden naar het object. De ontwikkelaar moet ervoor zorgen thread veiligheid voor dergelijke objecten.
Als de eigenschap "naam" nonatomic werd, worden alle draden in bovenstaand voorbeeld - A, B, C en D wordt uitgevoerd gelijktijdig produceren van elk onvoorspelbare resultaten. Bij atoom, een van A, B of C wordt eerst uitgevoerd, maar D nog steeds parallel worden uitgevoerd.
De syntax en semantiek zijn al goed gedefinieerd door andere uitstekende antwoorden op deze vraag. Omdat de uitvoering en de prestaties niet goed zijn uitgewerkt, zal ik mijn antwoord toe te voegen.
Wat is het functionele verschil tussen deze 3?
Ik zou altijd beschouwd atomaire als standaard heel nieuwsgierig. Op het abstractieniveau we werken, met behulp van atomaire eigenschappen voor een klasse als een voertuig tot 100% thread-veiligheidsniveau te bereiken is een hoek geval. Want echt correct multithreaded programma's, ingrijpen door de programmeur is vrijwel zeker een vereiste. Ondertussen, prestatie-eigenschappen en de uitvoering nog niet uitgewerkt in de diepte. Hebben geschreven sommige zwaar multithreaded programma's door de jaren heen, had ik verklaren mijn eigenschappen als nonatomicde hele tijd, omdat atomaire was niet verstandig voor enig doel. Tijdens de bespreking van de details van atomaire en nonatomic eigenschappen van deze vraag , ik heb wat profilering stuitte op merkwaardige resultaten.
Executie
OK. Het eerste wat ik zou willen opruimen, is dat de vergrendeling implementatie-implementatie gedefinieerd en geabstraheerd. Louis gebruikt @synchronized(self)in zijn voorbeeld - Ik heb dit gezien als een gemeenschappelijke bron van verwarring. De implementatie niet daadwerkelijk gebruik @synchronized(self); het maakt gebruik van niveau object draai sluizen . Illustratie Louis is goed voor een hoog niveau illustratie met behulp van constructies die we allemaal kennen, maar het is belangrijk om te weten het niet te gebruiken @synchronized(self).
Een ander verschil is dat de atomaire eigenschappen binnen de getter zal behouden / release-cyclus uw objecten.
Prestatie
Hier is het interessante deel: Prestaties met behulp van atomaire woning toegangen in onbetwiste (bijv single-threaded) gevallen kan echt heel snel zijn in sommige gevallen. In minder dan het ideale geval, kunnen gebruik maken van atomaire toegangen meer dan 20 keer de overhead van de kosten nonatomic. Terwijl de bestreden bij toepassing van 7 threads was 44 maal lager voor de drie bytes struct (2,2 GHz Core i7 Quad Core x86_64). De drie-byte struct is een voorbeeld van een zeer trage eigendom.
Interessante kanttekening: de gebruiker gedefinieerde accessors van de drie-byte struct waren 52 keer sneller dan de gesynthetiseerde atomaire accessors; of 84% van de snelheid van gesynthetiseerde nonatomic accessors.
Objecten in betwiste gevallen kunnen ook meer dan 50 keer.
Als gevolg van het aantal optimalisaties en variaties in implementaties, het is heel moeilijk om real-world gevolgen in deze context te meten. Je zou kunnen horen vaak iets als "Vertrouw op, tenzij je profiel en vind het een probleem". Als gevolg van het abstractieniveau, het is eigenlijk heel moeilijk is om de werkelijke impact te meten. Sprokkelen werkelijke kosten van profielen kunnen zeer tijdrovend zijn, en als gevolg van abstracties, heel onnauwkeurig. Als goed, ARC vs MRC kan een groot verschil maken.
Dus laten we een stap terug, niet gericht op de uitvoering van de woning toegangen, plaatsen we de gebruikelijke verdachten zoals objc_msgSend, en kijken naar enkele real-world high-level resultaten voor vele gesprekken naar een NSStringgetter in onbetwiste gevallen (in seconden):
Zoals u waarschijnlijk al geraden, verwijzingstelling activiteit / fietsen levert een belangrijke bijdrage met atomics en onder ARC. Je zou ook grotere verschillen in betwiste gevallen.
Hoewel ik aandacht schenken aan prestaties, zeg ik nog steeds Semantiek First! . Ondertussen, performance is een lage prioriteit voor veel projecten. Echter, in de wetenschap uitvoeringsdetails en de kosten van technologieën u zeker gebruik maken van geen kwaad. Je moet de juiste technologie gebruiken voor uw behoeften, doelen en vaardigheden. Hopelijk zal dit bespaart u een paar uur van vergelijkingen, en u helpen een beter geïnformeerde beslissing te nemen bij het ontwerpen van uw programma's.
Atomic = thread veiligheid
Niet-atoom = No thread veiligheid
Zo variabelen zijn thread-safe, indien ze correct gedragen als benaderd vanuit meerdere threads, ongeacht de plannen of verweving van de uitvoering van die onderwerpen die door de runtime-omgeving, en zonder extra synchronisatie of andere coördinatie van de zijde van de oproepende code.
Indien zich de waarde van de instantie verandert de veranderde waarde beschikbaar is voor alle draden, en slechts één thread kan de waarde tegelijk wijzigen.
atomic:Als de instantievariabele gaat is toegankelijk in een multithreaded omgeving.
atomic:Niet zo snel nonatomic, omdat nonatomicgeen waakhond werk aan dat vanaf runtime nodig hebben.
nonatomic:Als de instantie variabele is niet gonna worden gewijzigd door meerdere threads die u kunt gebruiken. Het verbetert de prestaties.
Ik vond een vrij goed zetten verklaring van atomaire en niet-atomaire eigenschappen hier . Hier is een aantal relevante tekst van dezelfde:
'atomaire' betekent dat het kan niet worden afgebroken. In OS / programmeertermen atomaire functievraag is een die niet kan worden onderbroken - de gehele functie moet worden uitgevoerd, en niet uit de CPU omgeruild gebruikelijke context van de OS schakelen totdat het voltooid is. Voor het geval dat u niet wist: sinds de CPU maar één ding kan doen op een moment, het besturingssysteem draait toegang tot de CPU om alle lopende processen in korte tijd-slices, aan de geven illusie van multitasking. De CPU scheduler kan (en doet) onderbreken van een proces op elk punt in de uitvoering ervan - zelfs midden in de functie aan te roepen. Dus voor acties zoals het updaten van gedeelde teller variabelen waar twee processen zou kunnen proberen om de variabele tegelijkertijd te werken, moeten ze worden uitgevoerd 'atomair', dat wil zeggen, elke update actie dient te eindigen in zijn geheel voordat enige andere proces kan worden verwisseld op de PROCESSOR.
Dus zou gok dat atoom in dit geval betekent het kenmerk lezer methoden niet onderbreken - in feite betekent dat de variabele (n) wordt gelezen door de werkwijze kan de waarde helft ongewijzigd doorgang door sommige andere thread / call / functie krijgt verwisseld op de CPU.
Omdat de atomicvariabelen niet kan worden onderbroken, de waarde die door deze op elk punt (schroefdraadslot) gegarandeerd uncorrupted , hoewel, zorgen deze draad slot maakt toegang daartoe langzamer. non-atomicvariabelen, aan de andere kant, maken geen dergelijke garantie, maar bieden wel de luxe van een snellere toegang. Samengevat, ga met non-atomicals u weet dat uw variabelen niet worden benaderd door meerdere threads tegelijk en snelheid dingen.
Na het lezen van zo veel artikelen, stack overflow berichten en het maken van demo applicaties om variabele eigendom attributen te controleren, heb ik besloten om alle attributen informatie die de samen te stellen:
atomic // Standaardnonatomicstrong = retain // Standaardweak = unsafe_unretainedretainassign // Standaardunsafe_unretainedcopyreadonlyreadwrite // StandaardIn het artikel Variable eigenschap attributen of modifiers in iOS kun je alle hierboven genoemde eigenschappen te vinden, en dat zal je zeker helpen.
atomic
atomic betekent maar een thread toegang tot de variabele (statisch).atomic thread safe.atomic is het standaard gedragVoorbeeld:
@property (retain) NSString *name;
@synthesize name;
nonatomic
nonatomic betekent meervoudige schroefdraad toegang variabele (dynamische type).nonatomic is threadonveilige.nonatomicis niet standaard gedrag. We moeten de voegen nonatomiczoekwoord in het pand attribuut.Voorbeeld:
@property (nonatomic, retain) NSString *name;
@synthesize name;
Makkelijkste antwoord eerst: Er is geen verschil tussen uw tweede twee voorbeelden. Standaard zijn eigendom accessors zijn atomaire.
Atomic accessors in een niet opgeschoond omgeving (dat wil zeggen bij gebruik te behouden / release / autorelease) zal een slot te gebruiken om ervoor te zorgen dat een andere thread niet interfereert met de juiste instelling / het krijgen van de waarde.
Zie de " Performance and Threading " sectie van Objective-C 2.0 documentatie van Apple voor wat meer informatie en voor andere overwegingen bij het maken van multi-threaded applicaties.
Atomic garanties dat de toegang tot het pand zal worden uitgevoerd in een atomaire manier. Bijvoorbeeld het altijd terug een volledig geïnitialiseerd objecten, elke get / set van een woning op één thread moet voltooien voordat een ander het kan openen.
Als u zich de volgende functie die zich op twee threads tegelijk kunt u zien waarom de resultaten niet mooi zou zijn.
-(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;
}
...
}
Voors: Return of volledig is geïnitialiseerd objecten elke keer is het de beste keuze in het geval van multi-threading.
Nadelen: Prestatie hit, maakt de uitvoering een beetje langzamer
In tegenstelling tot de Atomic, is het niet te verzekeren volledig is geïnitialiseerd object terug elke keer.
Pros: Extreem snelle uitvoering.
Nadelen: De kans vuilnis waarde in het geval van multi-threading.
Atoom betekent maar een thread toegang tot de variabele (statisch). Atomic is thread-safe, maar het is traag.
Nonatomic betekent meerdere threads toegang tot de variabele (dynamische type). Nonatomic is draad-onveilig, maar het is snel.
Atomic is thread safe , het is traag en het goed verzekert (niet gegarandeerd) dat alleen wordt de vergrendelde waarde ongeacht voorzien hoeveel threads worden toegang ten opzichte van dezelfde zone proberen. Bij gebruik atoom, een stukje code geschreven in deze functie wordt het gedeelte van de kritische sectie, waarbij slechts één thread kan uitvoeren tegelijk.
Verzekert alleen de draad veiligheid; Het kan niet garanderen dat. Wat ik bedoel is dat je een expert chauffeur te huren voor je auto, nog steeds geen garanties auto zal niet voldoen aan een ongeval. Echter, waarschijnlijkheid blijft het minst.
Atomic - het kan niet worden afgebroken, dus het resultaat wordt verwacht. Met nonatomic - wanneer een andere thread toegang tot het geheugengebied kan te wijzigen, zodat het resultaat is onverwacht.
Code Talk:
Atomic maken getter en setter van het pand thread safe. bijvoorbeeld als u geschreven:
self.myProperty = value;
thread safe.
[myArray addObject:@"Abc"]
NIET thread safe.
Er is geen keyword "atomic"
@property(atomic, retain) UITextField *userName;
We kunnen het bovenstaande gebruiken, zoals
@property(retain) UITextField *userName;
Zie stack overflow vraag ik krijg problemen als ik @property (atomaire, behouden) NSString * myString .
De standaard is atomic, betekent dit dat het kost u de prestaties als u de woning te gebruiken, maar het is veilig draad. Wat Objective-C heeft, ligt een slot, zodat alleen de actuele thread kan toegang tot de variabele, zolang de setter / getter wordt uitgevoerd.
MRC voorbeeld van een woning met een ivar _internal:
[_internal lock]; //lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;
Dus deze laatste twee zijn hetzelfde:
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName; // defaults to atomic
Aan de andere kant doet nonatomicniets toevoegen aan uw code. Dus het is alleen draad veilig als je beveiligingsmechanisme code zelf.
@property(nonatomic, retain) UITextField *userName;
De zoekwoorden hoeft niet te worden geschreven als eerste eigenschapkenmerk at all.
Vergeet niet, dit betekent niet dat het pand als geheel is thread-safe. Alleen de methode-aanroep van de setter / getter is. Maar als je een setter en daarna een getter te gebruiken op hetzelfde moment met 2 verschillende draden, het zou kunnen worden ook gebroken!
atoom (standaard)
Atomic is de standaard: als je niets te typen, uw eigendom is atomaire. Een atomaire eigenschap wordt gegarandeerd dat als je probeert te lezen van het, krijgt u terug een geldige waarde. Het geeft geen enkele garantie over wat die waarde zou kunnen zijn, maar u zult goede gegevens, niet alleen junk geheugen terug te krijgen. Wat dit kun je doen is als u meerdere threads of meerdere processen wijst op een enkele variabele, kan een thread lezen en andere draad kan schrijven. Als ze op hetzelfde moment te raken, wordt de lezer draad gegarandeerd een van de twee waarden te krijgen: ofwel vóór de wijziging of na de wijziging. Wat atomaire geeft u niet om het even welke soort van garantie voor welke van die waarden die u zou kunnen krijgen. Atomic is echt vaak verward met zijn thread-safe, en dat is niet juist. U moet uw veiligheid draad andere manieren te garanderen. Echter, atomaire zal garanderen dat als je probeert te lezen, krijg je een soort van waarde terug.
nonatomic
Aan de andere kant, niet-atomaire, zoals u waarschijnlijk kunt raden, betekent gewoon, “doe dat niet atomaire spul.” Wat je verliest is die garantie dat u altijd iets terug. Als u probeert te lezen in het midden van een afschrijving, kan je wartaal rug. Maar aan de andere kant, ga je een beetje sneller. Omdat atomaire eigenschappen moeten wat magie doen om te garanderen dat je terug krijgt een waarde, ze zijn een beetje langzamer. Als het een eigenschap die u toegang veel, kunt u omlaag naar nonatomic vallen om ervoor te zorgen dat je niet aangaan die snelheid boete.
Zie hier meer: https://realm.io/news/tmi-objective-c-property-attributes/
Hoe te verklaren:
Zoals atomaire is standaard ingeschakeld, zodat,
@property (retain) NSString *name;
Als voor de uitvoering bestand
self.name = @"sourov";
Stel dat een taak met betrekking tot drie eigenschappen zijn
@property (retain) NSString *name;
@property (retain) NSString *A;
@property (retain) NSString *B;
self.name = @"sourov";
Alle woningen werken parallel (zoals asynchroon).
Als u belt "naam" van de draad A ,
En
Op hetzelfde moment als je belt
[self setName:@"Datta"]
van draad B ,
Nu Als * naam van de eigenschap is nonatomic dan
Dat is de reden waarom niet atomaire wordt genoemd draad onveilig Maar, maar het is snel in de prestaties als gevolg van parallelle uitvoering
Nu Als * naam van de eigenschap is atomaire
Daarom atomaire wordt genoemd draad Safe en dat is waarom het heet lezen-schrijven safe
Een dergelijke situatie operatie zal in serie uit te voeren. En Slow in de prestaties
- nonatomic betekent meervoudige schroefdraad toegang variabele (dynamische type).
- nonatomic draad is onveilig.
- maar het is snel in de prestaties
-Nonatomic is niet standaard gedrag, moeten we nonatomic zoekwoord toe te voegen in eigenschapkenmerk.
Voor in Swift bevestigen dat Swift eigenschappen nonatomic de ObjC zin. Een van de redenen is, zodat u na te denken over de vraag of per-woning atomiciteit is voldoende voor uw behoeften.
Referentie: https://forums.developer.apple.com/thread/25642
Fro meer info kunt u terecht op de website http://rdcworld-iphone.blogspot.in/2012/12/variable-property-attributes-or.html
Als u uw woning in multi-threaded code dan zou je in staat zijn om het verschil tussen nonatomic en atomaire attributen te zien. Nonatomic is sneller dan atomaire en atomaire is thread-safe, niet nonatomic.
Vijayendra Tripathi heeft al een voorbeeld van een multi-threaded omgeving gegeven.
Voordat u begint: U moet weten dat elk object in het geheugen moet worden deallocated uit het geheugen voor een nieuw schrijven te gebeuren. Je kunt niet zomaar gewoon schrijven op de top van iets als jij op papier. Je moet eerst te wissen (dealloc) en dan kun je op te schrijven. Als op het moment dat het wissen wordt gedaan (of het halve werk) en niets is nog al schreef (of de helft heeft geschreven) en je probeert te lezen kan het zeer problematisch zijn! Atomic en nonatomic helpen dit probleem te behandelen op verschillende manieren.
Lees eerst deze vraag en lees dan antwoord Bbum's . Daarnaast lees dan mijn samenvatting.
atomic zal altijd garant
Behoud tellingen zijn op de wijze waarop het geheugen wordt beheerd in Objective-C. Wanneer u een object maakt, heeft het een behouden telling van 1. Wanneer u een object stuur behouden bericht, zijn behouden telling wordt verhoogd met 1. Wanneer u een object een versie bericht te sturen, wordt de behouden telling verlaagd met 1. Wanneer u stuur dan een object een autorelease bericht , wordt de behouden telling verlaagd met 1 op een bepaald moment in de toekomst. Als een object's behouden telling wordt teruggebracht tot 0, is het deallocated.
Wacht wat?! Zijn multithreading en draad veiligheid anders?
Ja. Multithreading betekent: meerdere threads kan een gedeelde stuk van de gegevens op hetzelfde moment lezen en we zullen niet crashen, maar het is geen garantie dat je niet lezen van een niet-autoreleased waarde. Met draad veiligheid, is het zeker dat wat je leest is niet automatisch vrijgegeven. De reden dat we niet alles atomaire standaard te maken is, want er is een performance kosten en voor de meeste dingen niet echt nodig de veiligheid draad. Een paar delen van onze code nodig hebben en voor die paar onderdelen die we nodig hebben om onze code te schrijven in een thread veilige manier met behulp van sloten, mutex of synchronisatie.
nonatomic
Over het algemeen zijn ze anders in 2 aspecten:
Crashen of niet omwille van het hebben of niet hebben autorelease zwembad.
Waardoor wordt gelezen in het midden van een 'nog niet klaar schrijf- of lege waarde' of niet toestaan en laten alleen leesbaar als de waarde wordt volledig geschreven.
Alvorens in te gaan over de attributen van @property, moet u weten wat is het nut van @property. @property biedt een manier om de informatie die een klasse is bedoeld om in te kapselen definiëren. Als u een object / variabele declareert met behulp @property, dan zal dat object / variabele toegankelijk zijn voor andere klassen importeren van zijn klasse. Als u een object te verklaren met behulp van @property in de header-bestand, dan moet je om het te synthetiseren met behulp van @ synthetiseren in de uitvoering bestand.
Voorbeeld:
.h klasse
@interface ExampleClass : NSObject
@property (nonatomic, retain) NSString *name;
@end
.m klasse
@implementation ExampleClass
@synthesize name;
@end
Nu is de compiler zal synthetiseren accessormethoden voor de naam.
ExampleClass *newObject=[[ExampleClass alloc]init];
NSString *name1=[newObject name]; // get 'name'
[obj setName:@“Tiger”];
Lijst van attributen van @property: atoom. nonatomic. behouden. kopiëren. alleen lezen. lezen schrijven. toewijzen. sterk.
atomaire: Het is het standaard gedrag. Als een object zoals atomaire gedeclareerd dan wordt het thread-safe. Thread-veilige middelen tegelijk slechts één draad van een bepaalde instantie van die klasse kan de controle over deze strekken.
voorbeeld:
@property NSString *name; //by default atomic
@property (atomic)NSString *name; // explicitly declared atomic
nonatomic: Het is niet thread-safe. U kunt de nonatomic eigenschapkenmerk gebruiken om aan te geven dat gesynthetiseerd accessors eenvoudig instellen of direct terug te keren een waarde, zonder garanties over wat er gebeurt als dat dezelfde waarde gelijktijdig is toegankelijk vanuit verschillende draden. Om deze reden, het is sneller toegang tot een nonatomic pand dan een atomaire één.
@property (nonatomic)NSString *name;
behouden: nodig als het attribuut een pointer naar een object.The setter methode zal toenemen behouden telling van het voorwerp, zodat het geheugen AutoRelease pool inneemt.
@property (retain)NSString *name;
exemplaar: Als u een kopie gebruikt, kunt u geen gebruik te behouden. Met behulp van een kopie instantie van de klasse zal zijn eigen exemplaar bevatten. Zelfs als een veranderlijk string vastgesteld en vervolgens veranderd, de instantie vangt wat waarde die het heeft op het moment dat deze is ingesteld. Geen setter en getter methoden worden gesynthetiseerd.
@property (copy) NSString *name;
NSMutableString *nameString = [NSMutableString stringWithString:@"Liza"];
xyzObj.name = nameString;
[nameString appendString:@"Pizza"];
alleen-lezen: Als u niet wilt dat het pand moet worden gewijzigd via setter methode, kunt u alleen-lezen verklaren het pand.
@property (readonly) NSString *name;
readwrite: is het standaard gedrag. Je hoeft niet te readwrite attribuut expliciet.
@property (readwrite) NSString *name;
wijzen: een zetter waarbij de waarde voor de instantievariabele rechtstreeks toegewezen, in plaats van kopiëren of behouden te genereren. Dit is het beste voor primitieve types zoals NSInteger en CGFloat, of objecten die je niet direct bezit, zoals afgevaardigden.
@property (assign) NSInteger year;
strong: is een vervanging voor te behouden.
@property (nonatomic, strong) AVPlayer *player;
unsafe_unretained: Er zijn een paar klassen in Cocoa en Cocoa Touch, dat nog niet ondersteunen zwak referenties, wat betekent dat je een zwakke eigenschap of zwakke lokale variabele niet te kennen te houden van hen. Deze klassen omvatten NSTextView, NSFont en NSColorSpace, etc. Als u een zwakke verwijzing te gebruiken om een van deze klassen, moet u een onveilige referentie gebruiken. Een onveilige verwijzing vergelijkbaar met een zwakke verwijzing doordat het zijn verwant doel levend bijhoudt, maar het zal niet worden ingesteld op nul indien het doelobject wordt deallocated.
@property (unsafe_unretained) NSObject *unsafeProperty;
De atomaire eigenschap zorgt voor een volledig is geïnitialiseerd waarde ongeacht hoeveel threads aan het doen zijn getter en setter op behouden.
De nonatomic eigenschap specificeert dat gesynthetiseerde accessors eenvoudig instellen of retourneren een waarde direct, zonder garanties over wat er gebeurt als dat gelijkwaardig tegelijkertijd toegankelijk vanuit verschillende draden.
Atoom betekent slechts één thread kan tegelijk (statisch) toegang tot de variabele. Atomic is thread-safe, maar het is traag.
Nonatomic betekent meerdere threads op hetzelfde moment (dynamisch type) toegang tot de variabele. Nonatomic is draad-onveilig, maar het is snel.
Als u met behulp van atomaire, betekent dit dat de draad zal veilig zijn en alleen-lezen. Als u gebruik maakt nonatomic, betekent dit dat de meerdere threads toegang tot de variabele en is draad onveilig, maar het wordt snel uitgevoerd, gedaan een lees- en schrijfbewerkingen; Dit is een dynamisch type.
Atomiciteit atoom (standaard)
Atomic is de standaard: als je niets te typen, uw eigendom is atomaire. Een atomaire eigenschap wordt gegarandeerd dat als je probeert te lezen van het, krijgt u terug een geldige waarde. Het geeft geen enkele garantie over wat die waarde zou kunnen zijn, maar u zult goede gegevens, niet alleen junk geheugen terug te krijgen. Wat dit kun je doen is als u meerdere threads of meerdere processen wijst op een enkele variabele, kan een thread lezen en andere draad kan schrijven. Als ze op hetzelfde moment te raken, wordt de lezer draad gegarandeerd een van de twee waarden te krijgen: ofwel vóór de wijziging of na de wijziging. Wat atomaire geeft u niet om het even welke soort van garantie voor welke van die waarden die u zou kunnen krijgen. Atomic is echt vaak verward met zijn thread-safe, en dat is niet juist. U moet uw veiligheid draad andere manieren te garanderen. Echter, atomaire zal garanderen dat als je probeert te lezen, krijg je een soort van waarde terug.
nonatomic
Aan de andere kant, niet-atomaire, zoals u waarschijnlijk kunt raden, betekent gewoon, “doe dat niet atomaire spul.” Wat je verliest is die garantie dat u altijd iets terug. Als u probeert te lezen in het midden van een afschrijving, kan je wartaal rug. Maar aan de andere kant, ga je een beetje sneller. Omdat atomaire eigenschappen moeten wat magie doen om te garanderen dat je terug krijgt een waarde, ze zijn een beetje langzamer. Als het een eigenschap die u toegang veel, kunt u omlaag naar nonatomic vallen om ervoor te zorgen dat je niet aangaan die snelheid boete. Toegang
courtesy https://academy.realm.io/posts/tmi-objective-c-property-attributes/
Atomiciteit eigenschap attributen (atomaire en nonatomic) zijn niet in het desbetreffende verklaring Swift eigenschap, maar het atomiciteit waarborgen van de implementatie Objective-C stil te houden wanneer de ingevoerde eigenschap is toegankelijk via Swift.
Dus - als u een atomaire woning in Objective-C te definiëren zal het atomaire blijven bij gebruik door Swift.
courtesy https://medium.com/@YogevSitton/atomic-vs-non-atomic-properties-crash-course-d11c23f4366c
Atomic eigenschappen : - Bij een variabele toegewezen met atomaire eigenschap dat betekent dat er slechts één thread toegang tot en het zal draad veilig en goed zal zijn in de prestaties perspectief, zal standaard gedrag te hebben.
Niet Atomic Eigenschappen : - Bij een variabele toegewezen met atomaire eigenschap dat betekent dat het heeft multi thread toegang en het zal niet worden thread safe en zal vertragen in de prestaties perspectief, zal standaard gedrag te hebben en wanneer twee verschillende threads wilt toegang tot variabele op hetzelfde moment het zal onverwachte resultaten.
De waarheid is dat zij gebruiken spin-slot om atomaire eigendom te implementeren. De code zoals hieronder:
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);
}
Om de hele verwarring te vereenvoudigen laat ons zien mutex lock.Mutex slot volgens de naam vergrendelt de veranderlijkheid van de object.So als het object is toegankelijk via een klasse geen enkele andere klasse kan toegang tot dezelfde object.In iOS @sychronise ook de mutex lock.Now serveren in FIFO-modus en zorgt ervoor dat de stroom wordt niet beïnvloed door twee klassen die dezelfde instance.However als de taak is van de rode draad te voorkomen toegang tot object met behulp van atomaire eigenschappen als het kan uw UI te houden en te degraderen van de prestaties
Atoom: Controleer draad veiligheid door het blokkeren van de draad met behulp NSLOCK.
Non atoom: Niet waarborgen thread veiligheid omdat er geen thread-sluiting.