Czy std :: atomic kasuje przyrosty z dekrementami?

Korzystanie z , np. dla referencyjnego wskaźnika zliczającego, czy kompilator może zoptymalizować dalszą inkrementację i dekrementację?Czy std :: atomic kasuje przyrosty z dekrementami?

std::atomic_int32_t ai; 
for (size_t i = 0; i < 10000; i++) 
{ 
    ai.fetch_add(1, std::memory_order_relaxed); 
    ai.fetch_sub(1, std::memory_order_relaxed); 
}

Patrząc na demontaż nie wygląda. Ale ponieważ zmiana kolejności jest dozwolona i atomic zachowuje się jak licznik, po prostu wątek bezpieczny, można argumentować, że mógłby zoptymalizować tak, jakby był zwykłym int.

Źródło

2016-08-04 Borph

Nie masz już odpowiedzi, jeśli zauważysz, że nie została ona zoptymalizowana? – rustyx

@rustyx: Tak to nie działa. To, że wdrożenie OP nie optymalizowało go w tym czasie, nie oznacza, że taka optymalizacja jest zabroniona. –

Próbowałem odpowiedzieć na to pytanie, ale nie znam się dobrze na terminologii z § 29.3. Czekamy na odpowiedź! –

-3

Kompilator nie może zoptymalizować atomów na odległość, ponieważ mogłoby to naruszyć ich zawartość. Musi przyjąć, że inny wątek może dotknąć wartości również dlatego usunięcie nie jest dozwolone.

nie może również zoptymalizować/zmienić kolejności rzeczy, które są "widoczne" dla kodu C++ przed i po nim (i na odwrót), ponieważ atomy są barierami pamięci.

Źródło

2016-08-04 12:09:45 oreubens

Nie, mylisz je z 'volatile'. Te są nieusuwalne. A jeśli chodzi o bariery pamięci, pamiętaj, że te dwie operacje są odwrócone. Oznacza to, że w środku nie ma punktu synchronizacji, w którym inny wątek jest w stanie zobaczyć lub dotknąć wyniku pośredniego.Aby zobaczyć wynik pośredni wątku X w wątku Y, wątek Y musi zostać zsekwencjonowany - po obliczeniu pośredniego w X, ale zsekwencjonowany - przed nadpisaniem w X. – MSalters

Uważam, że można go zoptymalizować, o ile nie stwierdzono jego niestabilności. Powodem jest to, że dla każdego harmonogramu, który przeplata wątek pomiędzy, istnieje ważny harmonogram, który nie. Uważam, że tak też jest w przypadku modelu pamięci DRF-SC.

Nie byłoby tak, jeśli ten wątek czyta coś pośrodku.

Źródło

2016-08-04 12:14:02 Elazar

Zgadzam się. Ponadto, przy swobodnym porządkowaniu pamięci nie ma żadnych gwarancji, kiedy modyfikacja stanie się widoczna dla innych wątków i nie można udowodnić, że nie tylko nie udało się uchwycić momentu pomiędzy dwiema zmianami. Jeśli istniała synchronizacja semantyczna lub inna synchronizacja, to jest inny przypadek. –

@Revolver_Ocelot: Nawet nabycie-wydanie byłoby niewystarczające. Istnieje trywialne planowanie wątków, w którym wszystkie 10.000 inkrementów i 10.000 dekrementów zdarza się w tym wątku, zanim jakikolwiek inny wątek uruchomi pojedynczą instrukcję. (To nawet realistyczne planowanie wątków na jednordzeniowym procesorze) – MSalters

Czy std :: atomic kasuje przyrosty z dekrementami?

Odpowiedz

Powiązane problemy