On Thursday, April 9, 2015 at 4:35:44 PM UTC+2, Wojciech Muła wrote:
> On Thursday, April 9, 2015 at 1:20:44 PM UTC+2, M.M. wrote:
> > Jakie korzyści płyną z tego w praktyce?
>
> No takie, że jeden procesor zawsze odczyta/zapisze całe 64 bity
> w całości, nie musi dbać o zapis i odczyt. Chodzi o to, że jak
> zapisujesz 64-bitową liczbę to masz *gwarancję*, że zapisane zostały
> wszystkie dane, a nie, że np. 1 procesor zapisał pierwsze 3 bajty,
> a 2 procesor dopisał 5 pozostałych.
Czyli mamy na myśli to samo :)

>
> > Jak mam przypisanie:
> > zmienna_lokalna = zmienna_globalna;
> > Zmienna globalna mogła zostać zmodyfikowana przez inny wątek/proces.
>
> > Jeśli dostępu do zmienna_globalna nie obejmę sekcją krytyczną, to
> > wiem że dane w zmiennej globalnej i tak będą spójne. Ale co w sytuacji, gdy
> > wątek modyfikujący robi:
> > zmienna_globalna += cos;
> > albo
> > zmienna_globalna *= cos;
> > zmienna_globalna %= cos;
> >
> > Czy dane nadal będą spójne?
>
> Ale to jest już inny przypadek.
Ściśle inny, generalnie ten sam - wątek jakoś zmodyfikował zawartość
zmiennej, a programista nie jest pewny:
1) czy zmodyfikowana zmienna jest widoczna dla innych wątków,
2) czy inny wątek może zobaczyć zmienną zmodyfikowana 'w połowie'.


> Dodawanie, odejmowanie i operacje
> bitowe też mogą być atomowe na x86, ale dla pozostałych rzeczywiście
> trzeba mieć jakąś formę sekcji krytycznej.
Ok, ale w praktyce używamy języków wysokiego poziomu. Piszę np.
a = b;
a kompilator wywnioskował że b będzie równe zero i zrobi:
a ^= a;
Na jakimś procesorze xor może nie być już atomowe.


> > Na pewno z powodu pamięci cache i tak zostaną te same problemy.
>
> Cache akurat nie ma tutaj znaczenia.
>
> > Wątek odczytujący może otrzymać zmienna_globalna z opóźnieniem. Czyli
> > wątek zapisujący i tak musi zrobić powolną operację zrzutu
> > zmodyfikowanych danych. Nie lepiej od razu użyć sekcji krytycznej
> > i mieć prostszy kod w analizie, nie wspominając o możliwości
> > kompilacji na inne procesory, albo o uruchamianiu na klastrze.
>
> Sekcje krytyczne, w sensie mutexy, czy semafory, jako obiekty systemowe
> są wolne, a nawet bardzo wolne. Dlatego tam gdzie liczy się wydajność
> pojawiają się algorytmy lockfree, czyli nie ma jako takiej blokady na
> sekwencję instrukcji, ale np. próbuje się do skutku wykonać jakąś
> operację, powiedzmy dopisania do kolejki. I tu już można to robić
> wydajnie właśnie operacjami atomowymi (głównie compare & exchange)
> no i trzeba pamiętać o barierach pamięci (memory fence).

Myślałem że memory fence też jest wolne, ale jeszcze nigdy na oczy
nie widziałem pomiarów czasu. Może faktycznie to się opłaca...

Pozdrawiam