C11 płot pamięć Wykorzystanie

Question

Nawet na prosty 2-wątku przykład komunikacji, mam trudność wyrazić to w C11 atomowej i memory_fence stylu w celu uzyskania odpowiedniej pamięci Kolejność:

wspólne dane:

volatile int flag, bucket; 

wątek

producent:

while (true) { 
    int value = producer_work(); 
    while (atomic_load_explicit(&flag, memory_order_acquire)) 
     ; // busy wait 
    bucket = value; 
    atomic_store_explicit(&flag, 1, memory_order_release); 
} 

konsument thre ad:

while (true) { 
    while (!atomic_load_explicit(&flag, memory_order_acquire)) 
     ; // busy wait 
    int data = bucket; 
    atomic_thread_fence(/* memory_order ??? */); 
    atomic_store_explicit(&flag, 0, memory_order_release); 
    consumer_work(data); 
} 

O ile mi zrozumieć, że powyższy kod poprawnie zamówić sklep-w-wiaderku -> flag-sklep -> Flaga obciążenia -> load-z-wiadra. Uważam jednak, że nadal istnieje warunek wyścigowy między ładowaniem z zasobnika i ponownym zapisywaniem wiadra z nowymi danymi. Aby wymusić zamówienie po przeczytaniu wiadra, domyślam się, że potrzebuję jawnego atomic_thread_fence() między odczytem wiadra i następującą stacją atomową. Niestety, wydaje się, że nie ma argumentu, aby wymusić cokolwiek na poprzednich ładunkach, nawet na memory_order_seq_cst.

Naprawdę zabrudzonym rozwiązaniem może być ponowne przypisanie bucket w wątku konsumenckim z fałszywą wartością: jest to sprzeczne z pojęciem "tylko do odczytu".

W starszym C99/GCC świecie mógłbym użyć tradycyjnego __sync_synchronize(), który moim zdaniem byłby wystarczająco silny.

Jakie byłoby ładniejsze rozwiązanie w stylu C11 do synchronizowania tej tak zwanej anty-zależności?

(Oczywiście zdaję sobie sprawę, że powinienem lepiej unikać takiego kodowanie niskopoziomowe i wykorzystywać dostępne konstrukcje wyższego poziomu, ale chciałbym zrozumieć ...)

Answer 1

Aby wymusić zamówienie po przeczytaniu zasobnika, domyślam się, że potrzebowałbym jawnej wartości atrybutu atomic_thread_fence() między odczytanym zbiornikiem a następującym plikiem atomowym.

Nie wierzę wywołanie atomic_thread_fence() jest konieczne: aktualizacja flaga ma semantykę uwalnianiu, zapobieganie wszelkim poprzednich obciążeń lub sklepu operacji przed kolejność poprzek. Zobacz formalnej definicji przez Herb Sutter:

Odpisy uwalnianiu wykonuje przecież czyta i pisze przez tego samego wątku, które poprzedzają je w celu programu.

To powinno zapobiec lektury bucket przed kolejność wystąpić po aktualizacji flag, niezależnie od tego, gdzie kompilator zdecyduje się zapisać data.

To prowadzi mnie do komentarz o innej odpowiedzi:

volatile zapewnia, że ​​nie są ld/st generowane operacje, które mogą być następnie zamówić z ogrodzenia. Dane są jednak zmienną lokalną, a nie zmienną. Prawdopodobnie kompilator umieści go w rejestrze, unikając operacji przechowywania. To pozostawia ładunek z kubła, który ma zostać zamówiony, z późniejszym resetem flagi.

Wydaje się, że nie jest to problem, jeśli odczyt bucket nie mogą zostać zreorganizowane obok zapisu uwalnianiu flag, więc volatile nie powinno być konieczne (choć prawdopodobnie nie zaszkodzi go mieć, albo). Jest to również niepotrzebne, ponieważ większość wywołań funkcji (w tym przypadku atomic_store_explicit(&flag)) służy jako bariery pamięci podczas kompilacji. Kompilator nie zmienia kolejności odczytu zmiennej globalnej poza nieliniowym wywołaniem funkcji, ponieważ ta funkcja może modyfikować tę samą zmienną.

Zgadzam się również z @MaximYegorushkin, że możesz poprawić swoje intensywne czekanie z instrukcjami pause podczas kierowania na kompatybilne architektury. GCC i ICC wydają się mieć wewnętrzne właściwości _mm_pause(void) (prawdopodobnie równoważne __asm__ ("pause;")).

Answer 2

zgadzam się z tym, co mówi w @MikeStrobel jego komentarz.

Nie potrzebujesz tutaj atomic_thread_fence(), ponieważ sekcje krytyczne zaczynają się od nabycia i kończą semantyką wydania. W związku z tym, odczytów w kluczowych sekcjach nie można zmienić przed nabyciem i pisze po wydaniu. I dlatego tutaj również niepotrzebne jest volatile.

Ponadto nie widzę powodu, dla którego zamiast tego użyty został spinlock (pthread). Spinlock robi podobną zajęty zawrót dla Ciebie, ale również wykorzystuje pause instruction:

Pauza wewnętrzna służy w spin-czekać pętle z procesorami wykonawczych dynamiczne wykonanie (zrealizowanie szczególnie out-of-order). W pętli spin-wait, przerwa wewnętrzna poprawia szybkość, z jaką kod wykrywa zwolnienie blokady i zapewnia szczególnie znaczny wzrost wydajności. Wykonanie następnej instrukcji jest opóźnione o określoną ilość czasu. Instrukcja PAUSE nie modyfikuje stanu architektonicznego. W przypadku dynamicznego planowania instrukcja PAUSE zmniejsza karę wyjścia z pętli spinów.

Answer 3

odpowiedź Direct:

że sklep jest operacja memory_order_release oznacza, że ​​kompilator musi emitować ogrodzenie pamięci do przechowywania instrukcji przed sklepie flagi.Jest to wymagane, aby zapewnić, że inne procesory widzą ostateczny stan opublikowanych danych, zanim zaczną je interpretować. Nie, nie musisz dodawać drugiego ogrodzenia.

---

odpowiedź Long:

Jak wspomniano powyżej, co się dzieje, jest to, że kompilator przekształca swoje instrukcje atomic_... w kombinacji ogrodzeń i uzyskuje dostęp do pamięci; podstawową abstrakcją nie jest ładunek atomowy, to płot pamięci. Tak to działa, mimo że nowe abstrakcje w C++ zachęcają do myślenia inaczej. Osobiście uważam, że znacznie łatwiej jest myśleć o płotach pamięciowych niż o pokrzywdzonych abstrakcjach w C++.

Z punktu widzenia sprzętu, co musisz zapewnić, jest względne zamówienie Twoich ładunków i zapasów, i. mi. że zapis do zasobnika kończy się, zanim flaga zostanie zapisana w producencie, a obciążenie flagi odczytuje wartość starszą niż ładunek wiadra w konsumentach.

Mimo to, czego faktycznie potrzebujesz to:

//producer 
while(true) { 
    int value = producer_work(); 
    while (flag) ; // busy wait 
    atomic_thread_fence(memory_order_acquire); //ensure that value is not assigned to bucket before the flag is lowered 
    bucket = value; 
    atomic_thread_fence(memory_order_release); //ensure bucket is written before flag is 
    flag = true; 
} 

//consumer 
while(true) { 
    while(!flag) ; // busy wait 
    atomic_thread_fence(memory_order_acquire); //ensure the value read from bucket is not older than the last value read from flag 
    int data = bucket; 
    atomic_thread_fence(memory_order_release); //ensure data is loaded from bucket before the flag is lowered again 
    flag = false; 
    consumer_work(data); 
} 

Uwaga, że ​​etykiety „producent” i „konsument” są mylące tutaj, bo mamy dwa procesy gra ping-pong, każdy producent staje i konsument z kolei; to tylko jeden wątek wytwarza użyteczne wartości, podczas gdy drugi wytwarza "dziury", aby zapisać przydatne wartości w ...

atomic_thread_fence() to wszystko, czego potrzebujesz, a ponieważ jest to bezpośrednio przekłada się na instrukcje asemblera poniżej abstrakcji atomic_..., to gwarantowane najszybsze podejście.