UNIX e programmazione multithreading

[shatzy]

Salve a tutti,
vorrei proporvi questo problema: ho scritto un piccolo esempio di processo multitrhead per capire meglio come funziona la gestione dei thread in linux e in particolare dei segnali.

Vi descrivo brevemente a parole cosa fa il programma:
ho una variabile globale "fine" inizializzata a 0 che indica lo stato di terminazione del sistema.
Il main istalla un handler per i segnali SIGINT e SIGTERM (l'handler setta fine a 1).
Subito dopo crea 3 thread, rispettivamente thread1, thread2, thread3 ed entra in un while(!fine) in cui fa una sleep.
Thread1 e thread2 entrano in un while(!fine) nel quale fanno una semplice fprintf.
Thread1 entra nel while(!fine) fa una sleep(10) al termine della quale manda kill(get(pid),SIGINT).

Il comportamento che mi aspetto è questo:
una volta che thread1 manda kill viene generata SIGINT che è indirizzata al processo stesso, quindi arriverà ad un thread a caso(?).
Dunque partirà l'handler che setta fine=1 e tutti i processi possono uscire dal while e terminare. Il main prima di terminare attende le join per i 3 threads.

Il comportamento che ottengo, invece, è che thread1 appena fatta la kill rientra nel while ancora una volta e fa un ultimo ciclo inviando anche un'altra kill.

Il codice è il seguente:

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <pthread.h>
#include <signal.h>
#include <sys/syscall.h>

volatile sig_atomic_t fine = 0;

pthread_t tid1,tid2,tid3;

/* gestore per SIGINT e SIGTERM */
static void handler (int signum) {
int tid;
tid = syscall (SYS_gettid);
fprintf (stdout,"tid %d \n", tid);fflush(NULL);
fine = 1;
}

void* thread1()
{
int tid;
tid = syscall (SYS_gettid);
while(!fine)
{
fprintf(stdout,"thread1 %d partito\n",tid);fflush(NULL);
sleep(10);
kill(getpid(),SIGINT);
}

fprintf(stdout,"thread1 termina\n");fflush(NULL);
return (void*) 1;
}

void* thread2()
{
int tid;
tid = syscall (SYS_gettid);
while(!fine)
{
fprintf(stdout,"thread2 %d partito\n",tid);fflush(NULL);
sleep(1);
}
fprintf(stdout,"thread2 termina\n");fflush(NULL);
return (void*) 1;
}

void* thread3()
{
int tid;
tid = syscall (SYS_gettid);
while(!fine)
{
fprintf(stdout,"thread3 %d partito \n",tid);fflush(NULL);
sleep(1);
}
fprintf(stdout,"thread3 termina\n");fflush(NULL);
return (void*) 1;
}

int main()
{

sigset_t set;

struct sigaction sa;
void** status=NULL;

/* maschero tutti i segnali */
sigfillset(&set);
pthread_sigmask(SIG_SETMASK,&set,NULL);

/* installo i gestori */
bzero( &sa, sizeof(sa) );
sa.sa_handler = handler;
sigaction(SIGINT,&sa,NULL);
sigaction(SIGTERM,&sa,NULL);

/* tolgo la maschera */
sigemptyset(&set);
pthread_sigmask(SIG_SETMASK,&set,NULL);

/*creo i threads */
pthread_create(&tid1, NULL, &thread1, NULL);
fprintf(stdout,"main -- creato thread1 \n");fflush(NULL);
sleep(1);
pthread_create(&tid2, NULL, &thread2, NULL);
fprintf(stdout,"main -- creato thread2 \n");fflush(NULL);
sleep(1);
pthread_create(&tid3, NULL, &thread3, NULL);
fprintf(stdout,"main -- creato thread3 \n");fflush(NULL);
sleep(1);

while(!fine)
{
fprintf(stdout,"main while\n");fflush(NULL);
sleep(50);
}
pthread_join(tid1,status);
pthread_join(tid2,status);
pthread_join(tid3,status);
fprintf(stdout,"main termina\n");fflush(NULL);
return 1;
}

Qualcuno sa spiegarmi un possibile motivo?

[tomminno]

Il comportamento è del tutto coerente con il codice che hai scritto, essendo multithread viene eseguito nuovamente thread1 prima della gestione di SIGINT (a seconda dei casi potrebbe pure comportarsi nella maniera che ti attendi se aumenti lo sleep).

Secondo me non ha senso che thread1 possa inviare più volte il segnale SIGINT, dovresti far terminare thread1 dopo il primo kill e non metterlo all'interno del while.

[shatzy]

Questo è un esempio che mi serve per risolvere un progetto più esteso, in cui tutti i thread fanno operazioni in un ciclo. Di conseguenza non posso evitare che thread1 entri in un ciclo, altrimenti il mio esempio non sarebbe coerente. Quello che non mi convince è come mai l'handler parte dopo che thread1 abbia ripreso a lavorare, per come l'avevo capita io, l'handler dovrebbe partire immediatamente dopo il sollevamento dell'interruzione, dato che i segnali pendenti vengono controllati sempre al ritorno di una system call

[marco.r]

Questo è un esempio che mi serve per risolvere un progetto più esteso, in cui tutti i thread fanno operazioni in un ciclo. Di conseguenza non posso evitare che thread1 entri in un ciclo, altrimenti il mio esempio non sarebbe coerente. Quello che non mi convince è come mai l'handler parte dopo che thread1 abbia ripreso a lavorare, per come l'avevo capita io, l'handler dovrebbe partire immediatamente dopo il sollevamento dell'interruzione, dato che i segnali pendenti vengono controllati sempre al ritorno di una system call

Sei in un programma multithreaded. Non sai in che thread venga chiamato il signal handler.
Puo' quindi essere che mentre viene chiamato il signal handler il thread1 continui e rientri nel loop prima che venga impostato il flag.

[shatzy]

Questo posso capirlo, ma nell'handler faccio anche stampare il tid e nella maggior parte dei casi viene stampato proprio quello di thread1... dunque è da lui che parte l'handler e almeno in questo caso dovrebbe partire prima che il thread riprenda la normale esecuzione, invece ciò non accade e thread1 fa comunque 2 cicli.
Queste sono le stampe che ottengo dopo l'esecuzione:

elisa@elisa-Aspire-5951G:~$ ./esempio
main -- creato thread1
thread1 2347 partito
main -- creato thread2
thread2 2348 partito
thread2 2348 partito
main -- creato thread3
thread3 2349 partito
thread2 2348 partito
main while
thread3 2349 partito
thread2 2348 partito
thread3 2349 partito
thread2 2348 partito
thread3 2349 partito
thread2 2348 partito
thread3 2349 partito
thread2 2348 partito
thread3 2349 partito
thread2 2348 partito
thread3 2349 partito
thread2 2348 partito
thread3 2349 partito
thread2 2348 partito
thread3 2349 partito
thread1 mandata SIGINT
thread1 2347 partito
tid 2347
thread2 termina
thread3 termina
thread1 mandata SIGINT
thread1 termina
tid 2346
main termina

[tomminno]

Questo è un esempio che mi serve per risolvere un progetto più esteso, in cui tutti i thread fanno operazioni in un ciclo. Di conseguenza non posso evitare che thread1 entri in un ciclo, altrimenti il mio esempio non sarebbe coerente. Quello che non mi convince è come mai l'handler parte dopo che thread1 abbia ripreso a lavorare, per come l'avevo capita io, l'handler dovrebbe partire immediatamente dopo il sollevamento dell'interruzione, dato che i segnali pendenti vengono controllati sempre al ritorno di una system call

Allora devi usare uno qualunque dei costrutti di sincronizzazione tra thread: mutex, semafori,... a seconda di quello che devi fare.

[shatzy]

Scusami Tomminno, non ti seguo, usare meccanismi di mutua esclusione per cosa?? Intendi per l'accesso alla variabile fine?
Ma la variabile fine è di tipo volatile sig_atomic_t quindi il suo accesso è già indivisibile

[marco.r]

dunque è da lui che parte l'handler e almeno in questo caso dovrebbe partire prima che il thread riprenda la normale esecuzione, invece ciò non accade e thread1 fa comunque 2 cicli.

Quando tu lanci il segnale, questo parte in modo asincrono e l'esecuzione del thread prosegue praticamente subito.
D'altro canto invece la gestione del segnale non e' cosi' immediata come uno potrebbe immaginarsi visto che richiede un po' di gestione da parte sia del kernel che delle librerie : capire se il processo gestisce o meno il segnale, capire quale thread e' in condizioni di farlo etc. Ora che viene chiamato il signal handler nel thread opportuno, il thread di cui sopra avra' gia' eseguito un po' di istruzioni.

[shatzy]

Grazie Marco la tua risposta mi convince quasi del tutto. Dalle tue parole, però, mi pare di capire che il kernel lavori contemporaneamente al thread1, cosa che non mi sembra possibile, perché avviene tutto all'interno di un solo processore.
Io pensavo che si può essere o in modalità kernel (quindi lavora il kernel), o in modalità user (e quindi lavora thread1), ma non nello stesso momento.
In quest'ottica non riesco a dare un senso al fatto che il kernel sia lento a calcolare il thread destinatario del segnale perché se lavora lui non lavora thread1.
Dove sbaglio?

[tomminno]

Scusami Tomminno, non ti seguo, usare meccanismi di mutua esclusione per cosa?? Intendi per l'accesso alla variabile fine?
Ma la variabile fine è di tipo volatile sig_atomic_t quindi il suo accesso è già indivisibile

Te devi sincronizzare i thread, ma non per l'accesso alla variabile fine.

L'esempio che hai posto non è adatto in quanto nel caso in esame si risolve evitando il loop in thread1, ma nel caso a quanto pare reale in cui thread1 dopo il primo ciclo debba attendere qualche evento da qualche altro thread prima di procedere con il secondo giro, ecco che entrano in gioco i costrutti di sincronizzazione.

Così ad occhio potrebbe bastarti un mutex su cui thread1 rimane bloccato fino a che handler non ha gestito il segnale.
Ma per essere più precisi (magari ti serve usare un semaforo) dovresti fare un esempio più calzante con il caso reale.

[shatzy]

Dato che mi è sorto un altro problema, descrivo anche il caso reale che devo trattare.
Devo realizzare un "server" composto dal main e diversi threads "worker".
Il main crea una socket di comunicazione ed entra in un ciclo while(!fine) in cui si blocca nella accept finchè un "client" non si connette alla socket e una volta che l'accept ritorna positivamente, main crea un thread worker.
Questo attenderà messaggi dal relativo client ed esaudirà alcune richieste.
Il server deve terminare all'arrivo di un segnale SIGINT o SIGTERM, in maniera gentile, cioè prima tutti i worker devono risolvere le richieste pendenti e salvare alcuni dati in un file di log.
Il mio problema è che una volta arrivato il segnale di terminazione oltre a settare fine=1 tramite handler, devo anche fare in modo che tutti i threads eventualmente bloccati nelle read o nella eccept si sblocchino.
Il meccanismo che ho pensato di usare è mandare delle kill in cascata:
il thread che riceve il segnale è sicuramente sbloccato dal segnale stesso, esce dal while mandando una kill prima di terminare. E così via per tutti i threads. Il mio dubbio è: c'è un modo per mandare un segnale ad una altro thread a caso, diverso da me, senza salvarsi la lista di tutti i tid?
Con kill(getpid(),SIGINT) mi pare che il segnale possa arrivare anche a me stesso, e questo vanificherebbe il suo l'effetto