Koncepcja barier pamięci pochodzi z modeli pamięci sprzętowej, gdzie procesory stosują wykonanie poza kolejnością, aby zmaksymalizować przepustowość. Rust's std::sync::atomic::fence udostępnia te niskopoziomowe prymitywy do ustalania ograniczeń porządkowych między operacjami pamięci na różnych lokalizacjach bez modyfikacji danych. W przeciwieństwie do operacji atomowych, które łączą modyfikacje danych z gwarancjami porządku, bariery działają jako bariery synchronizacyjne, które egzekwują zasady widoczności dla wszelkich wcześniejszych lub późniejszych dostępu do pamięci.
Często mylnie przyjmuje się, że użycie Ordering::SeqCst na zmiennej atomowej automatycznie synchronizuje wszystkie wcześniejsze zapisy do niepowiązanych lokalizacji pamięci w różnych wątkach. Jest to błędne, ponieważ SeqCst zapewnia tylko całkowity porządek dla samych operacji atomowych, a nie transytywną relację happens-before dla innych danych. Kiedy Wątek A zapisuje do bufora, a następnie wykonuje zapis Release do atomowej flagi, Wątek B wykonujący odczyt Acquire na tej fladze nie widzi automatycznie zapisów bufora, chyba że bariera lub silniejsze porządki łączą te dwa obszary.
Aby to rozwiązać, fence(Ordering::Release) zapewnia, że wszystkie operacje pamięci, które następują przed nią w kolejności programowej, staną się widoczne dla innych wątków przed jakimkolwiek następnym zapisem atomowym. Z drugiej strony, fence(Ordering::Acquire) gwarantuje, że wszystkie operacje pamięci, które następują po niej, obserwują wartości zapisane przed odpowiadającą barierą Release w innym wątku. Ta parowa synchronizacja tworzy krawędź happens-before w całym stanie pamięci, a nie tylko w zmiennej atomowej, co umożliwia algorytmy bezblokujące, które polegają na oddzielnych kanałach sterujących i danych.
Rozważ procesor pakietów sieciowych bez kopiowania, gdzie jeden wątek wypełnia współdzielony bufor cykliczny danymi pakietowymi i aktualizuje wskaźnik głowy, podczas gdy inny wątek odczytuje ten wskaźnik i przetwarza pakiety. Producent zapisuje bajty pakietów do bufora za pomocą standardowych zapisów (operacji nieatomowych) i następnie atomowo zwiększa indeks głowy, używając Ordering::Release, aby sygnalizować dostępność nowych danych. Konsument czeka na zmianę indeksu, a następnie odczytuje dane pakietów z bufora.
Jedno z potencjalnych rozwiązań polegało na zabezpieczeniu całego bufora i indeksu za pomocą std::sync::Mutex. Choć zapewnia to bezpieczeństwo pamięci i sekwencyjną spójność, wprowadza poważne kontencje; każdy zapis pakietu wymaga uzyskania blokady, co serializuje producenta i niszczy lokalność pamięci podręcznej. Podejście to zmniejszyło przepustowość do nieakceptowalnych poziomów dla wymagań handlu wysokiej częstotliwości, czyniąc je nieodpowiednim dla systemów o niskiej latencji.
Inne rozważane podejście polegało na zastąpieniu pary Release/Acquire operacjami Ordering::SeqCst dla wskaźnika głowy, zakładając, że jego globalny porządek automatycznie zaktualizuje zapisy bufora. To rozwiązań nie zdało egzaminu, ponieważ SeqCst ustala tylko całkowity porządek wśród operacji SeqCst; kompilator i CPU mogą swobodnie przestawiać nieatomowe zapisy bufora po atomowym zapisie. W rezultacie konsument może zauważyć zaktualizowany indeks głowy podczas odczytu przestarzałych danych pakietów, naruszając bezpieczeństwo pamięci pomimo pozornie silnego porządku atomowego.
Wybrane rozwiązanie polegało na wstawieniu fence(Ordering::Release) po zakończeniu wszystkich zapisów do bufora, ale przed zapisaniem zaktualizowanego indeksu głowy po stronie producenta. Wątek konsumenta umieścił fence(Ordering::Acquire) tuż po załadowaniu indeksu głowy i przed dereferencjonowaniem wskaźnika bufora. Ta para zapewnia, że zapisy do bufora są globalnie widoczne przed opublikowaniem aktualizacji indeksu, a konsument nie może spekulatywnie odczytać bufora, aż indeks zostanie zsynchronizowany, eliminując wyścigi danych bez blokad.
Wynik był kolejką SPSC (single-producer-single-consumer) bez blokad zdolną do przetwarzania milionów pakietów na sekundę z mikrosekundową latencją. Benchmarki wykazały dziesięciokrotną poprawę w porównaniu do podejścia opartego na Mutex i zero wyścigów danych w narzędziach sprawdzania współbieżności Miri i Loom. To wykazało, że odpowiednie użycie barier może dorównać wydajności na poziomie sprzętu, jednocześnie zachowując gwarancje bezpieczeństwa Rust.
Dlaczego samodzielne ładowanie Acquire zmiennej atomowej nie gwarantuje widoczności wcześniejszych zapisów nieatomowych?
Samodzielne ładowanie Acquire synchronizuje się tylko z zapisem Release w tej konkretnej lokalizacji atomowej, tworząc relację happens-before ograniczoną do tej zmiennej. Nie rozciąga się na inne lokalizacje pamięci, które były zapisane przez producenta przed zapisaniem. Aby zsynchronizować te zapisy, producent musi użyć bariery Release przed zapisaniem, lub konsument musi użyć bariery Acquire po załadunku. Bez tych bariery kompilator może przestawiać nieatomowe zapisy po atomowym zapisie, a CPU może opóźnić ich widoczność, co prowadzi do wyścigów danych na niepowiązanych danych.
Jak kompilator optymalizuje operacje atomowe Relaxed, i dlaczego może to prowadzić do nieintuicyjnych przestarzałych odczytów na x86_64 pomimo silnego modelu pamięci sprzętowej?
Nawet na x86_64, gdzie sprzęt zapewnia silne porządki, operacje Relaxed gwarantują jedynie atomowość (brak uszkodzonych odczytów/zapisów), lecz nie nakładają żadnych ograniczeń porządkowych na otaczające operacje. Kompilator ma swobodę przestawiania ładowań i zapisów Relaxed z innymi instrukcjami lub trzymania wartości w rejestrach, co powoduje, że wątek może obserwować przestarzałe wartości w odniesieniu do logicznego toku programu. Kandydaci często mylą spójność sprzętową z gwarancjami kompilatora, zapominając, że Relaxed nie zapewnia żadnej ochrony przed optymalizacjami kompilatora, co wymusza semantykę Acquire/Release w celu zapobiegania przestawianiu.
Co odróżnia barierę SeqCst od połączenia barier Acquire i Release, i w jakim konkretnym algorytmicznym wymogu globalne całkowite uporządkowanie SeqCst jest niezbędne?
Bariera SeqCst wymusza globalnie spójny całkowity porządek wszystkich operacji SeqCst wśród wszystkich wątków, zapewniając, że każdy wątek obserwuje tę samą sekwencję tych zdarzeń. W przeciwieństwie do tego, bariery Acquire/Release tylko ustanawiają parową synchronizację pomiędzy konkretnymi wątkami i lokalizacjami pamięci bez globalnej zgody. SeqCst jest niezbędne dla algorytmów wymagających globalnej zgody co do porządku zdarzeń, takich jak algorytm wzajemnego wykluczania Dekker'a lub rozproszone liczniki znaczników, gdzie wiele wątków musi niezależnie dojść do tego samego wniosku co do względnego porządku niepowiązanych operacji; w przypadku prostych scenariuszy producent-konsument, parowa synchronizacja Acquire/Release jest wystarczająca i bardziej wydajna.