Ponowne wprowadzanie kodu a Bezpieczeństwo wątku

Ten artykuł mówi:

"funkcja może być reentrantowa, bezpieczna dla wątku, obie lub żadna z nich."

Jest też napisane:

"Funkcje Niecentrujące są niebezpieczne dla wątków".

Oto jakiś pseudo-kod, który jest bezpieczny dla wątków (cóż, jest mnóstwo okazji dla wywołań zwrotnych do tworzenia blokad z powodu inwersji blokowania, ale załóżmy, że dokumentacja zawiera wystarczające informacje dla użytkowników, aby tego uniknąć), ale nie ponownie. Ma to na celu zwiększenie globalny licznik, i wykonać callback:

take_global_lock();
int i = get_global_counter();
do_callback(i);
set_global_counter(i+1);
release_global_lock();

Jeśli wywołanie zwrotne wywoła tę procedurę ponownie, w wyniku innego wywołania zwrotnego, wtedy oba poziomy wywołania zwrotnego otrzymają ten sam parametr (który może być OK, w zależności od API), ale licznik zostanie zwiększony tylko raz (co prawie na pewno nie jest API, które chcesz, więc będzie musiał zostać zablokowany).

Zakładając, że zamek jest rekurencyjny, oczywiście. Jeśli blokada nie jest rekurencyjna, to oczywiście kod nie jest reentrantowy tak czy siak, skoro drugie zajęcie zamka nie zadziała.

Oto jakiś pseudo-kod, który jest "słaby", ale nie bezpieczny dla wątków:

int i = get_global_counter();
do_callback(i);
set_global_counter(get_global_counter()+1);

Teraz można wywołać funkcję z wywołania zwrotnego, ale nie jest bezpiecznie wywoływać funkcję jednocześnie z różnych wątków. Nie jest również bezpieczne wywołanie go z funkcji obsługi sygnału, ponieważ ponowne wejście z funkcji obsługi sygnału może również przerwać liczenie, jeśli sygnał zdarzył się w odpowiednim czasie. Więc kod nie jest re-entrant według właściwej definicji.

Oto kod, który prawdopodobnie jest w pełni re-entrant (chyba, że standard rozróżnia reentrant i 'non-interruptible by signals', i nie jestem pewien, gdzie to spada), ale nadal nie jest bezpieczny dla wątków: {]}

int i = get_global_counter();
do_callback(i);
disable_signals(); // and any other kind of interrupts on your system
set_global_counter(get_global_counter()+1);
restore_signal_state();

W aplikacji jednowątkowej jest to w porządku, zakładając, że system operacyjny obsługuje wyłączanie wszystkiego, co należy wyłączyć. Zapobiega to ponownemu wejściu w punkcie krytycznym. W zależności od tego, w jaki sposób sygnały są wyłączone, może to być bezpieczne wywołanie z obsługi sygnału, chociaż w tym konkretnym przykładzie nadal występuje problem z parametrem przekazanym do wywołania zwrotnego, który jest taki sam dla oddzielnych połączeń. Jednak nadal może pójść źle wielowątkowy.

W praktyce, non-thread-safe często oznacza non-re-entrant, ponieważ (nieformalnie) wszystko, co może pójść nie tak z powodu przerwania wątku przez scheduler, a funkcja wywołana ponownie z innego wątku, może również pójść nie tak, jeśli wątek zostanie przerwany przez sygnał, i funkcja jest wywoływana ponownie z obsługi sygnału. Ale wtedy "fix", aby zapobiec sygnałom (wyłączanie ich) różni się od "fix", aby zapobiec współbieżności (zazwyczaj blokady). To jest w najlepszym razie zasada kciuka.

Zauważ, że sugerowałem tu globale, ale dokładnie te same rozważania miałyby zastosowanie, gdyby funkcja przyjmowała jako parametr wskaźnik do licznika i blokadę. Chodzi o to, że różne przypadki byłyby niebezpieczne lub nieodwracalne po wywołaniu z tym samym parametrem, a nie kiedy w ogóle dzwonisz.