Pytanie Jaka jest różnica między atrybutami atomowymi i nieatomowymi?


Co robią atomic i nonatomic w deklaracjach majątkowych?

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

Jaka jest różnica operacyjna między tymi trzema?


1723
2018-02-26 02:31


pochodzenie


developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/... - KKendall
@Alex Wayne - mam jeden problem i napisałem go, ale nikt nie odpowiedział na to. Czy możesz mi w tym pomóc? Pytanie Link - stackoverflow.com/questions/35769368/... - DJ1


Odpowiedzi:


Dwa ostatnie są identyczne; "atomowy" jest domyślnym zachowaniem (zauważ, że w rzeczywistości nie jest słowem kluczowym; jest określona tylko przez brak nonatomic - atomic został dodany jako słowo kluczowe w najnowszych wersjach llvm / clang).

Zakładając, że @syntetyzuje implementacje metod, atomowe vs. nieatomowe zmienia wygenerowany kod. Jeśli piszesz własnego setera / pozyskiwania, atomowe / nonatomic / retain / assign / copy są jedynie doradcze. (Uwaga: @synthesize jest teraz domyślnym zachowaniem w ostatnich wersjach LLVM, nie ma również potrzeby deklarowania zmiennych instancji, będą one również automatycznie syntetyzowane i będą miały _ poprzedzone ich nazwiskiem, aby zapobiec przypadkowemu bezpośredniemu dostępowi).

Z "atomowym", syntetyzowany seter / getter zapewni, że cały wartość jest zawsze zwracana z gettera lub ustawiana przez seter, niezależnie od aktywności ustawiacza w innym wątku. Oznacza to, że jeśli wątek A znajduje się pośrodku programu pobierającego, podczas gdy wątek B wywołuje funkcję ustawiającą, rzeczywista wartość rzeczywista - najprawdopodobniej obiekt autouzupełniany - zostanie zwrócona do osoby wywołującej w punkcie A.

W nonatomic, nie ma takich gwarancji. A zatem, nonatomic jest znacznie szybszy niż "atomowy".

Co robi "atomowy" nie do czyni wszelkie gwarancje dotyczące bezpieczeństwa nici. Jeśli wątek A wywołuje getter jednocześnie z wątkiem B i C wywołującym setter z różnymi wartościami, wątek A może otrzymać jedną z trzech zwróconych wartości - tę, przed wywołaniem którejkolwiek z setterów lub jedną z wartości przekazanych do ustawiaczy w B i C. Podobnie, obiekt może kończyć się wartością z B lub C, bez możliwości odróżnienia.

Zapewnienie integralności danych - jednego z głównych wyzwań związanych z programowaniem wielowątkowym - osiąga się w inny sposób.

Dodając do tego:

atomicity pojedyncza właściwość również nie może zagwarantować bezpieczeństwa wątku, gdy wiele zależnych właściwości jest w grze.

Rozważać:

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

W tym przypadku wątek A może zmienić nazwę obiektu przez wywołanie setFirstName: a następnie dzwoniąc setLastName:. W międzyczasie wątek B może wywołać fullName pomiędzy dwoma wywołaniami wątku A i otrzyma nowe imię połączone ze starym nazwiskiem.

Aby rozwiązać ten problem, potrzebujesz model transakcyjny. To znaczy. inny rodzaj synchronizacji i / lub wykluczenia, który pozwala na wykluczenie dostępu fullName podczas gdy właściwości zależne są aktualizowane.


1668
2018-02-26 06:40



Biorąc pod uwagę, że jakikolwiek bezpieczny dla wątku kod będzie robił własne blokowanie itp., Kiedy chciałbyś użyć atomowych właściwości dostępu? Mam problem z dobrym przykładem. - Daniel Dickison
@bbum ma sens. Podoba mi się twój komentarz do innej odpowiedzi, że bezpieczeństwo wątków jest bardziej problemem na poziomie modelu. Z definicji bezpieczeństwa wątków IBM: ibm.co/yTEbjY "Jeśli klasa jest poprawnie zaimplementowana, co jest kolejnym sposobem stwierdzenia, że ​​jest zgodna z jej specyfikacją, żadna sekwencja operacji (odczytów lub zapisów pól publicznych i wywołań metod publicznych) na obiektach tej klasy nie powinna być w stanie umieścić obiektu do stanu nieprawidłowego, obserwuj obiekt, który ma być w nieprawidłowym stanie, lub naruszaj niezmienniki, warunki wstępne lub warunki post-klasy. " - Ben Flynn
Oto przykład podobny do @StevenKramer: Mam @property NSArray* astronomicalEvents; wyświetla listę danych, które chcę wyświetlić w interfejsie użytkownika. Po uruchomieniu aplikacji wskaźnik wskazuje pustą tablicę, a następnie aplikacja pobiera dane z sieci. Po zakończeniu żądania (w innym wątku) aplikacja tworzy nową tablicę, a następnie ustawia ją atomicznie na nową wartość wskaźnika. Jest bezpieczny dla wątków i nie musiałem pisać żadnego kodu blokującego, chyba że czegoś mi brakuje. Wydaje mi się to bardzo przydatne. - bugloaf
@HotLicks Kolejny zabawny; na niektórych architekturach (nie pamiętam, który z nich), 64-bitowe wartości przekazane jako argumenty mogą zostać przekazane w połowie w rejestrze, a połowę na stosie. atomic zapobiega odczytaniu połowy wartości wątku. (To był zabawny błąd do wyśledzenia.) - bbum
@congliu Wątek A zwraca obiekt bez retain/autorelease taniec. Wątek B zwalnia obiekt. Wątek A idzie Bum. atomic zapewnia, że ​​wątek A ma silne odniesienie (wartość zatrzymania +1) dla wartości zwracanej. - bbum


Zostało to wyjaśnione w Apple's dokumentacja, ale poniżej kilka przykładów tego, co się naprawdę dzieje. Zauważ, że nie ma słowa kluczowego "atomowy", jeśli nie określisz "nieatomowy", wówczas właściwość jest atomowa, ale bezpośrednie określenie "atomowej" spowoduje błąd.

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

- (UITextField *) userName {
    return userName;
}

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

Teraz wariant atomowy jest nieco bardziej skomplikowany:

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

Zasadniczo, wersja atomowa musi podjąć blokadę, aby zagwarantować bezpieczeństwo wątku, a także podważyć liczbę powtórzeń na obiekcie (i liczbę autoreassesów zliczyć, aby ją zrównoważyć), aby obiekt był gwarantowany dla osoby dzwoniącej, w przeciwnym razie jest potencjalnym warunkiem wyścigowym, jeśli inny wątek ustawia wartość, powodując spadek liczby ref do 0.

W rzeczywistości istnieje wiele różnych wariantów działania tych funkcji w zależności od tego, czy właściwości są wartościami skalarnymi lub obiektami oraz w jaki sposób zachowują, kopiują, czytają, nieatomowo, itp. Ogólnie rzecz biorąc, syntezatory właściwości wiedzą, jak zrobić "właściwą rzecz" dla wszystkich kombinacji.


342
2018-02-26 06:24



Nie oznacza to, że zamek nie "gwarantuje bezpieczeństwa gwintu". - Jonathan Sterling
@Louis Gerbarg: Wierzę, że twoja wersja ustawnika (nieatomowego, zatrzymującego) nie będzie działać poprawnie, jeśli spróbujesz przypisać ten sam obiekt (to jest: nazwa_użytkownika == nazwa_użytkownika_) - Florin
Twój kod jest nieco mylący; jest Nie gwarancja, jakie zsynchronizowane są moduły pobierania / ustawiania atomów. Krytycznie,@property (assign) id delegate; nie jest zsynchronizowany na niczym (iOS SDK GCC 4.2 ARM -Os), co oznacza, że ​​istnieje wyścig pomiędzy [self.delegate delegateMethod:self]; i foo.delegate = nil; self.foo = nil; [super dealloc];. Widzieć stackoverflow.com/questions/917884/... - tc.
@fyolnish Nie jestem pewien co _val/val są, ale nie, nie bardzo. Zdobywca atomowego copy/retain Właściwość musi upewnić się, że nie zwraca obiektu, którego refcount staje się zerowy, ponieważ setter jest wywoływany w innym wątku, co w zasadzie oznacza, że ​​musi odczytać ivar, zachować go, upewniając się, że setter nie nadpisał-i-zwolnił go , a następnie autoreasować w celu zrównoważenia zatrzymania. To w zasadzie oznacza obie getter i seter muszą korzystać z blokady (jeśli układ pamięci został naprawiony, powinien być wykonalny z instrukcjami CAS2; -retain jest wywołaniem metody). - tc.
@tc To było dość długo, ale to, co chciałem napisać, to prawdopodobnie to: gist.github.com/fjolnir/5d96b3272c6255f6baae Ale tak, możliwe jest odczytanie starej wartości przez czytnik przed setFoo: zwraca i zwalnia, zanim czytelnik go zwróci. Ale może gdyby setter użył -autorelease zamiast -release, to by to naprawiło. - Fjölnir


Atomowy

  • jest domyślnym zachowaniem
  • zapewni, że obecny proces zostanie zakończony przez procesor, zanim inny proces uzyska dostęp do zmiennej
  • nie jest szybki, ponieważ zapewnia całkowite zakończenie procesu

Nieatomowy

  • NIE jest domyślnym zachowaniem
  • szybszy (dla zsyntetyzowanego kodu, czyli dla zmiennych utworzonych za pomocą @property i @synthesize)
  • nie wątki bezpieczne
  • może spowodować nieoczekiwane zachowanie, gdy dwa różne procesy uzyskują dostęp do tej samej zmiennej w tym samym czasie

148
2018-05-25 10:56





Najlepszym sposobem zrozumienia różnicy jest użycie następującego przykładu.

Załóżmy, że istnieje niepodzielna właściwość string o nazwie "nazwa", a jeśli zadzwonisz [self setName:@"A"] z wątku A, zadzwoń [self setName:@"B"] z wątku B i zadzwoń [self name] z wątku C, wtedy wszystkie operacje na różnych wątkach będą wykonywane szeregowo, co oznacza, że ​​jeśli jeden wątek wykonuje setter lub getter, wtedy inne wątki będą czekać.

Dzięki temu właściwość "nazwa" jest bezpieczna dla odczytu / zapisu, ale jeśli wywoływany jest inny wątek, D [name release] jednocześnie ta operacja może spowodować awarię, ponieważ nie ma tu mowy o wywołaniu settera / gettera. Co oznacza, że ​​obiekt jest bezpieczny do odczytu i zapisu (ATOMIC), ale nie jest bezpieczny dla wątków, ponieważ inne wątki mogą jednocześnie wysyłać wiadomości dowolnego typu do obiektu. Deweloper powinien zapewnić bezpieczeństwo wątków dla takich obiektów.

Jeśli właściwość "nazwa" byłaby nieatomowa, wszystkie wątki w powyższym przykładzie - A, B, C i D będą wykonywane jednocześnie, dając nieprzewidywalny wynik. W przypadku atomu, jeden z A, B lub C wykona pierwszy, ale D może nadal wykonywać się równolegle.


125
2018-01-31 18:36





Składnia i semantyka są już dobrze zdefiniowane przez inne doskonałe odpowiedzi na to pytanie. Bo wykonanie i wydajność nie są dobrze szczegółowe, dodam moją odpowiedź.

Jaka jest różnica funkcjonalna między tymi 3?

Zawsze uważałem atomowe za domyślne za dość ciekawe. Na poziomie abstrakcji, w której pracujemy, używając właściwości atomowych dla klasy jako pojazdu, aby osiągnąć 100% bezpieczeństwo gwintu, jest to przypadek narożny. W przypadku naprawdę poprawnych programów wielowątkowych interwencja programisty prawie na pewno jest wymagana. Tymczasem cechy wydajności i wykonanie nie zostały jeszcze szczegółowo opisane. Napisałam na przestrzeni lat wiele programów wielowątkowych, dlatego deklarowałam swoje własności jako nonatomicprzez cały czas, ponieważ atom nie był sensowny dla żadnego celu. Podczas omawiania szczegółów właściwości atomowych i nieatomowych to pytanieZrobiłem profilowanie napotkane jakieś ciekawe wyniki.

Wykonanie

Ok. Pierwszą rzeczą, którą chciałbym wyjaśnić, jest to, że implementacja blokowania jest zdefiniowana i definiowana przez implementację. Louis używa @synchronized(self) w jego przykładzie - widziałem to jako wspólne źródło zamieszania. Wdrożenie nie tak właściwie posługiwać się @synchronized(self); wykorzystuje poziom obiektu blokady spinów. Ilustracja Louisa jest dobra do ilustracji wysokiego poziomu z wykorzystaniem konstrukcji, które wszyscy znamy, ale ważne jest, aby wiedzieć, że nie używa @synchronized(self).

Inną różnicą jest to, że właściwości atomowe zatrzymają / zwalniają cykl obiektów w obrębie gettera.

Wydajność

Oto interesująca część: Wydajność z dostępem do własności atomowej bezsporny (np. jednowątkowe) skrzynki mogą być naprawdę bardzo szybkie w niektórych przypadkach. W mniej niż idealnych przypadkach użycie dostępu atomowego może kosztować więcej niż 20-krotność ogólnych kosztów nonatomic. Podczas Zaskarżony obudowa wykorzystująca 7 wątków była czterokrotnie wolniejsza dla trójbajtowej struktury (2,2 GHz Core i7 Quad Core, x86_64). Struktura trzech bajtów jest przykładem bardzo powolnej właściwości.

Interesująca uwaga na marginesie: zdefiniowane przez użytkownika akcesory trójbajtowej struktury były 52 razy szybsze niż zsyntetyzowane akcesoria atomowe; lub 84% prędkości syntezowanych nieatomowych akcesorów.

Obiekty w spornych przypadkach mogą również przekraczać 50 razy.

Ze względu na liczne optymalizacje i warianty implementacji trudno jest zmierzyć rzeczywisty wpływ w tych kontekstach. Często możesz usłyszeć coś w stylu "Zaufaj, chyba że profilujesz i uważasz, że to problem". Ze względu na poziom abstrakcji faktycznie trudno jest zmierzyć rzeczywisty wpływ. Zliczanie rzeczywistych kosztów z profili może być bardzo czasochłonne, a ze względu na abstrakcje dosyć niedokładne. Jak dobrze, ARC vs MRC może zrobić dużą różnicę.

Cofnijmy się, nie koncentrując się na implementacji dostępu do nieruchomości, włączymy zwykłych podejrzanych, takich jak objc_msgSendi zbadać niektóre rzeczywiste wyniki na wysokim poziomie dla wielu połączeń do NSString wchodzić do środka bezsporny przypadki (wartości w sekundach):

  • MRC | nieatomowy | ręcznie zaimplementowane pobierające: 2
  • MRC | nieatomowy | syntezowane getter: 7
  • MRC | atomowy | syntezowane getter: 47
  • ARC | nieatomowy | syntetyzowany getter: 38 (uwaga: tutaj dodaje się cykl zliczania ARC)
  • ARC | atomowy | syntezowane getter: 47

Jak zapewne się domyślasz, liczenie aktywności / jazdy na rowerze jest znaczącym wkładem w atomikę i ARC. Widziałbyś także większe różnice w spornych przypadkach.

Chociaż zwracam szczególną uwagę na wydajność, nadal mówię Semantyka pierwsza!. Tymczasem wydajność jest niskim priorytetem dla wielu projektów. Jednak znajomość szczegółów wykonania i kosztów technologii, z których korzystasz na pewno nie zaszkodzi. Powinieneś używać odpowiedniej technologii do swoich potrzeb, celów i umiejętności. Mamy nadzieję, że dzięki temu zaoszczędzisz kilkugodzinnych porównań i pomożesz podejmować lepsze decyzje przy projektowaniu swoich programów.


108
2017-08-18 09:47



MRC | atomowy | syntezowane getter: 47 ARC | atomowy | syntezowane getter: 47 Co sprawia, że ​​są takie same? Czy ARC nie powinno mieć więcej narzutów? - SDEZero
Więc jeśli właściwości atomowe są złe, są one domyślne. Aby zwiększyć kod na płycie? - Kunal Balani
@ LearnCocos2D właśnie przetestowałem na 10.8.5 na tym samym komputerze, celując na 10.8, dla pojedynczego gwintowanego bezspornego przypadku z NSString który nie jest nieśmiertelny: -ARC atomic (BASELINE): 100% -ARC nonatomic, synthesised: 94% -ARC nonatomic, user defined: 86% -MRC nonatomic, user defined: 5% -MRC nonatomic, synthesised: 19% -MRC atomic: 102% - wyniki są dziś nieco inne. Nie robiłem żadnego @synchronizedporównania. @synchronized jest semantycznie odmienna i nie uważam tego za dobre narzędzie, jeśli masz nietrywialne programy współbieżne. jeśli potrzebujesz prędkości, unikaj @synchronized. - justin
masz gdzieś ten test online? Wciąż dodajemy moje tutaj: github.com/LearnCocos2D/LearnCocos2D/tree/master/... - LearnCocos2D
@ LearnCocos2D Nie przygotowałem ich do spożycia przez ludzi, przepraszam. - justin


Atomowy= bezpieczeństwo wątku

Nieatomowy = Brak bezpieczeństwa wątku

Bezpieczeństwo wątków:

Zmienne instancji są bezpieczne dla wątków, jeśli zachowują się poprawnie w przypadku dostępu z wielu wątków, niezależnie od planowania lub przeplatania wykonywania tych wątków przez środowisko wykonawcze, bez dodatkowej synchronizacji lub innej koordynacji części kodu wywołującego.

W naszym kontekście:

Jeśli wątek zmienia wartość instancji, zmieniona wartość jest dostępna dla wszystkich wątków, a tylko jeden wątek może zmieniać wartość naraz.

Gdzie użyć atomic:

jeśli zmienna instancji będzie dostępna w środowisku wielowątkowym.

Implikacja atomic:

Nie tak szybko, jak nonatomic bo nonatomic nie wymaga żadnej pracy watchdoga z tego środowiska wykonawczego.

Gdzie użyć nonatomic:

Jeśli zmienna instancji nie zostanie zmieniona przez wiele wątków, możesz jej użyć. Poprawia wydajność.


89
2017-07-10 13:07



Wszystko, co tu mówisz, jest poprawne, ale ostatnie zdanie jest zasadniczo "niesłuszne", Dura, do dzisiejszego programowania. To naprawdę niewyobrażalne, aby w ten sposób próbować "poprawić wydajność". (Mam na myśli to, że zanim osiągniesz wiek lat świetlny, będziesz "nie używa ARC", "nie używając NSString, ponieważ jest powolny!" Itd.) Aby zrobić skrajny przykład, byłoby to jak powiedzenie "zespół, nie umieszczaj żadnych komentarzy w kodzie, ponieważ spowalnia to nas. " Nie ma realistycznego procesu rozwojowego, w którym chciałbyś (nieistniejącego) teoretycznego wzrostu wydajności z powodu niewiarygodności. - Fattie
@JoeBlow to fakt, możesz go tutaj zweryfikować developer.apple.com/library/mac/documentation/Cocoa/Conceptual/... - Durai Amuthan.H
Ładnie wyjaśnione (y) - Sunil Targe


Znalazłem całkiem dobre wyjaśnienie właściwości atomowych i nieatomowych tutaj. Oto odpowiedni tekst z tego samego:

"atomowy" oznacza, że ​​nie można go zepsuć.   W terminologii OS / programowanie wywołanie funkcji atomowej to takie, którego nie można przerwać - cała funkcja musi być wykonana, a nie zamieniona przez CPU przez zwykłe przełączanie kontekstu systemu operacyjnego, dopóki nie zostanie zakończona. Na wszelki wypadek, gdybyś nie wiedział: ponieważ procesor może wykonać tylko jedną rzecz na raz, system operacyjny obraca dostęp do procesora do wszystkich działających procesów w krótkich odcinkach czasu, aby iluzja wielozadaniowości. Program planujący CPU może (i robi) przerwać proces w dowolnym momencie jego wykonania - nawet w trakcie wywołania funkcji środkowej. Tak więc dla działań takich jak aktualizacja współdzielonych zmiennych licznika, gdy dwa procesy mogą próbować aktualizować zmienną w tym samym czasie, muszą być wykonywane "atomowo", tj. Każda akcja aktualizacji musi zakończyć się w całości zanim dowolny inny proces może zostać zamieniony na PROCESOR.

Więc zgaduję, że atomic w tym przypadku oznacza, że ​​metody czytnika atrybutów nie mogą zostać przerwane - co oznacza, że ​​zmienna (y) odczytana przez metodę nie może zmienić ich wartości w połowie, ponieważ jakiś inny wątek / wywołanie / funkcja dostaje zamienione na procesor.

Ponieważ atomic zmienne nie mogą być przerywane, wartość zawarta w nich w dowolnym punkcie to (wątek-blokada) gwarantowana nieuszkodzony, chociaż zapewnienie tej blokady wątków sprawia, że ​​dostęp do nich jest wolniejszy. non-atomic zmienne natomiast nie dają takiej gwarancji, ale oferują luksus szybszego dostępu. Podsumowując, idź z non-atomic gdy wiesz, że twoje zmienne nie będą dostępne jednocześnie przez wiele wątków i przyspieszysz.


67
2018-02-24 05:17





Po przeczytaniu tylu artykułów, postów Stack Overflow i zrobieniu aplikacji demonstracyjnych, aby sprawdzić atrybuty właściwości zmiennych, postanowiłem połączyć wszystkie informacje o atrybutach:

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

W artykule Zmienne atrybuty właściwości lub modyfikatory w iOS możesz znaleźć wszystkie wyżej wymienione atrybuty, a to z pewnością ci pomoże.

  1. atomic

    • atomic oznacza, że ​​tylko jeden wątek uzyskuje dostęp do zmiennej (typ statyczny).
    • atomic jest bezpieczny dla wątków.
    • Ale wydajność jest powolna
    • atomic jest domyślnym zachowaniem
    • Atomowe accessory w środowisku, w którym nie gromadzi się śmieci (to znaczy przy użyciu retain / release / autorelease) będą wykorzystywać blokadę, aby zapewnić, że inny wątek nie zakłóca prawidłowego ustawienia / uzyskania wartości.
    • To w rzeczywistości nie jest słowo kluczowe.
       

    Przykład:

        @property (retain) NSString *name;
    
        @synthesize name;
    
  2. nonatomic

    • nonatomic oznacza wielokrotny dostęp do zmiennej (typ dynamiczny).
    • nonatomic jest niebezpieczny dla wątków.
    • Ale jest szybki w działaniu
    • nonatomic NIE jest domyślnym zachowaniem. Musimy dodać nonatomic słowo kluczowe w atrybucie property.
    • Może to spowodować nieoczekiwane zachowanie, gdy dwa różne procesy (wątki) uzyskują dostęp do tej samej zmiennej w tym samym czasie.
       

    Przykład:

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

61
2018-03-21 07:10



W jaki sposób przypisać i mocne / zachować oba mogą być domyślne? - BangOperator
silny pochodzi z ARC, zatrzymanie było domyślne przed ARC - abdullahselek


Najpierw najłatwiejsza odpowiedź: nie ma różnicy pomiędzy Twoimi dwoma przykładami. Domyślnie obiekty dostępowe właściwości są atomowe.

Atomowe accessory w środowisku, w którym nie gromadzi się śmieci (to znaczy przy użyciu retain / release / autorelease) będą wykorzystywać blokadę, aby zapewnić, że inny wątek nie zakłóca prawidłowego ustawienia / uzyskania wartości.

Zobacz "Wydajność i gwintowanie"Sekcja dokumentacji Objective-C 2.0 firmy Apple zawierająca więcej informacji i inne kwestie związane z tworzeniem aplikacji wielowątkowych.


52
2018-02-26 02:56



Dwa powody. Po pierwsze, w przypadku zsyntetyzowanego kodu generuje on szybciej (ale nie w przypadku kodów zawierających wątki). Po drugie, jeśli piszesz akcesory klienta, które nie są atomowe, możesz opisać dla każdego przyszłego użytkownika, że ​​kod nie jest atomowy podczas czytania jego interfejsu, bez konieczności implementacji. - Louis Gerbarg
@Dogweather: patrz Dlaczego właściwości IBOutlet w Cocoa są domyślnie atomowe, a Cocoa Touch nie? - Anoop Vaidya


Atomowy:

Atomowe gwarancje, że dostęp do nieruchomości będzie wykonywany w sposób atomowy. Na przykład. zawsze zwraca w pełni zainicjalizowane obiekty, każde pobranie / zestaw właściwości w jednym wątku musi się zakończyć, zanim inny będzie mógł uzyskać do niego dostęp.

Jeśli wyobrazisz sobie następującą funkcję występującą na dwóch wątkach jednocześnie, możesz zobaczyć, dlaczego wyniki nie będą ładne.

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

  ...
}

Zalety: Zwrot w pełni inicjowanych obiektów za każdym razem stanowi najlepszy wybór w przypadku wielowątkowości.

Cons : Uderzenie wydajnościowe sprawia, że ​​wykonanie jest nieco wolniejsze

Nieatomowy:

W przeciwieństwie do Atomic, nie zapewnia on w pełni inicjalizowanego obiektu za każdym razem.

Zalety: Niezwykle szybka realizacja.

Cons : Szanse na wartość śmieci w przypadku wielowątkowości.


52
2018-02-26 02:41



Ten komentarz nie ma większego sensu. Możesz wyjaśnić? Jeśli spojrzysz na przykłady na stronie Apple, słowo kluczowe atomowe synchronizuje się z obiektem podczas aktualizacji jego właściwości. - Andrew Grant
Ta odpowiedź ma dla mnie więcej sensu niż jakakolwiek inna odpowiedź! Dziękuję za wyjaśnienie. - dreamBegin


Atomowy oznacza, że ​​tylko jeden wątek uzyskuje dostęp do zmiennej (typ statyczny). Atomic jest bezpieczny dla wątków, ale działa wolno.

Nonatomic oznacza, że ​​wiele wątków ma dostęp do zmiennej (typ dynamiczny). Nonatomic jest niebezpieczny dla wątków, ale jest szybki.


31
2017-11-22 11:20