Co to jest threadsafe atomic czy non atomic?

Dla właściwości ObjC -- ani wątek nie jest bezpieczny .

Atomic jest bardziej odporny na błędy gwintowania. Ogólnie rzecz biorąc, jest to ciekawa wartość domyślna. Scenariusze, dla których preferowałbyś atomic, są bardzo nieliczne. Atomic może zwiększyć prawdopodobieństwo poprawności, ale to na zbyt niskim poziomie można uznać za substytut WŁAŚCIWEGO mechanizmu blokującego. Dlatego, jeśli potrzebujesz bezpieczeństwa wątku, nadal potrzebujesz innej synchronizacji prymitywnej na szczycie atomowego odczytu/zapisu. Jeśli nie potrzebujesz bezpieczeństwa wątku (np. instancja jest niezmienna lub przeznaczona do uruchomienia tylko z głównego wątku), atomic nic nie doda.

Bycie odpornym na błędy wątków nie jest 'jakością' - służy do maskowania prawdziwych błędów wątków i utrudniania ich odtworzenia i wykrycia.

Zauważ również, że typy mutable vs. immutable nie gwarantują bezpieczeństwa threadsafety. "Mutable" może być używane w nazwach obiektów, aby odnosić się tylko do interfejsu -- wewnętrznych instancja niezmienna może mieć wewnętrzny, zmienny stan. Krótko mówiąc, nie można zakładać, że typ, który ma zmienną podklasę, jest bezpieczny dla wątku.

Pytanie Rozszerzone:

Załóżmy, że istnieje atomic string property o nazwie "name", i jeśli wywołasz [self setName:@"a"] z wątku A, wywołasz [self setName:@"B"] z wątku B, A wywołasz [self name] Z wątku C, wtedy cała operacja na innym wątku będzie wykonywana seryjnie, co oznacza, że jeśli jeden wątek zostanie thread wykonuje setter lub getter, wtedy inne wątki będą czekać.

Gdyby wszystkie wątki próbowały jednocześnie odczytywać i / lub zapisywać do właściwości, tylko jeden wątek miałby dostęp naraz, a pozostałe byłyby zablokowane, gdyby właściwość była atomowa. Gdyby właściwość była nieatomowa, to wszyscy mieliby niestrzeżony dostęp do odczytu i zapisu zmiennej w tym samym "czasie".

Jeśli inny wątek D wywoła jednocześnie [name release], operacja może spowoduj awarię, ponieważ nie ma tu połączenia setter/getter.

Zgadza się.

Co oznacza, że obiekt jest bezpieczny do odczytu/zapisu (atomowy), ale nie jest bezpieczny dla wątku, ponieważ inne wątki mogą jednocześnie wysyłać do obiektu dowolne wiadomości.

    @interface MONPerson : NSObject

    @property (copy) NSString * firstName;
    @property (copy) NSString * lastName;

    - (NSString *)fullName;

    @end

Atomic, lub nonatomic, będziesz potrzebował mechanizmu synchronizacji (np. lock), jeśli jeden wątek czyta z tej instancji, a drugi jest piszę do niego. Możesz skończyć z pierwszym imieniem Monpersona i ostatnim nazwiskiem innego Monpersona-obiekt mógł się zmienić przed zwróceniem wartości zwracanej przez getter, lub może się to zdarzyć:

Wątek A:

p.firstName = @"Rob";

Wątek B:

p.firstName = @"Robert";

Wątek A:

label.string = p.firstName; // << uh, oh -- will be Robert

Jeśli właściwość "name" była nieatomiczna, to wszystkie wątki w powyższym przykładzie - A,B, C i D będą wykonywane jednocześnie, dając dowolny nieprzewidywalny wynik.

Prawo-początkowe objawy mogą być nierównowaga liczby odniesienia(wyciek, nadmierne zwolnienie).

W przypadku atomów, jeden z A, B lub C będzie wykonywany jako pierwszy, ale D może nadal wykonywać równolegle. Uprzejmie skomentuj to....

Zgadza się. Ale jeśli spojrzeć na przykład powyżej -- sam atomic rzadko jest odpowiednim zamiennikiem zamka. Zamiast tego musiałoby to wyglądać tak:

Wątek A:

[p lock]; // << wait for it… … … …
// Thread B now cannot access p
p.firstName = @"Rob";
NSString fullName = p.fullName;
[p unlock];
// Thread B can now access p
label.string = fullName;

Wątek B:

[p lock]; // << wait for it… … … …
// Thread A now cannot access p
…
[p unlock];