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.

> 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. Dodawanie, odejmowanie i operacje
bitowe też mogą być atomowe na x86, ale dla pozostałych rzeczywiście
trzeba mieć jakąś formę sekcji krytycznej.

> 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).

w.