On Thursday, April 9, 2015 at 6:45:16 PM UTC+2, M.M. wrote:
> > 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,

No to do tego jest bariera pamięci.

> 2) czy inny wątek może zobaczyć zmienną zmodyfikowana 'w połowie'.

A od tego mamy gwarancje spójności od producenta. :)

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

Oczywiście, o to trzeba zadbać. C++11 ma std::atomic, które daje ładne
API do atomiców, barier itp., natomiast kompilator ma wiedzę, którą
jest w stanie wykorzystać. Nie wiem, jak to wygląda w innych językach
imperatywnych (Ada, C#).

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

Ostatnio kolega wykonał proste testy: prefiks lock na instrukcji
increment (tj. pełna blokada) vs increment, później store fence --
z barierą było 2-3 razy szybciej. Podejrzewam, że to trochę
zależy od całego komputera (kontroler pamięci, liczba procesorów),
ale sądzę, że czynnik 2 jest dobrym przybliżeniem.

w.