W jaki sposób wielowątkowa aplikacja C radzi sobie z nieudanym malloc()?

Question

Część aplikacji, nad którą pracuję, to prosty serwer oparty na pthread, który komunikuje się przez gniazdo TCP/IP. Piszę to w C, ponieważ będzie działał w środowisku z ograniczoną pamięcią. Moje pytanie brzmi: co powinien zrobić program, jeśli jeden z wątków napotka obiekt malloc(), który zwraca NULL? Możliwości, które do tej pory wymyśliłem:

1. Bez specjalnej obsługi. Niech funkcja malloc() zwróci wartość NULL i pozwoli na jej dereferencję, tak aby cała sprawa uległa uszkodzeniu.
2. Zamknij natychmiast niepowodzenie malloc(), wywołując abort() lub exit (-1). Załóżmy, że środowisko wszystko oczyści.
3. Wyskocz z głównej pętli zdarzeń i spróbuj pthread_join() wszystkich wątków, a następnie zamknij system.

Pierwsza opcja jest oczywiście najłatwiejsza, ale wydaje się bardzo błędna. Drugi również wydaje się błędny, ponieważ nie wiem dokładnie, co się stanie. Trzecia opcja wydaje się kusząca, z wyjątkiem dwóch problemów: po pierwsze, wszystkie wątki nie muszą być łączone z powrotem do głównego wątku w normalnych okolicznościach, a po drugie, aby zakończyć wykonywanie wątku, większość pozostałych wątków będzie musiała wywoływać malloc () jeszcze raz.

Co mam zrobić?

Answer 1

Jest to jeden z powodów, dla których space/rad hard systems generalnie zabrania dynamicznego przydzielania pamięci. Gdy ulegnie awarii, bardzo trudno jest "wyleczyć" awarię. Masz kilka opcji:

• Nie musisz używać wbudowanej biblioteki libc malloc() (w ogóle lub jak zwykle). Możesz wykonać wrap malloc(), aby wykonać dodatkową pracę przy niepowodzeniach, takich jak powiadamianie o czymś innym. Jest to pomocne przy używaniu czegoś takiego jak watchdog. Możesz także użyć full blown garbage collector, ale nie polecam go. Lepiej zidentyfikować i naprawić wycieki.
• W zależności od przestrzeni dyskowej i złożoności rzadko przydzielane bloki alokowane na dysku mogą być mapowane na dysk. Ale tutaj, typowo, patrzysz tylko na kilka KB oszczędności w pamięci fizycznej.
• Możesz użyć statycznej puli pamięci i własnego malloc(), które nie będą go przesadzać. Jeśli profilowałeś swoje użycie sterty w znacznym stopniu (przy użyciu narzędzia takiego jak Valgrind o masie lub podobnej), możesz rozsądnie powiększyć wielkość puli.

Jednak to, co większość z tych sugestii sprowadzają się nie ufa/korzystania z systemu malloc() jeśli awaria nie jest rozwiązaniem.

W twoim przypadku, myślę, że najlepszą rzeczą jaką możesz zrobić, to pewny watchdog notyfikację w przypadku malloc() nie powiedzie się, więc, że proces (lub całego systemu) może być ponownie uruchomiony. Nie chcesz, aby wyglądał "żywy i działający", gdy znajdujesz się w martwym punkcie. Może to być tak proste, jak po prostu odłączenie pliku.

Napisz bardzo szczegółowe logi. Jaki plik/linia/funkcja spowodowała awarię?

Jeśli próba uzyskania zaledwie kilku KB kończy się niepowodzeniem, to jest to dobry znak, że proces nie może być kontynuowany w niezawodny sposób. Jeśli nie uda się zdobyć kilkuset MB, możesz odzyskać i kontynuować. Na podstawie tego żetonu każde działanie, jakie podejmiesz, powinno opierać się na tym, ile pamięci próbujesz uzyskać, i czy połączenia w celu przydzielenia o wiele mniejszego rozmiaru nadal się powiodą.

Jedną z rzeczy, których nigdy nie chcesz robić, jest operowanie wskaźnikami NULL i awarie. Jest po prostu niechlujny, nie dostarcza użytecznych informacji o tym, gdzie coś poszło nie tak i daje wrażenie, że twoje oprogramowanie ma niską/niestabilną jakość.

Answer 2

Nie ma nic złego w opcji 2. Nie musisz zakładać - exit() wychodzi z procesu, co oznacza, że ​​wszystkie wątki są zrywane i wszystko jest czyszczone.

Nie zapomnij spróbuj zarejestrować miejsca, w których nastąpiło niepowodzenie alokacji.

Answer 3

W zależności od Twojej architektury myślę.

Czy błąd w oznaczeniu malloc() oznacza, że ​​tylko ten wątek nie może być kontynuowany lub czy cały proces został przerwany w takiej sytuacji?

Zasadniczo, gdy pamięć jest naprawdę ciasna (tj. Środowiska mikroprocesorowe), dobrym pomysłem jest uniknięcie CAŁKOWITEJ alokacji pamięci dynamicznej, aby uniknąć takich problemów.

Answer 4

Istnieje czwarta opcja: zwolnij trochę pamięci (pamięci podręczne zawsze są dobrymi kandydatami) i spróbuj ponownie.

Jeśli nie możesz sobie na to pozwolić, wybrałbym opcję 2 (rejestrowanie lub drukowanie jakiegoś komunikatu o błędzie, oczywiście) ... Jedynym problemem związanym z czyszczeniem byłaby zamykanie otwartych połączeń sieciowych w uporządkowany sposób, aby klienci wiedzą, że aplikacja po drugiej stronie jest zamykana, zamiast znaleźć nieoczekiwany problem z łącznością.

Answer 5

Z własnego doświadczenia mogę stwierdzić, że częstotliwość błędów malloc jest często zawyżona. Na przykład w Linuksie zwykłe "rozwiązanie" to wariant 2, a nie otrzymujesz błędu malloc. Proces nagle umiera. W większych systemach aplikacja ma tendencję do śmierci, ponieważ użytkownik lub watchdog ją zabija, gdy tylko zamiana sprawi, że przestanie reagować.

To sprawia, że ​​oczyszczanie jest nieco trudniejsze, a także sprawia, że ​​trudno jest znaleźć ogólne rozwiązanie.

Answer 6

Czy to działa w systemie operacyjnym? Sugeruje to użycie pthreadów. Czy wiesz, że nawet malloc() kiedykolwiek zwróci NULL? W niektórych systemach (na przykład Linux) usterka wystąpi w funkcji malloc() i będzie obsługiwana przez system operacyjny (przez zabicie procesu) bez zwracania funkcji malloc().

Proponuję przydzielić pulę pamięci podczas inicjowania aplikacji i przydzielić ją zamiast używać malloc() po inicjalizacji. Zapewni to kontrolę nad algorytmem alokacji pamięci i zachowanie po wyczerpaniu pamięci. Jeśli nie ma wystarczającej ilości pamięci dla puli, wystąpi pojedynczy punkt awarii podczas inicjalizacji, zanim aplikacja będzie miała szansę na rozpoczęcie wszystkiego, czego nie może zakończyć.

W systemach czasu rzeczywistego i systemach wbudowanych często stosuje się 'fixed-block memory allocator'. Jeśli twój system operacyjny nie zapewnia usług, można go zaimplementować poprzez wstępne przydzielanie bloków pamięci i umieszczanie ich wskaźników w kolejce. Aby przydzielić blok, bierzesz wskaźnik z kolejki, a aby go zwolnić, umieść go z powrotem w kolejce. Kiedy kolejka jest pusta, pamięć jest wyczerpana i możesz albo zniszczyć i poradzić sobie z błędem, albo zablokować i poczekać, aż inny wątek zwróci trochę pamięci. Możesz utworzyć wiele pul z blokami o różnych rozmiarach, a nawet utworzyć pulę do określonego celu, blokując dokładny rozmiar potrzebny do tego celu.