Ochrona głównego wątku przed błędami w wątku roboczym

Question

Podczas korzystania z wątków POSIX, istnieje sposób "ochrony" głównego wątku przed błędami (takimi jak dereferencje wskaźników zerowych, dzielenie przez zero itd.) Spowodowanych przez wątki robocze. Przez "wątek roboczy" mam na myśli wątek posix stworzony przez pthread_create().

Niestety, nie możemy używać wyjątków - tak nie "złapać", itp

Tu jest mój program testowy (C++):

void* workerThreadFunc(void* threadId) { 
    int* a = NULL; 
    *a = 5; //Error (segmentation fault) 
    pthread_exit(NULL); 
} 

int main() { 
    cout << "Main thread start" << endl; 

    pthread_t workerThread; 
    pthread_attr_t attr; 
    pthread_attr_init(&attr); 
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_JOINABLE); 
    pthread_create(&workerThread, &attr, workerThreadFunc, (void*)0); 
    pthread_join(workerThread, NULL); 

    cout << "Main thread end" << endl; 
} 

W powyższym przykładzie, błąd spowodowany przez workerThread będzie zakończyć cały program. Ale chciałbym, aby główny wątek nadal działał pomimo tego błędu. Czy można to osiągnąć?

Answer 1

Brzmi dla mnie tak, jakbyś używał wielu procesów, a nie wątków. Niezależne procesy są automatycznie chronione przed tego rodzaju błędami występującymi w innych procesach.

Możesz używać potoków lub pamięci współdzielonej (lub innych form IPC) do przekazywania danych między wątkami, co ma dodatkową zaletę polegającą na dzieleniu się tylko pamięcią, którą chcesz udostępnić, więc błąd w wątku roboczym nie może przejść na stosie głównego "wątku", ponieważ jest to oddzielny proces z oddzielną przestrzenią adresową.

Nici mogą się przydać, ale mają kilka wad, czasem bardziej odpowiednie są oddzielne procesy.

Answer 2

Zakładając, że system wykorzystuje sygnały w POSIX rodzaju sposób (choć, które mogą podlegać regule „nie wyjątki”), a następnie POSIX mówi:

W czasie generowania, determinacja powinna być wykonane, czy sygnał został wygenerowany dla procesu, czy dla określonego wątku w procesie. Sygnały generowane przez niektóre działania przypisane do określonego wątku, takie jak błąd sprzętowy, są generowane dla wątku, który spowodował wygenerowanie sygnału.

Więc można obsługiwać SIGSEGV, SIGFPE, itp na podstawie jednej Pthread (należy jednak pamiętać, że można ustawić tylko jedną funkcję obsługi sygnału dla całego procesu). Możesz więc "ochronić" proces przed zatrzymaniem martwym przez niepowodzenie pojedynczego pthread ... do pewnego momentu. Problem polega oczywiście na tym, że bardzo trudno jest stwierdzić, w jakim stanie znajduje się proces - niepowodzenie pthread i wszystkie inne pthready. Uszkodzony pthread może posiadać pewną liczbę muteksów. Nie powiodło się, że pthread może pozostawić pewne struktury danych w bałaganie. Kto wie, w jakie gąszczu rzeczy się znajdują - chyba że pthreads są zasadniczo niezależne. Możliwe, że inne pthready zamkną się "z gracją", zamiast rozbić się i spalić. W ostatecznym rozrachunku może być bezpieczniej zatrzymać wszystkie pthready, niż próbować kontynuować w stanie mniejszym niż dobrze zdefiniowany. Będzie to zależeć wyłącznie od natury aplikacji.

Nic nie jest na nic ... nici mogą komunikować się ze sobą łatwiej niż z procesami, a koszt ich uruchamiania jest krótszy - procesy są mniej podatne na awarię innych procesów.

Answer 3

Jedynym sposobem mogę myśleć w ten sposób rejestruje obsługi sygnału, który mógłby zamiast przerywać działanie programu, należy anulować aktualnie uruchomiony wątek, coś takiego:

void handler(int sig) 
{ 
    pthread_exit(NULL); 
} 

signal(SIGSEGV, handler); 

Note, jednak jest to niebezpieczne jak pthread_exit nie jest wymienione jako jedno z bezpiecznych wywołań systemowych wewnątrz procedury obsługi sygnału. To może zadziałać i może nie, w zależności od O/S, z którego korzystasz, i od tego, jaki sygnał sobie poradzisz.