Thread Ringers come usare i thread in C - pt.2

Dove eravamo rimasti? Ah, si: nella prima parte di Dead Ringers (oops... Thread Ringers) avevamo introdotto l'argomento thread parlando della base, e cioè i POSIX Threads. Ora, come promesso, tenteremo di scrivere lo stesso esempio dello scorso post usando una interfaccia alternativa, e cioè i C11 Threads.

...ti spiego: io sono un POSIX thread e tu un C11 thread...

Una premessa che parte dal lato oscuro della forza (va beh, il C++): il committee ISO del C++ decise di introdurre, nella versione C++11, i thread all'interno del linguaggio. Quindi niente più uso diretto dei POSIX Threads attraverso (ad esempio) la libreria libpthread, ma uso diretto di costrutti del linguaggio. La realizzazione finale è stata (secondo me) brillante, ed i C++11 Threads sono una delle poche cose del C++11 che uso frequentemente (e già sapete cosa ne penso della brutta deriva del C++ pilotata dal committee ISO, se no andate a rileggervi quel post). Il committee ISO del C non poteva rimanere indietro, e quindi hanno pensato di fare la stessa cosa con il C11, quindi i thread adesso fanno direttamente parte del C... o no? Vi anticipo una considerazione: ho una stima del committee ISO del C maggiore di quella che ho del committee ISO del C++ (e non ci voleva molto...), ma in questo caso devo proprio dire che non ci siamo: a seguire vedremo perché.

Come sono stati pensati i nuovi C11 Threads? Allora, hanno preso tutte le funzioni e variabili che compongono i POSIX Threads e gli hanno cambiato il nome (e devo ammettere che quelli nuovi sono più semplici); inoltre, in alcuni casi (pochi, per fortuna), hanno cambiato i tipi dei codici di ritorno e degli argomenti delle funzioni. Punto. Geniale? Non proprio direi, e niente a che vedere con la soluzione brillante usata nel C++11. Motivi per usare questa nuova versione? Zero, direi, e non vi ho ancora esposto il problema principale...

Comunque, ho riscritto l'esempio dello scorso post usando i C11 Threads. Vai col codice!

#include <stdio.h>
#include <threads.h>
#include <string.h>
#include <unistd.h>

// creo un nuovo tipo per passare dei dati ai threads
typedef struct _tdata {
    int   index;      // thread index
    int   *comdata;   // dato comune ai threads
    mtx_t *lock;      // mutex comune ai threads
} tdata;

// prototipi locali
int tMyThread(void *arg);

// funzione main()
int main(int argc, char* argv[])
{
    int error;

    // init mutex
    mtx_t lock;
    if ((error = mtx_init(&lock, mtx_plain)) != thrd_success) {
        printf("%s: non posso creare il mutex (error=%d)\n", argv[0],  error);
        return 1;
    }

    // init threads
    thrd_t tid[2];
    tdata  data[2];
    int    comdata = 0;
    for (int i = 0; i < 2; i++) {
        // set data del thread e crea il thread
        data[i].index   = i;
        data[i].comdata = &comdata;
        data[i].lock    = &lock;
        if ((error = thrd_create(&tid[i], tMyThread, &data[i])) != thrd_success)
            printf("%s: non posso creare il thread %d (error=%d)\n", argv[0], i, error);
    }

    // join threads e cancella mutex
    thrd_join(tid[0], NULL);
    thrd_join(tid[1], NULL);
    mtx_destroy(&lock);

    // exit
    printf("%s: thread terminati: comdata=%d\n", argv[0], comdata);
    return 0;
}

// thread routine
int tMyThread(void *arg)
{
    // ottengo i dati del thread con un cast (tdata *) di (void *) arg
    tdata *data = (tdata *)arg;

    // thread loop
    printf("thread %d partito\n", data->index);
    int i = 0;
    for (;;) {
        // lock mutex
        mtx_lock(data->lock);

        // incrementa comdata
        (*data->comdata)++;

        // unlock mutex
        mtx_unlock(data->lock);

        // test counter per eventuale uscita dal loop
        if (++i >= 100) {
            // esce dal loop
            break;
        }

        // thread sleep (10 ms)
        usleep(10000);
    }

    // il thread esce
    printf("thread %d finito\n", data->index);
    return 0;
}

Come vedete il codice è praticamente identico, mi sono limitato a usare le nuove funzioni al posto di quelle vecchie (per esempio thrd_create() invece di pthread_create()), ho usato i nuovi tipi (per esempio mtx_t invece di pthread_mutex_t) e ho leggermente modificato il test dei valori di ritorno: poche differenze, devo dire, e, in alcuni casi, in peggio: ad esempio è sparito il parametro attr di pthread_create(), che (per semplicità) nello scorso esempio avevo lasciato a NULL, ma che a volte può risultare utile (leggere il manuale di pthread_create() per rendersene conto). Comunque si potrebbe dire (senza fare troppo gli schizzinosi) che la nuova interfaccia non ci offre nessun vantaggio sostanziale, ma neanche un peggioramento decisivo, quindi si potrebbe anche usare (de gustibus).

Ma cè un problema: pare che i C11 Threads non siano considerati una priorità per chi scrive i compilatori e le varie libc, quindi attualmente è difficile compilare/eseguire un programma come quello che ho mostrato. Perfino il nostro amato GCC (che di solito è il primo a fornire supporto per le ultime novità) non supporta i nuovi thread (in realtà a causa della mancata integrazione nella glibc). Quindi, se proprio volete usarli a tutti i costi, dovrete aspettare che qualche compilatore/libreria fornisca il supporto completo, oppure, ad esempio, usare la libreria c11threads che non è altro che un wrapper che simula i C11 Threads usando i POSIX Threads.

Io, alla fine, ho compilato l'esempio usando quella che (credo) sia la soluzione più interessante attualmente disponibile: ho installato nel mio sistema la musl libc che è una libc alternativa alla glibc, ed è dotata di un wrapper per GCC (musl-gcc): musl fornisce (su Linux) il supporto completo al C11, thread inclusi. Una volta compilato il programma si comporta correttamente, come potete vedere qui sotto:

aldo@ao-linux-nb:~/blogtest$ musl-gcc c11thread.c -o c11thread
aldo@ao-linux-nb:~/blogtest$ ./c11thread 
thread 0 partito
thread 1 partito
thread 1 finito
thread 0 finito
./c11thread: thread terminati: comdata=200

Ma il gioco vale la candela? No, per quel che mi riguarda continuerò ad usare i POSIX Threads, che uso da anni e rimangono il riferimento d'eccellenza. Ed un ultimo appunto: a prescindere da quello che stiamo usando (C11/C++11 threads) è molto probabile che, sotto sotto, ci siano i POSIX Threads (è vero in molte implementazioni). E se quando compilate dovete aggiungere il flag -pthread allora il dubbio diventa una certezza, visto che con questo flag usate libpthread ovvero la libreria dei POSIX Threads. Meditate gente, meditate...

Ciao e al prossimo post!

Thread Ringers come usare i thread in C - pt.1

I thread sono un po' come i gemelli del capolavoro del grande David Cronenberg: hanno la stessa origine, sembrano uguali ma sono diversi.

...ti spiego: io sono il thread A e tu sei il B...

In questo post (che è il primo di una breve serie) vedremo un esempio semplice semplice di come usare i thread in C: ovviamente l'argomento è molto vasto e complicabile a piacere, ma il nostro esempio contiene già le basi per capire come funziona il tutto, ovvero: la creazione, la sincronizzazione e la distruzione dei thread. Ovviamente in questa prima parte cominceremo usando la versione base (quasi) universale, ovvero useremo i POSIX Threads. E ora bando alle ciance, vai col codice!

#include <stdio.h>
#include <pthread.h>
#include <string.h>
#include <unistd.h>

// creo un nuovo tipo per passare dei dati ai thread
typedef struct _tdata {
    int             index;      // thread index
    int             *comdata;   // dato comune ai thread
    pthread_mutex_t *lock;      // mutex comune ai thread
} tdata;

// prototipi locali
void* tMyThread(void *arg);

// funzione main()
int main(int argc, char* argv[])
{
    int error;

    // init mutex
    pthread_mutex_t lock;
    if ((error = pthread_mutex_init(&lock, NULL)) != 0) {
        printf("%s: non posso creare il mutex (%s)\n", argv[0],  strerror(error));
        return 1;
    }

    // init threads
    pthread_t tid[2];
    tdata     data[2];
    int       comdata = 0;
    for (int i = 0; i < 2; i++) {
        // set data del thread e crea il thread
        data[i].index   = i;
        data[i].comdata = &comdata;
        data[i].lock    = &lock;
        if ((error = pthread_create(&tid[i], NULL, &tMyThread, (void *)&data[i])) != 0)
            printf("%s: non posso creare il thread %d (%s)\n", argv[0], i, strerror(error));
    }

    // join thread e cancella mutex
    pthread_join(tid[0], NULL);
    pthread_join(tid[1], NULL);
    pthread_mutex_destroy(&lock);

    // exit
    printf("%s: thread terminati: comdata=%d\n", argv[0], comdata);
    return 0;
}

// thread routine
void* tMyThread(void *arg)
{
    // ottengo i dati del thread con un cast (tdata*) di (void*) arg
    tdata *data = (tdata *)arg;

    // thread loop
    printf("thread %d partito\n", data->index);
    int i = 0;
    for (;;) {
        // lock mutex
        pthread_mutex_lock(data->lock);

        // incrementa comdata
        (*data->comdata)++;

        // unlock mutex
        pthread_mutex_unlock(data->lock);

        // test counter per eventuale uscita dal loop
        if (++i >= 100) {
            // esce dal loop
            break;
        }

        // thread sleep (10 ms)
        usleep(10000);
    }

    // il thread esce
    printf("thread %d finito\n", data->index);
    return NULL;
}

Ok, come vedete è ampiamente commentato e quindi è auto-esplicativo, per cui non mi dilungherò sulle singole istruzioni e/o gruppi di istruzioni (leggete i commenti! sono li per quello!), ma aggiungerò, solo, qualche dettaglio strutturale. Supponendo che già sappiate cosa sono e a cosa servono i thread (se no leggetevi prima qualche guida introduttiva, in rete ce ne sono di ottime) il flusso del codice è evidente: prima bisogna creare un mutex (con pthread_mutex_init()) per sincronizzare i thread che useremo, poi bisogna inizializzare i dati da passare ai thread e creare (con pthread_create()) i due thread del nostro esempio (init dati e creazione li ho messi in un loop di 2, ma si potevano anche scrivere ripetendo due volte i passi, ovviamente). Infine il main() si mette in attesa (con pthread_join()) della terminazione dei thread e, quando sono terminati, distrugge il mutex (con pthread_mutex_destroy()) ed esce.

Come si nota pthread_create() ha quattro parametri, che sono (nell'ordine): un pointer a un thread descriptor che identifica univocamente il thread creato, un pointer a un contenitore di attributi del thread da creare, un function pointer alla funzione che esegue il thread e, infine, un pointer all'unico argomento che si può passare alla funzione suddetta. In particolare, nel nostro esempio (semplice semplice), ho usato gli attributi di default (usando NULL per il secondo parametro), e ho creato (con typedef) un nuovo tipo ad-hoc per passare più parametri alla funzione che esegue il thread, sfruttando il fatto che l'argomento di default è un void* che si può facilmente trasformare (con una operazione di cast) in qualsiasi tipo complesso (nel nostro caso nel nuovo tipo tdata).

In questo esempio i due thread creati eseguono la stessa funzione, che ho chiamato tMyThread() (ma avrebbero anche potuto eseguire due funzioni completamente differenti: in questo caso, ovviamente, avrei dovuto scrivere una tMyThread1() e una tMyThread2()). Il flusso della funzione è molto semplice: prima esegue un cast sull'argomento arg per poter usare i dati del tipo tdata, poi entra in un classico thread-loop infinito con uscita forzata: nel nostro caso esce quando l'indice i arriva a 100, ma in un caso reale si potrebbe, per esempio, forzare l'uscita solo in caso di errore. Notare che il thread-loop usa una sleep di 10 ms (usando usleep()): provate a dimenticarvi di mettere la sleep in un thread-loop veramente infinito e vedrete i salti di gioia che farà la CPU del vostro PC!

Come si nota il tipo tdata contiene un indice tipico del thread (nel nostro caso è 0 o 1) e i pointer ai due dati comuni (locali al main()) che sono comdata e lock. Quindi cosa esegue il thread-loop? Visto che è un esempio semplice, si limita a incrementare il dato comune comdata inizializzato nel main() e lo fa in maniera sincronizzata usando pthread_mutex_lock() e pthread_mutex_unlock() sul mutex comune lock: questo serve per evitare che i due thread accedano contemporaneamente a comdata.

Compilando con GCC su macchina Linux (ovviamente) ed eseguendo, il risultato è:

aldo@ao-linux-nb:~/blogtest$ gcc thread.c -o thread -pthread
aldo@ao-linux-nb:~/blogtest$ ./thread 
thread 0 partito
thread 1 partito
thread 1 finito
thread 0 finito
./thread: thread terminati: comdata=200

Che è quello sperato. Nel prossimo post parleremo di una interfaccia alternativa ai POSIX Threads. E, come sempre, vi raccomando di non trattenere il respiro nell'attesa...

Ciao e al prossimo post!

P.S.
Come ben sapete questo è un blog di programmazione con un anima cinefila, per cui vi segnalo (con grande tristezza) che il mese scorso ci ha lasciati un grande maestro. R.I.P., George.

Il buono, il brutto, il VLA come usare i Variable Length Arrays in C - pt.3

Eccoci, e, come promesso, questo mese parleremo di un parente stretto dei VLAs, ovvero della funzione alloca()... sarà un buono, un brutto o un cattivo?

ciao, sono lo spoiler di questo post!

Allora, ho aggiunto il codice al programma di test per provare la alloca(). E, per non farci mancare niente, ho aggiunto anche del codice per provare la malloc() del C++, ovvero la new (dopo il problematico test di std::vector dello scorso post era doveroso completare il discorso con con qualcosa di più prestante, mica che si dica che ce l'ho con il C++...). Quindi useremo il programma C++ dello scorso post (tanto era praticamente identico alla versione C): vi riporto nuovamente il main() e le due funzioni di test aggiunte (per ricostruire il programma completo basta consultare i due post precedenti e fare un po' di cut-and-paste). Vai col codice!

#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <vector>

#define MYSIZE  1000000

// variabile dummy per evitare lo svuotamento totale delle funzioni usando GCC -O2
int avoid_optimization;

// prototipi locali
void testVLA(int size);
void testMallocVLA(int size);
void testStackFLA(int dum);
void testHeapFLA(int dum);
void testAllocaVLA(int size);
void testVectorVLA(int size);
void testNewVLA(int size);
void runTest(int iterations, void (*funcptr)(int), int size, const char *name);

// funzione main()
int main(int argc, char* argv[])
{
    // test argomenti
    if (argc != 2) {
        // errore: conteggio argomenti errato
        printf("%s: wrong arguments counts\n", argv[0]);
        printf("usage: %s vla iterations [e.g.: %s 10000]\n", argv[0], argv[0]);
        return EXIT_FAILURE;
    }

    // estrae iterazioni
    int iterations = atoi(argv[1]);

    // esegue test
    runTest(iterations, &testVLA, MYSIZE, "testVLA");
    runTest(iterations, &testMallocVLA, MYSIZE, "testMallocVLA");
    runTest(iterations, &testStackFLA, 0, "testStackFLA");
    runTest(iterations, &testHeapFLA, 0, "testHeapFLA");
    runTest(iterations, &testAllocaVLA, MYSIZE, "testAllocaVLA");
    runTest(iterations, &testVectorVLA, MYSIZE, "testVectorVLA");
    runTest(iterations, &testNewVLA, MYSIZE, "testNewVLA");

    // esce
    return EXIT_SUCCESS;
}

// funzione testAllocaVLA()
void testAllocaVLA(
    int size)       // size per alloca()
{
    int *allocavla = (int*)alloca(size * sizeof(int));

    // loop di test
    for (int i = 0; i < size; i++)
        allocavla[i] = i;

    // istruzione per evitare lo svuotamento totale della funzione usando GCC -O2
    avoid_optimization = allocavla[size / 2];
}

// funzione testNewVLA()
void testNewVLA(
    int size)       // size per new
{
    int *newvla = new int[size];

    // loop di test
    for (int i = 0; i < size; i++)
        newvla[i] = i;

    // istruzione per evitare lo svuotamento totale della funzione usando GCC -O2
    avoid_optimization = newvla[size / 2];

    delete[] newvla;
}

Come potete vedere, le due funzioni aggiunte sono perfettamente allineate stilisticamente con le altre che avevo già proposto e sono, come sempre, iper-commentate, così non devo neanche dilungarmi in spiegazioni. E i risultati del test? Vediamoli!

aldo@ao-linux-nb:~/blogtest$ g++ vlacpp.cpp -o vlacpp
aldo@ao-linux-nb:~/blogtest$ ./vlacpp 2000
testVLA       -  Tempo trascorso: 4.318492 secondi
testMallocVLA -  Tempo trascorso: 3.676805 secondi
testStackFLA  -  Tempo trascorso: 4.339859 secondi
testHeapFLA   -  Tempo trascorso: 4.340040 secondi
testAllocaVLA -  Tempo trascorso: 3.678644 secondi
testVectorVLA -  Tempo trascorso: 10.934088 secondi
testNewVLA    -  Tempo trascorso: 3.679624 secondi
aldo@ao-linux-nb:~/blogtest$ g++ -O2 vlacpp.cpp -o vlacpp
aldo@ao-linux-nb:~/blogtest$ ./vlacpp 2000
testVLA       -  Tempo trascorso: 0.746956 secondi
testMallocVLA -  Tempo trascorso: 0.697261 secondi
testStackFLA  -  Tempo trascorso: 0.696310 secondi
testHeapFLA   -  Tempo trascorso: 0.700047 secondi
testAllocaVLA -  Tempo trascorso: 0.691677 secondi
testVectorVLA -  Tempo trascorso: 1.384563 secondi
testNewVLA    -  Tempo trascorso: 0.695037 secondi

Allora, cosa si può dire? I risultati dei test dei post precedenti li abbiamo già ampliamene commentati, quindi ora possiamo solo aggiungere che: alloca() è molto veloce, visto che è, in pratica, una malloc() nello stack (e, usandola in maniera appropriata, potrebbe/dovrebbe essere la più veloce del gruppo). E la new? Beh, si comporta (come previsto) benissimo, anche perché, quasi sempre, la new usa internamente la malloc().

Va bene, la alloca() è veloce, ma lo è (solo un po' meno) anche un VLA, e questo non lo ha salvato dal essere eletto come cattivo del film. Quindi dovremo fare di nuovo una lista di pro e contro, e vedere quale parte è più pesante. Vediamo prima i pro:

1. la alloca() è molto veloce, già che usa lo stack invece del heap.
2. la alloca() è facile da usare, è una malloc() senza free(). La variabile allocata ha uno scope a livello di funzione, quindi rimane valida fino a quando la funzione ritorna al chiamante, esattamente come una qualsiasi variabile automatica locale (anche un VLA funziona più o meno così, ma il suo scope è a livello di blocco, non di funzione, e questo è, probabilmente, un punto a favore dei VLAs).
3. per il motivo visto al punto 2 la alloca() non lascia in giro residui di memoria in caso di errori gravi nella attività di una funzione (e con malloc() + free() non è altrettanto facile realizzare questo). Se poi siete soliti a usare cosucce come longjmp() i vantaggi in questo senso sono grandissimi.
4. a causa della sua implementazione interna (senza entrare in dettagli profondi) la alloca() non causa frammentazione della memoria.

Uh, che bello! E i contro?

1. la gestione degli errori è problematica, perché non c'è maniera di sapere se alloca() ha allocato bene o ha provocato un stack overflow (in questo caso provoca effetti simili a quelli di un errore per ricorsione infinita)... uh, questo è esattamente lo stesso problema dei VLAs.
2. la alloca() non è molto portatile, visto che non è una funzione standard e il suo funzionamento/presenza dipende molto dal compilatore in uso.
3. la alloca() è error prone (parte 1): bisogna usarla con attenzione, visto che induce, tipicamente, a errori come usare la variabile allocata quando oramai non è più valida (passarla con un return o inserirla dentro una struttura dati esterna alla funzione, per esempio)... ma noi siamo ottimi programmatori e questo punto non ci spaventa, no?
4. la alloca() è error prone (parte 2): ci sono problemi ancora più sottili da considerare nell'uso, ad esempio può risultare MOLTO pericoloso mettere una alloca() dentro un loop o in una funzione ricorsiva  (povero stack!) o in una funzione inline (che usa lo stack in una maniera che si scontra un po' con la maniera di usare lo stack della alloca())... ma noi siamo ottimi programmatori e questo punto non ci spaventa, no?
5. la alloca() è error prone (parte 3): la alloca() usa lo stack, che è normalmente limitato rispetto allo heap (specialmente negli ambienti embedded che sono molto frequentati dai programmatori C...). Quindi esaurire lo stack e provocare uno stack overflow è facile (e difficile da controllare, vedi il punto 1)... ma noi siamo ottimi programmatori e questo punto non ci spaventa, no?

Va beh, conclusioni? Ci sarebbero gli estremi per dichiarare la alloca() come un altro cattivo (stessa sorte del VLA), ma, dati i notevoli pro e, soprattutto, dato che oggi sono di buon umore, la dichiareremo solo come brutto (visto lo spoiler nella figura qui sopra?). Comunque usate la alloca() con molta cautela, uomo avvisato mezzo salvato!

Ciao e al prossimo post!