Jak wyzwalać fałszywe budzenie w aplikacji systemu Linux?

Question

Niektóre tła:

mam aplikację, która opiera się na sprzęcie firm trzecich i kierowca źródłowego zamkniętym. Sterownik ma obecnie błąd, który powoduje, że urządzenie przestaje odpowiadać po losowym czasie. Jest to spowodowane widocznym zakleszczeniem w sterowniku i przerywa prawidłowe funkcjonowanie mojej aplikacji, która jest zawsze w dobrze widocznym środowisku 24/7.

To, co odkryłem, to dołączenie GDB do procesu i natychmiastowe odłączenie GDB od procesu powoduje wznowienie działania urządzenia. To był mój pierwszy dowód, że w samym sterowniku wystąpił problem z blokowaniem wątków. Jest jakiś rodzaj wyścigu, który prowadzi do impasu. Dołączenie GDB oczywiście spowodowało pewne przetasowanie wątków i prawdopodobnie wypchnięcie ich z ich stanu oczekiwania, powodując ich ponowną ocenę ich warunków i tym samym przerwanie impasu.

Pytanie:

Moje pytanie jest po prostu tak: jest tam czyste czekać na wniosek wyzwolić wszystkie wątki w programie przerwania ich stan oczekiwania? Jedną rzeczą, która na pewno działa (przynajmniej na moim realizacji) jest wysłać SIGSTOP następuje natychmiast przez SIGCONT od innego procesu (tj od bash):

kill -19 `cat /var/run/mypidfile` ; kill -18 `cat /var/run/mypidfile` 

To wywołuje fałszywy wake-up w ramach procesu i wszystko wraca do życia.

Mam nadzieję, że istnieje inteligentna metoda wyzwalania fałszywego przebudzenia wszystkich wątków w ramach mojego procesu. Pomyśl pthread_cond_broadcast(...), ale bez dostępu do aktualnej zmiennej warunkowej, na którą czekano.

Czy to możliwe, czy opiera się na programie takim jak: kill moje jedyne podejście?

Answer 1

Sposób, w jaki to robisz, jest prawdopodobnie najbardziej poprawny i najprostszy. W jądrze nie ma żadnej "wake'owania wszystkich czekających futexów w danej operacji", co jest tym, czego potrzebujesz, aby osiągnąć to bardziej bezpośrednio.

Należy zauważyć, że jeśli nieudany "impas" jest w pthread_cond_wait, ale przerwanie go z sygnałem wyrwa się z zakleszczenia, błąd nie może być w aplikacji; musi to być rzeczywiście implementacja zmiennych warunkowych pthread. glibc zna nieusunięte błędy w swojej implementacji zmiennych warunkowych; zobacz http://sourceware.org/bugzilla/show_bug.cgi?id=13165 i pokrewne raporty o błędach. Mogłeś jednak znaleźć nowy, ponieważ nie wydaje mi się, aby istniejące znane można było naprawić przez wyjście z futex z sygnałem. Jeśli możesz zgłosić ten błąd do śledzenia błędów glibc, byłoby to bardzo pomocne.