Atomichunter come usare le funzioni atomic built-in di GCC in C

Graham: Non è curioso di sapere se Lei è più furbo di quello che cerchiamo?
Lecktor: Stai scherzando? Tu sei più furbo, visto che mi hai preso...
Graham: No, non sono più furbo di Lei.
Lecktor: E allora come hai fatto a prendermi?
Graham: Lei era svantaggiato.
Lecktor: In che senso svantaggiato?
Graham: Lei è pazzo.

Per parlare delle funzioni atomic built-in di GCC ho deciso di fare un temerario abbinamento con il capolavoro Manhunter del Maestro Michael Mann, un film assolutamente imperdibile. Il fatto è che per risolvere un problema pratico (ebbene si, oggi parleremo del mondo reale) a volte un programmatore deve trasformarsi in un cacciatore (fortunatamente non di uomini), e quindi deve investigare, provare, cercare informazioni qui e là per risolvere un caso reale. Si, bisogna fare come il detective Graham del film: beh, magari senza arrivare ai suoi estremi, e chi ha visto il film sa di cosa parlo...

...sai, ti ho preso grazie alle atomic built-in di GCC...

Non so se ricordate un mio articolo di un annetto fa, Atomic: Endgame, in cui decantavo la bontà del nuovo type qualifier _Atomic introdotto con C11 (e, ovviamente, se non lo ricordate siete tenuti a rileggerlo...). Nell'articolo era (spero) ben descritta la nuova funzionalità e si evidenziava che, grazie a _Atomic, la scrittura di applicazioni multi-thread  diventava molto più agevole (era ora!). E perché oggi torniamo sull'argomento? E qui sopraggiunge il problema pratico citato sopra: supponiamo (true story) di dover aggiungere una nuova prestazione a una vecchia applicazione su Linux Embedded usando la piattaforma (e quindi il compilatore) originale, che, per la legge di Murphy, non supporta C11 (anzi supporta a stento C99): che facciamo? Dovremo mica riscrivere il codice (già scritto e testato su piattaforme più recenti) in modo di usare i classici meccanismi di sincronizzazione delle variabili (mutex, ecc.)? No, ci deve essere una soluzione più semplice!

E quindi mi sono Graham-izzato (vedi sopra) e ho scoperto che il nostro amato GCC, grande amico dei programmatori C (e non solo), ha da molto tempo delle funzioni built-in che hanno anticipato le funzionalità di _Atomic ben prima del supporto a C11. Anzi, abbiamo ben due famiglie di built-in denominate __sync_* e __atomic_* , aggiunte con a la seguente sequenza temporale:

• GCC 4.1: __sync_* built-in (nel 02/2006)
• GCC 4.4: __sync_* built-in (nel 04/2009,  con supporto ARM)
• GCC 4.7: __atomic_* built-in (nel 03/2012)
• GCC 4.9: _Atomic (nel 04/2014, supporto completo)

Considerando la data in cui _Atomic è entrato in GCC il supporto a queste operazioni è stato fornito con un buon anticipo, no? Nella lista qui sopra ho anche evidenziato quando è stata aggiunta la compatibilità con ARM, perché l'argomento di questo articolo è decisamente indirizzato alla programmazione con Linux Embedded, e ARM è una piattaforma molto usata in questo ambito. Tra l'altro si può evidenziare che anche le versioni recenti di GCC continuano a supportare questi built-in, e quindi un eventuale Software "datato" che le usa si può ancora compilare senza problemi con un GCC recente, e senza modificare nulla (questa si che è vera retro-compatibilità! Grazie gcc.gnu.org!).

Nella mia ricerca ho anche notato che la quantità di informazioni a livello base (tipicamente quella fornita da gcc.gnu.org) è notevole in quantità e qualità, però latitano un po' i veri esempi d'uso (il codice!), e quindi ho deciso di contribuire un po' con questo articolo, che interesserà a pochi (credo) ma per quei pochi potrebbe essere una manna dal cielo (vabbé, non esageriamo...).

Che ho fatto allora? Ho scritto una mini-libreria per semplificare l'uso dell funzioni atomic built-in, e ho strutturato la libreria in maniera che si comporti in modo "intelligente" riconoscendo la versione del GCC in uso, per passare automaticamente da _Atomic a __atomic_* oppure a __sinc_*. Ho scritto un header, atoint.h che definisce un nuovo tipo atoint (nome originalissimo che sta per atomic int). Vediamolo: vai col codice!

/* atoint.h - header della libreria atoint
   versioni delle funzioni atomiche:
     _Atomic:        da GCC 4.9 in avanti (40900L)
     __atomic:       da GCC 4.7 in avanti (40700L)
     __sync con ARM: da GCC 4.4 in avanti (40400L)
     __sync:         da GCC 4.1 in avanti (40100L) */
// GCC_VERSION contiene la versione di GCC come numero (e.g.: GCC4.9 = 40900)
#define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
#if GCC_VERSION >= 40900L
// da GCC 4.9 in avanti è disponibile _Atomic di C11
#include <stdatomic.h>
typedef atomic_int atoint;  // uso atomic_int per atoint
#else
// _Atomic di C11 non è disponibile
typedef int atoint;         // uso int per atoint
#endif
#if GCC_VERSION >= 40900L
// uso le funzioni di _Atomic
#define ATOMIC_STORE(ptr, val)  atomic_store((ptr), val)
#define ATOMIC_LOAD(ptr)        atomic_load(ptr)
#define ATOMIC_INC(ptr)         atomic_fetch_add((ptr), 1)
#define ATOMIC_DEC(ptr)         atomic_fetch_sub((ptr), 1)
#elif GCC_VERSION >= 40700L
// uso le funzioni di GCC __atomic prefixed built-in
#define ATOMIC_STORE(ptr, val)  __atomic_store_n((ptr), val, __ATOMIC_SEQ_CST)
#define ATOMIC_LOAD(ptr)        __atomic_load_n((ptr), __ATOMIC_SEQ_CST)
#define ATOMIC_INC(ptr)         __atomic_fetch_add((ptr), 1, __ATOMIC_SEQ_CST)
#define ATOMIC_DEC(ptr)         __atomic_fetch_sub((ptr), 1, __ATOMIC_SEQ_CST)
#elif GCC_VERSION >= 40100L
// TODO: scrivere la versione con __sync prefixed built-in
// ...
#else
#error Spiacente, il tuo compilatore è troppo vecchio - aggiornalo, per favore.
#endif
// prototipi globali
atoint atoStore(atoint *val, atoint newval);    // store
atoint atoLoad(atoint *val);                    // load
atoint atoPreInc(atoint *value);    // prefix increment (++val)
atoint atoPostInc(atoint *value);   // postfix increment (val++) (usa il prefix increment)
atoint atoPreDec(atoint *value);    // prefix decrement (--val)
atoint atoPostDec(atoint *value);   // postfix decrement (val--) (usa il prefix decrement)

Come si può ben vedere il file contiene la definizione del nuovo tipo e i prototipi delle funzioni della libreria. E, soprattutto, contiene degli alias (delle #define) delle funzioni che usano le appropriate atomic built-in in base alla versione del compilatore in uso, versione che è contenuta nella macro GCC_VERSION (è un numero identificativo abbastanza semplice da calcolare, ad esempio per GCC 4.9 è 40900). Con l'uso di alcune semplici direttive #if  per il preprocessore del C possiamo scegliere quali alias attivare automaticamente. In questa versione ho usato come requisito minimo per la famiglia __sync_* il GCC 4.1  (ver.40100), ma chi ha bisogno del supporto ARM dovrebbe usare come requisito minimo il GCC 4.4 (ver.40400). Usando un compilatore ancora più anziano del requisito minimo, la compilazione esce (miseramente) con questo errore: "Spiacente, il tuo compilatore è troppo vecchio - aggiornalo, per favore.".

Visto che non volevo mettere troppa carne al fuoco ho lasciato come TODO  la versione con __sync_*  che è un po' più complicata e avrebbe appesantito un po' il codice. Tra l'altro si dovrebbero/potrebbero aggiungere anche altre funzioni oltre a quelle presentate qui (e si può fare: io, mio malgrado, ho dovuto scrivere una versione full-optional perché mi serviva): magari ci torneremo in un prossimo articolo.

Grazie agli alias delle funzioni la implementazione della libreria è molto semplice e lineare. Vediamola:

// atoint.c - implementazione della libreria atoint
#include "atoint.h"
// store (assegna il valore)
atoint atoStore(atoint *val, atoint newval)
{
    ATOMIC_STORE(val, newval);
    return *val;        // return del valore nuovo
}
// load (legge il valore)
atoint atoLoad(atoint *val)
{
    return ATOMIC_LOAD(val);
}
// prefix increment (++val)
atoint atoPreInc(atoint *val)
{
    ATOMIC_INC(val);    // incrementa atomicamente
    return *val;        // return del valore nuovo
}
// postfix increment (val++) (usa il prefix increment)
atoint atoPostInc(atoint *val)
{
    atoint old = *val;  // salva il valore vecchio
    atoPreInc(val);     // incrementa atomicamente
    return old;         // return del valore vecchio
}
// prefix decrement (--val)
atoint atoPreDec(atoint *val)
{
    ATOMIC_DEC(val);    // decrementa atomicamente
    return *val;        // return del valore nuovo
}
// postfix decrement (val--) (usa il prefix decrement)
atoint atoPostDec(atoint *val)
{
    atoint old = *val;  // salva il valore vecchio
    atoPreDec(val);     // decrementa atomicamente
    return old;         // return del valore vecchio
}

È veramente molto semplice, no? E grazie ai molti commenti, credo che non sono necessarie ulteriori spiegazioni.

E, dulcis in fundo, bisogna provare se la libreria funziona, no? Si, ci vuole un bel programma di test, vai col codice!

#include <stdio.h>
#include <pthread.h>
#include "atoint.h"
// prototipi locali
void* updateCnt(void* arg);
// variabili globali (per un semplice test si possono usare!)
atoint ato_cnt; // un int atomico usato come contatore
int    cnt;     // un int normale usato come contatore
// funzione main
int main(void)
{
    // init contatori
    atoStore(&ato_cnt, 0);
    cnt = 0;
    // avvio 10 thread
    pthread_t tid[10];
    for (int n = 0; n < 10; ++n)
        pthread_create(&tid[n], NULL, &updateCnt, NULL);
    // attendo la fine dei 10 thread
    for(int n = 0; n < 10; ++n)
        pthread_join(tid[n], NULL);
    // i risultati!
    printf("Il contatore atomico vale: %u\n", ato_cnt);
    printf("Il contatore normale vale: %u\n", cnt);
    return 0;
}
// updateCnt() - funzione di update dei counter eseguita da ogni thread
void* updateCnt(void* arg)
{
    // incremento i counter per 1000 volte
    for (int n = 0; n < 1000; ++n) {
        // uso prefix increment
        atoPreInc(&ato_cnt);
        ++cnt;
    }
    return NULL;
}

I più attenti avranno notato che è esattamente lo stesso programma di test mostrato nell'articolo Atomic: Endgame, solo che in questo caso si usa il nuovo tipo atoint invece del tipo standard atomic_int: se il test funzionasse potremmo affermare che la libreria atoint è un buon sostituto della versione standard. Ci riusciremo? Proviamo: prima di tutto se stiamo usando un GCC recente (cosa probabile) dobbiamo forzare l'uso della versione senza _Atomic (ad esempio "truccando"  la define di GCC_VERSION), poi possiamo compilare ed eseguire. Il risultato è questo:

aldo@Linux $ ./test
Il contatore atomico vale: 10000
Il contatore normale vale: 4902

Ma funziona! Il contatore atomico atoint ha contato esattamente tutti gli incrementi e vale 10000 mentre il contatore normale ha perso molti degli incrementi a causa della concorrenza, e, quindi, vale molto meno (e ripetendo l'esecuzione si ottengono sempre valori inferiori a 10000). Se poi vogliamo fare anche "la prova del 9"  possiamo togliere il trucco che forza la versione antica e ricompilare con il nostro GCC recente: con _Atomic,  il risultato dovrebbe essere lo stesso (e se non lo è sarebbe il caso di dire "Houston, abbiamo un problema.").

E, se avete voglia di sperimentare, potete modificare leggermente il codice per usare anche le tre funzioni inutilizzate (atoPostInc(), atoPreDec() e atoPostDec()), vi assicuro che funzionano bene.

Ok, personalmente a questo punto sono soddisfatto e per oggi possiamo concludere qui. La libreria atoint funziona e spero vivamente che possa risultare utile a molti lettori. Nel prossimo articolo cambieremo argomento, ma, come promesso sopra, prima o poi torneremo su questa storia per completare la trattazione... e non trattenete il respiro nell'attesa, mi raccomando!

Ciao, e al prossimo post!

Licorice System come scrivere una system(3) con timeout in C

Gary: Signore e signori posso avere la vostra attenzione? Lasciate che vi presenti la futura signora Alana Valentine.
Alana: Idiota.

Questo articolo è la seconda parte (non prevista, devo ammetterlo) di System? No, grazie!, quindi dovrebbe ripetere lo stesso titolo; però poco tempo fa ho visto il bel Licorice Pizza del Maestro Paul Thomas Anderson e non ho resistito alla tentazione di agganciarlo a questo post. E, a maggior ragione, l'ho fatto anche perché questo secondo articolo non è più un "No grazie!" ma è una variazione sul tema con una proposta interessante. Interessante come il film in oggetto, pieno di frasi lapidarie come quella vista sopra. Un piccolo gioiellino che ci ha regalato (grazie Paul!) un P.T.Anderson in veste leggera e spensierata, ma sempre a modo suo (ah, divagando: ne ho scritti altri di “No Grazie!” e vi invito a leggerli o rileggerli, qui, qui, qui e qui).

...corri, se no scade il timeout della nuova system...

E allora: immagino che tutti avete ben chiari i difetti della system(3) che ne fanno una funzione anti-pattern (e se non li avete chiari correte a rileggere l'articolo, svelti, prima che scappi!). Come ricorderete avevo elencato una lunga serie di problemi, indicando questo come il più grave:

"Quando si chiama la system(3) il programma principale viene sospeso fino al termine del comando invocato, e non c'è nessuna maniera di controllare efficacemente quello che sta succedendo."

e dopo calcavo la mano in questa maniera:

"Ah, solo come curiosità: nella lista dei problemi qui sopra quello che mi molesta di più è il numero 3: una applicazione che usa system(3) non ha maniera di controllare quello che sta succedendo con i programmi esterni invocati, e deve sospendersi per aspettare che finiscano l'esecuzione: ma questa vi sembra la descrizione di una buona applicazione da mandare in produzione? E vabbè, continuiamo cosi, facciamoci del male..."

Per cui, di cosa parleremo oggi? Ma di una system(3) con timeout, proprio quello che ci serve! In realtà l'idea originale era di fare una versione che risolvesse anche tutti gli altri problemi della lista (e in effetti ne ho scritta una) ma non volevo gettare troppa carne al fuoco, e quindi, per il momento, vi propongo questa che risolve il problema più importante (e scusate se è poco!).

Ok, è venuto il momento di far cantare il codice, che è pieno di commenti (che dovrebbero essere sufficienti a spiegare il tutto), ma comunque aggiungerò anche qualche nota in coda. Vai col codice!

#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/wait.h>
// prototipi locali
static int  toutSystem(const char* command, unsigned int timeout_ms);
static void mySleep(unsigned int milliseconds);
#define TOUT_SLEEP  500     // intervallo di sleep per il loop busy wait del timeout
// funzione main()
int main(int argc, char* argv[])
{
    // test con uno shell-script ma funziona con qualsiasi comando disponibile
    printf("main: eseguo toutSystem(\"./script.sh > out.txt\", 5000)\n");
    toutSystem("./script.sh > out.txt", 5000);
    return 0;
}
// toutSystem() - una system(3) con timeout
static int toutSystem(
    const char   *command,      // il comando shell da eseguire (e.g.: cp -v file1 file2)
    unsigned int timeout_ms)    // timeout per waitpid(2) in ms: 0 significa senza timeout
{
    char errmsg_buf[256];
    // fork + exec + wait
    pid_t pid = fork();
    if (pid == 0) {
        // figlio: eseguo il comando
        printf("%s: figlio: processo %d: eseguo il comando\n",
               __func__, getpid());
        execl("/bin/sh", "sh", "-c", command, (char *) NULL);
        // questo viene eseguito solo se fallisce exec (exec non ritorna mai)
        printf("%s: figlio: processo %d: errore exec: %s\n",
               __func__, getpid(), strerror_r(errno, errmsg_buf, sizeof(errmsg_buf)));
        exit(EXIT_FAILURE);
    }
    else if (pid > 0) {
        // padre: attesa uscita del figlio
        printf("%s: padre: processo %d: attesa uscita del figlio\n",
               __func__, getpid());
        int rc_wait;
        int status;
        if (timeout_ms > 0) {   // check timeout
            // busy wait con timeout
            int cnt_wait = 0;
            while ((rc_wait = waitpid(pid, &status, WNOHANG)) == 0) {
                mySleep(TOUT_SLEEP);
                if (++cnt_wait > timeout_ms / TOUT_SLEEP) {
                    // figlio non uscito prima del timeout: return errore
                    printf("%s: padre: processo %d: waitpid timeout scaduto\n",
                           __func__, getpid());
                    return -1;
                }
            }
        }
        else {
            // wait senza timeout
            rc_wait = waitpid(pid, &status, 0);
        }
        // figlio uscito: return risultato
        if (rc_wait != pid) {
            // waitpid error
            printf("%s: padre: processo %d: errore waitpid (%s)\n",
                   __func__, getpid(), strerror_r(errno, errmsg_buf, sizeof(errmsg_buf)));
            return -1;
        }
        else {
            // processo terminato: return risultato
            int result = -1;
            if (WIFEXITED(status)) {
                // questo è l'unico risultato accettato come successo
                result = 0;
                printf("%s: padre: processo %d: pid %d uscito (status=%d)\n",
                       __func__, getpid(), pid, WEXITSTATUS(status));
            }
            else if (WIFSIGNALED(status))
                printf("%s: padre: processo %d: pid %d ucciso dal segnale %d\n",
                       __func__, getpid(), pid, WTERMSIG(status));
            else if (WIFSTOPPED(status))
                printf("%s: padre: processo %d: pid %d fermato dal segnale %d\n",
                       __func__, getpid(), pid, WSTOPSIG(status));
            else
                printf("%s: padre: processo %d: pid %d con stato sconosciuto (status=%d)\n",
                       __func__, getpid(), pid, status);
            return result;
        }
    }
    else {
        // errore fork
        printf("%s: errore fork: %s\n",
               __func__, strerror_r(errno, errmsg_buf, sizeof(errmsg_buf)));
        return -1;
    }
}
// mySleep() - wrapper per nanosleep()
static void mySleep(unsigned int milliseconds)
{
    struct timespec ts;
    ts.tv_sec = milliseconds / 1000;
    ts.tv_nsec = (milliseconds % 1000) * 1000000;
    nanosleep(&ts, NULL);
}

Come avrete notato la nuova funzione, che ho battezzato toutSystem() (un nome originalissimo...) è scritta sulla falsariga dell'esempio con  fork(2) + exec(3) + wait(2) del precedente articolo, che era una delle soluzioni proposte come buona alternativa alla system(3) e che fa al caso nostro per sviluppare questa nuova versione.

Il funzionamento è (relativamente) semplice: la funzione esegue fork(2) e si sdoppia in padre e figlio. Il figlio esegue il comando <command> esattamente come lo fa, internamente, la system(3), per cui usa execl(3) per creare una sub-shell di esecuzione (e fino a qui siamo abbastanza in linea con la system(3) e con alcuni dei i suoi difetti, sigh). La parte buona, però la esegue il padre che, invece di limitarsi ad aspettare l'uscita del figlio, esegue un loop in stile busy wait  usando in maniera "intelligente" waitpid(3) per un tempo mai superiore ai millisecondi indicati dall'argomento <timeout_ms>. Alla fine del loop si testa il risultato dell'attesa per decidere se ritornare un errore o un esito, e il risultato che ci preme è stato conseguito: la toutSystem() non può bloccare indefinitamente il nostro programma (al contrario di quello che può fare la famigerata system(3)), ma lo blocca al massimo per la durata del timeout. E, comunque, ho lasciato la possibilità di simulare il comportamento "classico" (ossia: attesa indefinita) usando zero come timeout.

L'esempio qui sopra contiene anche un main() di prova, così gli increduli potranno compilare e verificare direttamente il funzionamento. Si può eseguire qualsiasi comando: io nell'esempio ho eseguito uno shell script che ho scritto proprio per verificare l'efficacia del timeout. Lo script (che poteva essere anche un semplice codice C compilato, eh!) è questo:

#!/bin/bash
for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
do
    echo $i
    sleep 1
done

Lo script scrive per 15 secondi un numero progressivo nel file "out.txt" su cui è rediretto il comando di toutSystem() nel main(): toutSystem("./script.sh > out.txt", 5000). Se compilate ed eseguite l'output sarà questo:

main: eseguo toutSystem("./script.sh > out.txt", 5000)
toutSystem: padre: processo 16463: attesa uscita del figlio
toutSystem: figlio: processo 16464: eseguo il comando
toutSystem: padre: processo 16463: waitpid timeout scaduto

che indica che la nostra chiamata a toutSystem() è uscita per timeout dopo 5 secondi (lo script eseguito lavora per 15 secondi, quindi è ancora attivo in quel momento), e difatti noterete che il file "out.txt" si riempirà 10 secondi dopo l'uscita del programma principale. Provare per credere!

Ok, per oggi può bastare: la toutSystem() è già perfettamente utilizzabile nella forma proposta, ed è una ottima alternativa all'uso della system(3) che, non mi stanco mai di dirlo, non si dovrebbe mai usare. Vi consiglio,  come utile esercitazione, di provare a modificare la toutSystem() per ovviare anche agli altri problemi elencati nell'articolo System? No, grazie!. Io l'ho fatto e vi assicuro che non è un lavoro molto complicato (e prossimamente vi mostrerò la mia soluzione, promesso).

Ciao, e al prossimo post!

Thread Cancel? No, grazie! considerazioni sul perché non usare la pthread_cancel(3) in C (e C++) - pt.2

[il gruppo alla ricerca di una via d'uscita si accorge di non essere sulla Terra guardando il cielo]
Royce: Abbiamo bisogno di un nuovo piano...

Come promesso nella prima parte dell'articolo è venuto il momento di dare qualche consiglio su come fermare un thread senza usare la pthread_cancel(3). Là il film collegato era il mitico Predator, e in questo, per rimanere in tema, ho scelto il buon Predators che, pur non essendo all'altezza del primo della saga, ne è un buon seguito (al contrario di Predator 2 su cui è meglio sorvolare). In Predators i protagonisti sono alle prese con una missione quasi impossibile (e mi scuso per lo spoiler: tornare sulla terra), una missione complicata come fermare efficacemente un thread usando la pthread_cancel(3)... Ma niente paura, qui vedremo come si può fare!

...ve l'avevo detto che andava a finire così usando la pthread_cancel(3)...

E allora, veniamo al dunque: immagino che tutti conosciate il principio del Rasodio di Occam, che più o meno dice:

E’ inutile fare con più ciò che può essere fatto con meno.

Ebbene si, applicando questo fantastico principio al nostro problema possiamo dire: "perché per fermare un thread devo usare la (demenziale) combinazione di pthread_setcancelstate(3) + pthread_setcanceltype(3) + pthread_key_create(3) + pthread_cleanup_push(3) + pthread_cleanup_pop(3) + pthread_getspecific(3) + pthread_setspecific(3) + pthread_cancel(3) + pthread_join(3) quando posso lasciare a lui l'incarico di fermarsi bene?".  Uhm, detto così sembra facile... e in effetti lo è! Il trucco consiste nel progettare adeguatamente la funzione eseguita dal thread in maniera che abbia dei punti di uscita "puliti", e senza usare nessuna funzione accessoria della libpthread, che, come abbiamo visto, sono (per questa particolare situazione) molte, macchinose e anche complicate da usare.

Ok, bando alle ciance, facciamo parlare il codice: ecco un esempio molto semplice di uscita controllata che ho ottenuto applicando pochi piccoli cambi al codice di threaderrcancel.c  che, nello scorso articolo, chiudeva male il thread. Vai col codice!

/ threadstop.c -esempio di stop thread
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

// prototipi globali
static void* myThread(void *arg);
static void  mySleep(unsigned int milliseconds);

// main() - funzione main()
int main(int argc, char* argv[])
{
    // creo il thread con un argomento "stop"
    int stop = 0;
    pthread_t tid;
    pthread_create(&tid, NULL, &myThread, &stop);

    // aspetto 2 secondi e poi stop del thread
    mySleep(2000);
    stop = 1;

    // join del thread
    pthread_join(tid, NULL);

    // esco
    printf("%s: esco\n", argv[0]);
    return 0;
}

// myThread() - thread routine
void* myThread(void *arg)
{
    // recast dell'argomento di stop thread
    int *stop = (int *)arg;

    // loop del thread
    printf("thread partito\n");
    while (*stop == 0) {
        // il thread fa cose...
        // ...

        // malloc sul buffer
        char *p = (char *)malloc(100);

        // simulo un ritardo perché il thread fa altre cose...
        mySleep(2);

        // free del buffer
        free(p);

        // sleep del thread (10 ms)
        mySleep(10);
    }

    // il thread esce
    printf("thread finito\n");
    pthread_exit(NULL);
}

// mySleep() - wrapper per nanosleep()
static void mySleep(unsigned int milliseconds)
{
    struct timespec ts;
    ts.tv_sec = milliseconds / 1000;
    ts.tv_nsec = (milliseconds % 1000) * 1000000;
    nanosleep(&ts, NULL);
}

Non so se avete notato: è praticamente lo stesso codice dell'altro con 5 (cinque!) linee modificate. Il semplicissimo trucco consiste nel passare al thread un flag (con il fantasiosissimo nome "stop") e usarlo adeguatamente nella funzione del thread. Nel nostro esempio la funzione esegue un loop pseudo-infinito, che ha come condizione di chiusura proprio il valore del flag di stop. Quando il main()  scrive 1 nel flag (invece di chiamare la pthread_cancel(3)) il thread finirà di eseguire il ciclo loop e, invece di eseguire un nuovo ciclo, uscirà chiamando pthread_exit(3). Ok, questo è un esempio molto semplificato, ma con qualche accortezza si può applicare a qualsiasi modello di thread routine. Anzi, possiamo fare un piccolo specchietto dei tre casi più classici di funzione di thread:

1. Funzione con loop pseudo-infinito semplice: il thread esegue poche operazioni self-cleaning in loop. È quello dell'esempio appena mostrato, e con il test del flag di stop nel while siamo a posto così.
2. Funzione con loop pseudo-infinito complesso: il thread esegue molte operazioni nel loop. Oltre al test del flag di stop nel while possiamo aggiungere delle istruzioni di uscita intermedie di questo tipo:
   

   ...
   if (stop == 1) {
       // pulisco memoria, lock, ecc.
       ...
       // esco dal loop (ma potrei anche uscire direttamente con pthread_exit(3))
       break;
   }
   ...

3. Funzione senza loop pseudo-infinito: il thread esegue alcune attività sequenziali. Possiamo aggiungere dopo ogni attività delle istruzioni di uscita intermedie di questo tipo:
   

   ...
   if (stop == 1) {
       // pulisco memoria, lock, ecc.
       ...
       // esco
       pthread_exit(NULL);
   }
   ...

Qualcuno dirà: "ma le attività di pulizia prima della chiusura sono le stesse viste l'altra volta con pthread_cleanup_push(3), ecc., quindi è la stessa cosa...". De gustibus: se sembra la stessa cosa ognuno è libero di continuare a impazzire usando la pthread_cancel(3) e le altre 1000 funzioni accessorie. A me sembra molto più semplice usare il flag di stop come appena mostrato... ma non voglio certo privare nessuno del piacere di scrivere codice più complicato del necessario (ah ah ah).

E chiudo con un (spero utile) consiglio: è meglio non confidare troppo nella combinazione pthread_create(3) + pthread_join(3): se qualcosa va male nello stop del thread (chessoio: una operazione di I/O bloccata nel thread) la pthread_join(3) blocca il programma infinitamente. Qualche furbone ovvia al problema eseguendo pthread_detach(3) sul thread appena creato, ma questa non è una scelta raccomandabile, perché si perde completamente il controllo dei thread creati e anche la possibilità di un vero stop controllato. Ci sono, invece, due opzioni molto più interessanti: la prima è usare una vera join con timeout, la pthread_timed_join_np(3), che funziona così (vi mostro solo il main(), nel resto del codice non cambia nulla):

// main() - funzione main()
int main(int argc, char* argv[])
{
    // creo il thread con un argomento "stop"
    int stop = 0;
    pthread_t tid;
    pthread_create(&tid, NULL, &myThread, &stop);
    // aspetto 2 secondi e poi stop del thread
    mySleep(2000);
    stop = 1;
    // join del thread con timeout di 1 sec
    struct timespec timeout;
    clock_gettime(CLOCK_REALTIME, &timeout);    // prendo il tempo attuale
    timeout.tv_sec += 1;    // il timeout è il tempo attuale più 1 sec
    int retval = pthread_timedjoin_np(tid, NULL, &timeout);
    // esco
    printf("%s: esco (%s)\n", argv[0],
           retval == ETIMEDOUT ? "con timeout" : "con Ok");
    return 0;
}

Oppure, se non è disponibile una la join con timeout (e, ahimè, per le interfacce threads di C11 e std::thread di C++11 è così), si può fare questo (e qui ci sono più cambi, quindi vi mostro quasi tutto il codice, omettendo le parti invariate):

// struttura per stop controllato
typedef struct _stops {
    int stop;
    int stopped;
} Stops;

// prototipi globali
static void* myThread(void *arg);
static void  mySleep(unsigned int milliseconds);

// main() - funzione main()
int main(int argc, char* argv[])
{
    // creo il thread con un argomento "stops"
    Stops stops;
    stops.stop    = 0;
    stops.stopped = 0;
    pthread_t tid;
    pthread_create(&tid, NULL, &myThread, &stops);

    // aspetto 2 secondi e poi stop del thread
    mySleep(2000);
    stops.stop = 1;

    // detach del thread (in chiusura si può fare!)
    pthread_detach(tid);

    // simula una join con timeout
    int sleep_sum = 0;
    while (stops.stopped == 0) {
        // sleep di attesa
        mySleep(100);
        if ((sleep_sum += 100) > 1000) {
            // timeout scaduto: forzo l'uscita
            break;
        }
    }

    // esco
    printf("%s: esco (%s)\n", argv[0],
           sleep_sum > 1000 ? "con timeout" : "con Ok");
    return 0;
}

// myThread() - thread routine
void* myThread(void *arg)
{
    // recast degll'argomento
    Stops *stops = (Stops *)arg;

    // loop del thread
    printf("thread partito\n");
    while (stops->stop == 0) {
        // il thread fa cose...
        // ...

        // malloc sul buffer
        char *p = (char *)malloc(100);

        // simulo un ritardo perché il thread fa altre cose...
        mySleep(2);

        // free del buffer
        free(p);

        // sleep del thread (10 ms)
        mySleep(10);
    }

    // segnala lo stop avvenuto
    stops->stopped = 1;

    // il thread esce
    printf("thread finito\n");
    pthread_exit(NULL);
}

Questo ultimo caso è leggermente più complesso (ripeto: leggermente) perché bisogna passare un parametro complesso al thread (per comandare lo stop e controllare se è avvenuto) e bisogna simulare la pthread_timed_join_np(3) usando la pthread_detach(3) seguita da un loop di attesa del flag stopped. Come detto sopra non bisognerebbe quasi mai usare pthread_detach(3), ma in questo caso si può fare un eccezione visto che la chiamiamo quando il thread sta già chiudendo la sua attività.

Per oggi può bastare, nel prossimo articolo cambieremo argomento, non voglio più sentir parlare di pthread_cancel(3) per un po' di tempo... anzi, fosse per me la eliminerei, ma questo credo che si era capito (ah ah ah).

Ciao, e al prossimo post!