Understanding std:: atomic:: compare exchange weak() in C++11

Po co robić exchange w pętli?

Zazwyczaj chcesz, aby Twoja praca została wykonana, zanim ruszysz dalej, dlatego umieszczasz compare_exchange_weak W pętli, aby próbowała się wymienić, dopóki się nie powiedzie(tzn. zwraca true).

Zauważ, że również compare_exchange_strong jest często używane w pętli. Nie ulega awarii z powodu fałszywej awarii, ale nie ulega awarii z powodu jednoczesnych zapisów.

Dlaczego używać weak zamiast strong?

Całkiem proste: fałszywa porażka nie zdarza się często, więc nie jest to duża wydajność hit. W constraście tolerowanie takiej awarii pozwala na znacznie wydajniejszą implementację wersji weak (w porównaniu do strong) na niektórych platformach: strong musi zawsze sprawdzać pod kątem fałszywej awarii i maskować ją. To jest drogie.

Tak więc, weak jest używany, ponieważ jest o wiele szybszy niż strong na niektórych platformach

Kiedy należy stosować weak i kiedy strong?

Odniesienie wskazuje, kiedy używać weak i kiedy używać strong:

Gdy compare-and-exchange jest w pętli, słaba wersja uzyska lepsza wydajność na niektórych platformach. Gdy słabe porównanie i wymiana wymagałaby pętli, a mocna nie, mocna jest lepiej.

Więc odpowiedź wydaje się być dość prosta do zapamiętania: jeśli musisz wprowadzić pętlę tylko z powodu fałszywej awarii, nie rób tego; użyj strong. Jeśli i tak masz pętlę, użyj weak.

Dlaczego !expected w przykład

To zależy od sytuacji i jej pożądanej semantyki, ale zwykle nie jest potrzebne do poprawności. Pominięcie tego daje bardzo podobną semantykę. Tylko w przypadku, gdy inny wątek może zresetować wartość false, semantyka może się nieco różnić (ale nie mogę znaleźć sensownego przykładu, w którym byś tego chciał). Zobacz komentarz Tony ' ego D., Aby uzyskać szczegółowe wyjaśnienie.

Jest to po prostu szybka ścieżka, gdy inny wątek pisze true: wtedy przerywamy zamiast próbować pisać true ponownie.

O Twoim ostatnim pytaniu

Ale jak przeanalizowano powyżej, dwie wersje w pętli powinny dawać tę samą / podobną wydajność. Czego mi brakuje?

From Wikipedia :

Rzeczywiste implementacje LL / SC nie zawsze się udają, jeśli nie ma równoczesne aktualizacje danych lokalizacji pamięci. Wszelkie wyjątkowe zdarzenia pomiędzy obiema operacjami, takie jak kontekst switch, another load-link, a nawet (na wielu platformach) inny load lub store działanie, spowoduje, że sklep-warunkowe do gwałtownej awarii. Starsze implementacje nie powiodą się, jeśli pojawią się jakiekolwiek aktualizacje transmitowane przez szyna pamięci.

Tak więc LL / SC zawiedzie na przykład przy przełączniku kontekstowym. Teraz mocna wersja wprowadzi swoją "własną małą pętlę", aby wykryć fałszywą awarię i zamaskować ją, próbując ponownie. Zauważ, że ta własna pętla jest również bardziej skomplikowana niż Zwykle pętla CAS, ponieważ musi odróżniać fałszywą awarię (i maskować ją) i awarię z powodu współbieżnego dostępu (co skutkuje zwrotem o wartości false). Słaba wersja nie ma takiej pętli.

Ponieważ podajesz jawną pętlę w obu przykładach, po prostu nie jest konieczne posiadanie małej pętli dla wersji strong. W związku z tym w przykładzie z wersją strong sprawdzanie błędu jest wykonywane dwa razy; raz przez compare_exchange_strong (co jest bardziej skomplikowane, ponieważ musi odróżnić fałszywych awarii i współbieżne acces) i raz przez pętli. Ten kosztowny czek jest niepotrzebny i powód, dla którego weak będzie tutaj szybszy.

Zauważ również, że twój argument (LL / SC) jest tylko jedną możliwością zaimplementowania tego. Jest więcej platform, które mają nawet różne zestawy instrukcji. Ponadto (i co ważniejsze), zauważ, że {[24] } musi obsługiwać wszystkie operacje dla wszystkich możliwych typów danych , więc nawet jeśli zadeklarujesz dziesięć milionów bajtów struct, możesz użyć compare_exchange na tym. Nawet jeśli na procesorze, który ma CAS, nie możesz CAS dziesięć milionów bajtów, więc kompilator wygeneruje inne instrukcje (prawdopodobnie lock acquire, następnie non-atomic compare and swap, a następnie lock release). Pomyśl, ile rzeczy może się wydarzyć podczas wymiany 10 milionów bajtów. Tak więc, podczas gdy fałszywy błąd może być bardzo rzadki w przypadku wymiany 8 bajtów, może być bardziej powszechny w tym przypadku.

Więc w skrócie, C++ daje dwie semantyki, a "najlepszy wysiłek" jeden (weak) i " zrobię to na pewno, bez względu na to, jak wiele złych rzeczy może się wydarzyć inbetween "jeden (strong). To, w jaki sposób są one wdrażane na różnych typach danych i platformach, to zupełnie inny temat. Nie przywiązuj swojego modelu mentalnego do implementacji na konkretnej platformie; biblioteka standardowa jest zaprojektowana do pracy z większą liczbą architektur, niż możesz być świadomy. Jedynym ogólnym wnioskiem, jaki możemy wyciągnąć jest to, że zagwarantowanie sukcesu jest zwykle trudniejsze (a więc może wymagają dodatkowej pracy) niż tylko próby i pozostawienie miejsca na ewentualną porażkę.

Dlaczego musi być w pętli w prawie wszystkich zastosowaniach ?

Ponieważ jeśli nie zapętlisz pętli i zawiedzie, Twój program nie zrobił nic użytecznego - nie zaktualizowałeś obiektu atomowego i nie wiesz, jaka jest jego aktualna wartość (poprawka: patrz komentarz poniżej od Camerona). Jeśli połączenie nie robi nic pożytecznego, jaki jest sens tego robić?

Czy to oznacza, że będziemy pętli, gdy zawiedzie z powodu fałszywych porażki?

Jeśli tak jest, to po co nam używanie compare_exchange_weak() i pisanie pętli sami? Możemy po prostu użyć funkcji compare_exchange_strong (), która moim zdaniem powinna pozbyć się fałszywych błędów. Jakie są typowe przypadki użycia compare_exchange_weak ()?

Na niektórych architekturach compare_exchange_weak jest bardziej wydajny, a fałszywe błędy powinny być dość rzadkie, więc może być możliwe pisanie bardziej wydajnych algorytmów przy użyciu słabej formy i pętla.

Ogólnie rzecz biorąc, prawdopodobnie lepiej jest użyć wersji silnej, jeśli algorytm nie wymaga pętli, ponieważ nie musisz się martwić o fałszywe błędy. Jeśli i tak musi zapętlić nawet dla wersji silnej (a wiele algorytmów i tak musi zapętlić), użycie słabej formy może być bardziej efektywne na niektórych platformach.

Dlaczego {[2] } jest w stanie pętli?

Wartość mogła zostać ustawiona na true przez inny wątek, więc nie chcesz zapętlać, próbując to ustawić.

Edit:

Ale jak przeanalizowano powyżej, dwie wersje w pętli powinny dawać tę samą / podobną wydajność. Czego mi brakuje?

Z pewnością jest oczywiste, że na platformach, na których możliwa jest fałszywa awaria, implementacja compare_exchange_strong musi być bardziej skomplikowana, aby sprawdzić fałszywą awarię i spróbować ponownie.

Słaba forma po prostu powraca po fałszywej porażce, nie próbuje ponownie.

W porządku, więc potrzebuję funkcji, która wykonuje atomowe przesunięcie w lewo. Mój procesor nie ma do tego natywnej operacji, a biblioteka standardowa nie ma do tego funkcji, więc wygląda na to, że piszę własną. Idzie:

void atomicLeftShift(std::atomic<int>* var, int shiftBy)
{
    do {
        int oldVal = std::atomic_load(var);
        int newVal = oldVal << shiftBy;
    } while(!std::compare_exchange_weak(oldVal, newVal));
}

Są dwa powody, dla których pętla może być wykonywana więcej niż raz.

1. ktoś inny zmienił zmienną, kiedy robiłem lewy shift. Wyniki moich obliczeń nie powinny być stosowane do zmiennej atomowej, ponieważ skutecznie wymazać czyjś zapis.
[6]] mój procesor odbił się i słaby CAS gwałtownie zawiódł.

To, co jest mniej szybko, to dodatkowy kod, który silny CAS musi owijać wokół słabego CAS, aby być silnym. Ten kod nie robi wiele, gdy słaby CAS się powiedzie... ale kiedy się nie powiedzie, silny CAS musi zrobić kilka praca detektywistyczna w celu ustalenia, czy był to przypadek 1, Czy 2. Ta praca detektywistyczna przybiera formę drugiej pętli, w zasadzie wewnątrz mojej własnej pętli. Dwie zagnieżdżone pętle. Wyobraź sobie, że twój nauczyciel algorytmów patrzy na ciebie teraz.

Innymi słowy, słaby CAS jest używany do implementacji operacji atomic update. Strong CAS jest używany, gdy zależy ci na wyniku CAS.