Historia pytania. Przed C++20 stosowanie operacji atomowych do istniejących obiektów nieatomowych wymagało uciążliwych obejść, ponieważ std::atomic wymaga, aby obiekty były konstruowane jako atomowe od samego początku. Programiści często podejmowali ryzykowne operacje reinterpret_cast, aby traktować zwykłe obiekty jako atomowe, naruszając zasady ściśle związane z aliasingiem i wywołując nieokreślone zachowanie z powodu niezgodności czasów życia obiektów. Wprowadzenie std::atomic_ref w C++20 wypełniło tę lukę, oferując nieposiadający własności widok, który tymczasowo nadaje semantykę atomową istniejącym obiektom bez zmiany ich typu przechowywania lub czasu życia.
Problem. std::atomic narzuca określone wymagania dotyczące reprezentacji — takie jak bitflagii bez blokady lub wewnętrzne mutexy — które zazwyczaj zmieniają rozmiar lub wyrównanie obiektu w porównaniu do typu podstawowego T. W związku z tym obiekt typu int nie jest kompatybilny z układem std::atomic<int>, co uniemożliwia stosowanie wskaźników. Ponadto, std::atomic_ref wymaga, aby obiekt, do którego się odwołuje, spełniał rygorystyczne ograniczenia dotyczące wyrównania; w szczególności adres obiektu musi być wyrównany co najmniej do alignof(std::atomic_ref<T>), co dla wielu platform jest równe alignof(T), ale może być większe dla sprzętowych instrukcji atomowych. Naruszenie tego wstępnego warunku wyrównania prowadzi do nieokreślonego zachowania, które może objawić się jako zniekształcone odczyty lub wyjątki sprzętowe na rygorystycznych architekturach, takich jak ARM.
Rozwiązanie. std::atomic_ref działa jako lekki wrapper trzymający wskaźnik do docelowego obiektu, stosując intrinsics kompilatora lub instrukcje sprzętowe, aby wymusić atomowość, nie zakładając, że przechowywanie jest instancją std::atomic. Szanuje czas życia istniejącego obiektu, jednocześnie zapewniając te same gwarancje porządkowania pamięci co std::atomic na czas każdej operacji. Aby użyć go w sposób bezpieczny, programiści muszą zapewnić odpowiednie wyrównanie obiektu, najczęściej za pomocą specyfikatorów alignas lub weryfikując, czy std::atomic_ref<T>::required_alignment jest spełnione, co umożliwia bezblokowy dostęp do danych już istniejących lub zgodnych z C.
#include <atomic> #include <cstdint> #include <iostream> struct alignas(alignof(std::atomic_ref<std::uint64_t>)) Data { std::uint64_t value; }; int main() { Data d{42}; std::atomic_ref<std::uint64_t> ref(d.value); ref.fetch_add(8, std::memory_order_relaxed); std::cout << d.value << " "; // Wynik: 50 }
Opis problemu. W zastosowaniu do handlu o wysokiej częstotliwości, starożytna struktura C zdefiniowała układ pakietu danych rynkowych, zawierającą pole ceny typu double, które wymagało atomowych aktualizacji z wątku z sieci, podczas gdy wątek strategii je odczytywał. Giełda wymagała dokładnej zgodności binarnej, co uniemożliwiło modyfikację struktury w celu użycia std::atomic<double>, a wymagania dotyczące opóźnienia zabraniały blokad mutexów lub kopiowania pamięci. Mieliśmy do czynienia z wyścigiem danych, gdzie częściowe zapisy do double (nieatomowy na x86-64 bez odpowiedniego wyrównania) powodowały, że wątek strategii odczytywał uszkodzone wartości „duchów” podczas skoków dużej zmienności.
Różne rozważane rozwiązania. Pierwsze podejście opierało się na podwójnym buforowaniu z flagami std::atomic<bool>, utrzymując dwie kopie struktury i atomowo przełączając wskaźnik. Chociaż bezblokowe, podwajało to zużycie pamięci i wprowadzało bounce między liniami pamięci NUMA, pogarszając wydajność o około 15% w mikrobencmarkach. Drugie podejście rozważało użycie std::memcpy do lokalnej zmiennej std::atomic<double>, ale to naruszało wymagania w czasie rzeczywistym z powodu dodatkowego kopowania i nadal cierpiało z powodu zniekształconych odczytów, jeśli memcpy wystąpiło w trakcie aktualizacji. Trzecie rozwiązanie wykorzystywało std::atomic_ref, aby bezpośrednio odwołać się do pola ceny w strukturze C, wykorzystując sprzętowe instrukcje CAS (Compare-And-Swap) bez zmiany układu struktury.
Które rozwiązanie zostało wybrane i dlaczego. Wybraliśmy std::atomic_ref, ponieważ zapewnia prawdziwą abstrakcję bez kosztów: wygenerowany kod assemblera na x86-64 był identyczny z ręcznie napisanymi instrukcjami lock cmpxchg, bez dodatkowych alokacji lub pośrednictwa. W przeciwieństwie do podejścia z podwójnym buforowaniem, utrzymywało jednolity dostęp w linii cache dla gorących danych, zachowując lokalność cache L1, co jest kluczowe dla opóźnienia na poziomie mikrosekund. Kluczowo szanowało to ograniczenia ABI zewnętrznej biblioteki C, jednocześnie eliminując wyścigi danych dzięki sprzętowej wymuszonej atomowości.
Wynik. Po wdrożeniu system osiągnął spójne, bezblokowe aktualizacje z latencją poniżej mikrosekundy, eliminując anomalie wartości duchów weryfikowane za pomocą uruchomień ThreadSanitizer. Weryfikacja wyrównania (alignas) zapewniła przenośność na serwery ARM64 bez zmian w kodzie, a wydajność poprawiła się o 12% w porównaniu z podstawą podwójnego buforowania dzięki zmniejszeniu nacisku na pamięć cache.
Dlaczego rzutowanie wskaźnika nieatomowego na std::atomic<T>* wywołuje nieokreślone zachowanie, podczas gdy std::atomic_ref jest bezpieczny?
Rzutowanie za pomocą reinterpret_cast tworzy wskaźnik do obiektu typu std::atomic<T>, ale przechowywanie faktycznie zawiera obiekt typu T. Narusza to zasady ściśle związane z aliasingiem modelu obiektowego C++ oraz wymagania dotyczące czasu życia, ponieważ std::atomic<T> może mieć inny rozmiar, wyrównanie lub wewnętrzny stan (np. spinlock) niż T. std::atomic_ref jest zaprojektowane jako odrębny typ odniesienia, który wyraźnie odnosi się do obiektu T i stosuje operacje atomowe na nim za pomocą specyficznych dla implementacji intrinsics, nie udając, że przechowywanie jest innego typu, co pozwala zachować oryginalny czas życia i układ obiektu.
Czy std::atomic_ref synchronizuje się z konstrukcją obiektu, do którego się odwołuje?
Nie. std::atomic_ref zapewnia atomowość tylko dla operacji wykonywanych przez niego, ale nie ustanawia relacji ważności z konstruktorem wskazywanego obiektu. Jeśli Wątek A konstruuje obiekt, a Wątek B natychmiast tworzy std::atomic_ref do niego, Wątek B może zobaczyć niezainicjowaną pamięć, chyba że Wątek A wykonał operację zwolnienia (np. zapis do std::atomic<bool>) oraz Wątek B wykonał operację przechwytywania przed dostępem do atomic_ref. Sam atomic_ref zakłada, że obiekt jest już żywy i dostępny, ale współbieżne nieatomowe zapisy podczas konstrukcji pozostają wyścigami danych bez zewnętrznej synchronizacji.
Czy std::atomic_ref może być używane z obiektami const, a jakie są ograniczenia?
Tak, std::atomic_ref<const T> jest ważne i pozwala na atomowe operacje odczytu (takie jak load) na obiektach zadeklarowanych jako const, pod warunkiem, że obiekt nie został pierwotnie zadeklarowany jako const w sposób, który umożliwia optymalizacje kompilatora do buforowania wartości w rejestrach. Jednak nie można skonstruować std::atomic_ref<T> (nie-stałego) z const T&, ponieważ naruszałoby to poprawność const. Dodatkowo, nawet z atomic_ref<const T>, leżący u podstaw obiekt nie może znajdować się w pamięci tylko do odczytu (np. sekcja .rodata), ponieważ sprzętowe instrukcje atomowe wymagają zapisujących linii pamięci cache nawet dla operacji odczytu na większości architektur.