On Monday, April 13, 2015 at 8:27:29 PM UTC+2, Wojciech Muła wrote:
> 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.

Czyli przyspieszenie niezbyt duże. Blokady są koszmarnie wolne, dwukrotnie
przyspieszenie to za mało dla wielu praktycznych zastosowań. Z kolei
jeśli dzielimy zadania na bardzo duże porcje, to nawet 10cio krotne
przyspieszenie mechanizmu synchronizacji nie przyniesie mierzalnego
przyspieszenia całego programu.

Ciekawym rozwiązaniem, jak pisałeś, wydają się klasy obudowujące inta w
bibliotece qt czy std. Jest też klasa atomic pointer. Jeszcze nigdy nie używałem tych
klas, trudno mi się wypowiedzieć o ich przydatności i
wydajności. Najbardziej ciekawe jest jednak, jak się mają możliwości tych
klas do spotykanych problemów w praktyce. Może warto im się przyjrzeć.

Pozdrawiam