[uho]

Witam, od jakiegoś czasu, w swoich appkach, zacząłem rozdzielać pewne zadania na wątki. Używam ARC i nurtuje mnie w związku z tym kilka pytań. Czy w prostych aplikacjach używanie non/atomic ma znaczenie ? Jeśli wątków w programie jest tyle co kot napłakał. Wiem że właściwość atomic generuje trochę bardziej skomplikowany setter i getter, jaki jest tego wpływ na działanie. W przypadku ARC różnica pomiędzy _zmienna, a self.zmienna, zaciera się jeśli nie zależy nam na zmianie domyślnych właściwości ? Jeśli zależy nam na nonatomic, to wszędzie gdzie tylko powinno używać się self.zmienna ?

[P_P]

Chyba raczej gdy zależy nam na atomic, to powinno się używać propertasa (self.zmienna), dla nonatomic chyba nie ma różnicy. Jeżeli wierzyć temu wpisowi: atomic vs nonatomic Properties in Objective-C - ItsAboutCode to atomic po prostu dodaje do gettera/settera @synchronized(self) {...} czyli blokuje semaforem dostęp do zmiennej gdy któryś wątek już na niej pracuje, co zapobiega race condition.

[uho]

A jeśli tworze jakiś obiekt, przypisuje go do wskaźnika.

NSObject *test = [NSObject alloc] init];

To test będzie domyślnie posiadał właściwości strong i atomic ? To samo z zadeklarowanymi wskaźnikami jak poniżej ?

@interface AddPatientVC () {
    float orgViewHeight;
    float orgViewWidth;
    KeyboardBar *keyboardBar;
    NSString *currentLanguage;
    UIActionSheet *asAddPhoto;
    UIImagePickerController *ipcPhoto;
    BOOL isPhoto;
}

Rozumiem zasadę że w przypadku atomic wątki czekają na dostęp do wartości, ale czy w prostych aplikacjach, czekanie nie przekłada się na jakieś opóźnienia widoczne dla użytkownika. Więc jeśli atomic jest domyśną właściwością, to powinno się używać właściwości nonatomic jeśli zależy nam na tym aby aplikacja działała szybciej, ryzykując nieprzewidzianymi sytuacjami, gdy kilka wątków dopiera się do danej wartości.

[P_P]

Sama zmienna raczej nie może mieć atomic, bo jest to po prostu dodatkowy narzut w getterze i setterze propertasa, a zmienna nie ma gettera i settera, tylko jest do niej przypisywana wartość bezpośrednio (jak ivar). Można oczywiście przypisywanie do tej zmiennej opakować w @synchronize(self) { test = cośtam; } żeby uzyskać ten sam efekt. Myślę że jeżeli chcesz zadbać o szybkie działanie aplikacji, to atomic/nonatomic jest ostatnią rzeczą na którą powinieneś patrzeć. Jest jakiś dodatkowy narzut, ale przy większości aplikacji będzie niezauważalny. A jeżeli na prawdę wydaje ci się, że aplikacja działa wolno, to użyj time profilera i sprawdź co zużywa najwięcej czasu, zazwyczaj to będą jakieś zbyt skomplikowane obliczenia, albo animacje (trzeba też pamiętać żeby wszystkie animacje zatrzymywać przed zmianą widoku jeżeli aktualny widok nie będzie dealokowany, czyli np przy nakładaniu nowego widoku na stos navigation controllera). Chyba że piszesz coś co rzeczywiście będzie zżerało większą część mocy obliczeniowej procka, ale do takich rzeczy lepiej pisać kod w czystym C/C++ i wrappować go do Objective-C/Objective-C++

[uho]

Trochę mi rozjaśniłeś, ale dalej widzę ciemność Przepisuje jedną z aplikacji i chciałbym nie popełnić błędów wynikających z mojej niewiedzy. Człowiek ciągle się uczy i zawsze znajdzie się coś co można zrobić lepiej. Do tej pory @property używałem tylko w przypadku obiektów z xib i zastanawiam się czy do innych rodzajów obiektów także powinienem ich użyć. Oczywiście robię tak od momentu przejścia na ARC.

[P_P]

Ja w zasadzie zawsze używam @property i self.nazwa. Między innymi dlatego, że jak mam np @property (nonatomic) NSUInteger index; to mogę sobie nadpisać setter i np. przypisując tylko self.index = 10 zmieniać index i np przesuwać scrollView do tego miejsca gdzie obiekt o indeksie 10 się znajduje. Nie trzeba wywoływać oddzielnej metody do przesuwania. Property obudowuje tylko iVara (zazwyczaj _nazwa) w metody getNazwa i setNazwa w których standardowo tylko odczytujesz/ustawiasz wartość tego iVara, ale można w nich dodać dodatkowy kod który wykona się zawsze przy odczytaniu/ustawieniu wartości. No i np. atomic dodaje taki kod który dodaje semafor i blokuje jednoczesny dostęp do iVara z kilku wątków. W zasadzie zazwyczaj się wykorzystuje nonatomic, chyba że robisz coś w wątku w tle i masz zamiar nadpisywać/odczytywać którąś zmienną, to wtedy dajesz jej atomic. A swoją drogą zwykła zmienna chyba też może być IBOutlet'em (przynajmniej w jednym Mac OSowym projekcie tak robiłem) więc nie musisz używać @property w ogóle ;]

[uho]

Dzięki, wszystko już jasne.

[robertjunior]

Myślę że jeżeli chcesz zadbać o szybkie działanie aplikacji, to atomic/nonatomic jest ostatnią rzeczą na którą powinieneś patrzeć.

Jeżeli @property jest oznaczone jako atomic, każdy dostęp do zmiennej wymusza poczekanie danego wątku na lock na danym obiekcie który to @property posiada. Jest to o wiele wolniejsze niż normalne wywołanie gettera/settera, ponieważ tutaj oddaje się kontrole systemowi (trap & context switch) który to sprawdza stan semafora. W pojedyńczym przypadku, faktycznie nie ma to znaczenia, ale jeżeli ktoś oznaczył by wszystkie zmienne jako atomic, wtedy było by to widoczne.


PS.
Atomic zabezpiecza dostęp do zmiennej, ale jeżeli zmienna to pointer do NSMutableArray, a na przykład ta klasa nie jest przeznaczona do dostępu z wielu wątków ( non thread safe ), a taki mamy zamiar, to nadal mamy problem.