Jak zawiesić inny wątek (nie bieżący)?

Question

Próbuję zaimplementować symulację mikrokontrolera. Ta symulacja nie ma na celu dokładnego odwzorowania jednego taktycznego mikrokontrolera, ale sprawdza ogólną poprawność kodu.

Myślałem o "głównym wątku" wykonującym normalny kod i drugim wątku wykonującym kod ISR. Ilekroć ISR musi zostać uruchomiony, wątek ISR zawiesza "główny wątek".

Oczywiście, chcę mieć funkcję blokowania przerwań. Pomyślałem o rozwiązaniu tego przy pomocy muteksu, który wątek ISR zawiera za każdym razem, gdy wykonuje kod ISR, podczas gdy główny wątek utrzymuje go tak długo, jak "przerywane są zablokowane".

POR (power on reset) może zostać zaimplementowany nie tylko zawieszając, ale zabijając główny wątek (i uruchamiając nowy wykonujący funkcję POR).

Windows API zapewnia niezbędne funkcje. Ale wydaje się, że niemożliwe jest wykonanie powyższych czynności za pomocą wątków posix (w systemie Linux).

Nie chcę zmieniać rzeczywistego kodu niezależnego od mikrokontrolera sprzętu. Więc wstawianie czegokolwiek w celu sprawdzenia oczekujących przerw jest nieopcją.

Przyjmowanie przerwania w niezbyt dobrze zachowanych punktach jest pożądane, podobnie jak w mikrokontrolerach (chyba że blokujesz przerwania).

Czy istnieje sposób zawieszenia innego wątku na Linuksie? (Debugery muszą jakoś skorzystać z tej opcji.)

Proszę, nie mówcie mi, że to zły pomysł. Wiem, że tak jest w większości przypadków. Ale główny kod nie używa standardowych bibliotek lub lock/mutexes/semaphores.

Answer 1

Jakoś myślę, że wysyłanie drugiego wątku SIGSTOP działa.

Jednak dużo lepiej jest napisać komunikację wątków obejmującą senaogires.mutexes i zmienne globalne.

Widzisz, jeśli zawiesisz drugi wątek w malloc() i zadzwonisz do malloc() -> impasu.

Czy wspomniałem, że wiele standardowych funkcji biblioteki C, nie mówiąc już o innych używanych bibliotekach, wywoła funkcję malloc() za plecami?

EDYTOWANIE:

Hmmm, bez standardowego kodu biblioteki. Być może użyj setjmp/longjump() z obsługi sygnału do symulacji POR i handler sygnału, aby symulować przerwanie.

DO TYCH, KTÓRZY PRZECHOWYWAJĄ POCHODZĄCYCH Z NIEGO: Odpowiedź została zaakceptowana dla zawartości po EDYCJI, która jest scenariuszem, którego nie można użyć w żadnym innym scenariuszu.

Answer 2

Solaris ma wywołanie thr_suspend (3C), które zrobiłoby to, co chcesz. Czy przejście na Solaris jest możliwe?

Poza tym prawdopodobnie będziesz musiał wykonać trochę gimnastyki z muteksami i/lub semaforami. Problem polega na tym, że zawiesisz tylko, gdy sprawdzisz muteks, który prawdopodobnie będzie w dobrze zachowanym punkcie. W zależności od tego, co faktycznie chcesz osiągnąć, może to być teraz pożądane.

Answer 3

Lepiej jest, aby główny wątek wykonywał ISR - ponieważ tak działa prawdziwy kontroler (prawdopodobnie). Po prostu sprawdź to po każdej emulowanej instrukcji, jeśli istnieje zarówno przerwanie w toku, a przerwania są obecnie włączone - jeśli tak, emuluj wywołanie do ISR.

Drugi wątek jest nadal używany - ale po prostu nasłuchuje warunków, które powodują przerwanie, i oznaczyć odpowiednie przerwanie jako oczekujące (aby drugi wątek mógł później odebrać).

Answer 4

Hotspot JAVA VM używa SIGUSR2 do implementacji zawieszenia/wznowienia wątków JAVA na Linuksie.

Procedura oparta na na obsługę sygnału dla SIGUSR2 może być:

Zapewnienie obsługi sygnału dla SIGUSR2 pozwala nitki do żądania blokady (która już została objęta przez wysyłanie sygnału wątku).

Spowoduje to zawieszenie wątku.

Jak tylko zawieszający się wątek zwalnia blokadę, moduł obsługi sygnału może (i będzie?) Uzyskać blokadę. Procedura obsługi sygnału zwolni blokadę natychmiast i opuszcza procedurę obsługi sygnału.

Powtarza wątek.

Prawdopodobnie konieczne będzie wprowadzenie zmiennej sterującej, aby upewnić się, że główny wątek znajduje się w procedurze obsługi sygnału przed rozpoczęciem faktycznego przetwarzania ISR. (Szczegóły zależą od tego, czy funkcja obsługi sygnału jest nazywana synchronicznie lub asynchronicznie.)

Nie wiem, jeśli tak właśnie jest w Java VM, ale myślę, że powyższa procedura robi to, czego potrzebuję .

Answer 5

SIGSTOP nie działa - zawsze zatrzymuje cały proces. Zamiast tego można użyć kilka innych sygnałów, powiedzmy SIGUSR1 do zawieszania i wznawiania SIGUSR2 dla:

// at process start call init_pthread_suspending to install the handlers 
// to suspend a thread use pthread_kill(thread_id, SUSPEND_SIG) 
// to resume a thread use pthread_kill(thread_id, RESUME_SIG) 

#include <signal.h> 

#define RESUME_SIG SIGUSR2 
#define SUSPEND_SIG SIGUSR1 

static sigset_t wait_mask; 
static __thread int suspended; // per-thread flag 

void resume_handler(int sig) 
{ 
    suspended = 0; 
} 

void suspend_handler(int sig) 
{ 
    if (suspended) return; 
    suspended = 1; 
    do sigsuspend(&wait_mask); while (suspended); 
} 

void init_pthread_suspending() 
{ 
    struct sigaction sa; 

    sigfillset(&wait_mask); 
    sigdelset(&wait_mask, SUSPEND_SIG) 
    sigdelset(&wait_mask, RESUME_SIG); 

    sigfillset(&sa.sa_mask); 
    sa.sa_flags = 0; 
    sa.sa_handler = resume_handler; 
    sigaction(RESUME_SIG, &sa, NULL); 

    sa.sa_handler = suspend_handler; 
    sigaction(SUSPEND_SIG, &sa, NULL); 
} 

Jestem bardzo zły z odpowiedziami typu „nie należy zawiesić inny wątek, który jest zły”. Faceci, dlaczego uważasz, że inni to idioci i nie wiedzą, co robią? Wyobraź sobie, że inni również słyszeli o impasie i nadal, w pełnej świadomości, chcą zawiesić inne wątki. Jeśli nie masz prawdziwej odpowiedzi na swoje pytanie, dlaczego marnujesz czas swoich czytelników.

Tak, IMO pthreads to bardzo krótkowzroczne api, hańba dla POSIX.

Answer 6

Rozwiązanie wykorzystujące sygnały pthread_kill (3) i SIGUSR1, SIGUSER2 jest dobrym rozwiązaniem, ale nadal może powodować problem z współbieżnością. Czy istnieje sposób zawieszenia wszystkich wątków (z wyjątkiem wątku głównego) w bezpiecznym miejscu, tj. W czasie zawieszenia wątki nie powinny mieć żadnej blokady lub nie być uruchomione w wywołaniu systemowym?