Jeśli przeciągniesz nowe gniazdo z Konstruktora interfejsu do pliku interfejsu (nagłówka), Xcode 4.6 automatycznie utworzy dla Ciebie właściwość ...

W systemie iOS (Cocoa Touch) będzie wyglądać następująco:

@property (weak, nonatomic) SomeClass *someProperty; //nonatomic accessors

Podczas gdy w OS X (Cocoa) będzie wyglądać tak:

@property (weak) SomeClass *someProperty; //atomic accessors (implicitly)

Czemu?

EDYTOWAĆ: Nie pytam o to, co robi lub czego nie robi atom, dobrze zdaję sobie sprawę z dyrektywy synchronizacji i leżącego u jej podstaw muteksu (lub blokady lub czegoś innego), który gwarantuje atomowość setera i gettera. Wiem, że w systemie iOS akcesory są nieatomowe, ponieważ UIKit nie jest bezpieczny dla wątków, a więc nie ma nic do zyskania, czyniąc je atomowymi, to tylko strata czasu procesora i żywotność baterii. Mówię tu o przypadku domyślnym, programiści, którzy wiedzą, co robią, będą wiedzieć, kiedy muszą uczynić swoje akcesory atomowymi.

Pytam więc, dlaczego domyślnie są one atomowe w systemie OS X. Miałem wrażenie, że Appkit też nie jest bezpieczny dla wątków. Posiadanie atomowych akcesoriów nie gwarantuje bezpieczeństwa wątków, a nawet posunąłbym się do stwierdzenia, że ​​idzie to w przeciwnym kierunku, ponieważ może dać iluzję bezpieczeństwa wątku początkującym programistom i sprawić, że śledzenie błędów będzie trudniejsze w aplikacjach współbieżnych, odraczając awarie w późniejszym czasie i tym samym utrudniając ich śledzenie. I właśnie dlatego, że komputery stacjonarne są stosunkowo potężne, nie oznacza to, że zasoby powinny zostać zmarnowane (zauważ, że nie mówię tu o przedwczesnej optymalizacji), a ponieważ jest to uzasadnione, że inżynierowie Apple są rozsądnymi programistami, musi istnieć dobry powód, dla którego mają postanowił, że właściwości domyślnie syntetyzują atomowe akcesoria.