Esercizio - Thread e mutex in RIOT con un buffer condiviso (laboratorio 12)

Nota. I programmi di questa pagina non sono stati compilati in questo lavoro: servono il sorgente di RIOT 2023.04 e la toolchain AVR. Il codice segue le istruzioni del laboratorio e le API documentate; va provato nella macchina virtuale del corso con make BOARD=arduino-mega2560 RIOTBASE=… e il simulatore Wokwi (vedi Esercizio - Shell di RIOT con i comandi board, cpu ed echo (laboratorio 11)).

Task 1: i thread con ps

Nel Makefile si caricano i moduli:

USEMODULE += shell
USEMODULE += shell_cmds_default
USEMODULE += ps

shell_cmds_default costruisce i comandi di shell forniti dagli altri moduli, e ps fornisce il comando che mostra l'attività dei thread. In main si avvia la shell (shell_run(NULL, line_buf, SHELL_DEFAULT_BUFSIZE)); con help si vedono i comandi e ps elenca i thread: all'inizio ci sono il main e l'idle.

Nuovo thread. Servono: l'inclusione di thread.h, la memoria dello stack del thread (dichiarata globale), una funzione che contiene il codice del thread e la chiamata thread_create:

#include <stdio.h>

#include "shell.h"
#include "thread.h"

static char stack[THREAD_STACKSIZE_MAIN];

static void *thread_handler(void *arg)
{
    (void)arg;
    puts("Hello from thread!");
    return NULL;
}

int main(void)
{
    /* il thread va creato PRIMA della shell: shell_run non ritorna mai */
    thread_create(stack, sizeof(stack), THREAD_PRIORITY_MAIN - 1,
                  0, thread_handler, NULL, "new thread");

    char line_buf[SHELL_DEFAULT_BUFSIZE];
    shell_run(NULL, line_buf, SHELL_DEFAULT_BUFSIZE);
    return 0;
}

Gli argomenti di thread_create: stack, sua dimensione, priorità, flag, funzione del thread, argomento della funzione, nome. Con la priorità THREAD_PRIORITY_MAIN - 1 (più alta di quella del main: in RIOT un numero più basso significa priorità più alta), il thread parte subito, stampa "Hello from thread!" prima dell'avvio della shell e termina: con ps non si vede, perché è già uscito.

Thread in background. Per vederlo con ps bisogna fare due cose: impedirgli di terminare (un ciclo infinito) e dargli una priorità più bassa del main:

static void *thread_handler(void *arg)
{
    (void)arg;
    while (1) { /* busy loop */ }
    return NULL;
}

/* nel main: */
thread_create(stack, sizeof(stack), THREAD_PRIORITY_MAIN + 1,
              0, thread_handler, NULL, "new thread");

Con THREAD_PRIORITY_MAIN + 1 (priorità minore di quella del main) il thread è elencato da ps e risulta in attesa (pending: pronto, ma non in esecuzione). Lo scheduler è a priorità fisse con prelazione: ogni volta che il thread principale ha bisogno della CPU (per esempio per eseguire ps) prevale su quello a priorità minore, che quindi non avanza mentre il main lavora; la slide del corso riassume dicendo che "non è mai partito". Se il thread con il ciclo infinito avesse priorità più alta, monopolizzerebbe la CPU e la shell non risponderebbe più (a priorità diverse un thread alto che non cede non viene interrotto da uno più basso). Vedi lo scheduler di RIOT nella teoria.

Task 2: il mutex

Si aggiungono i moduli ztimer e ztimer_msec (timer a millisecondi):

USEMODULE += ztimer
USEMODULE += ztimer_msec

Il codice (struttura data_t con il buffer e il mutex, stack del thread scrittore, thread scrittore, e il lettore nel main):

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

#include "thread.h"
#include "ztimer.h"
#include "mutex.h"

typedef struct {
    char buffer[128];
    mutex_t lock;
} data_t;

static data_t data;
static char writer_stack[THREAD_STACKSIZE_MAIN];

static void *writer_thread(void *arg)
{
    (void)arg;
    while (1) {
        mutex_lock(&data.lock);                          /* 1) prendere il mutex */
        int p = sprintf(data.buffer, "%s", "one");        /* 2) scrivere, lentamente */
        ztimer_sleep(ZTIMER_MSEC, 50);
        sprintf(&data.buffer[p], "%s", " two");
        mutex_unlock(&data.lock);                        /* 3) rilasciarlo */

        ztimer_sleep(ZTIMER_MSEC, 100);
    }
    return NULL;
}

int main(void)
{
    puts("RIOT application with thread safe concurrency");

    thread_create(writer_stack, sizeof(writer_stack), THREAD_PRIORITY_MAIN - 1,
                  0, writer_thread, NULL, "writer thread");

    while (1) {
        mutex_lock(&data.lock);                          /* il lettore accede solo col mutex */
        printf("%s\n", data.buffer);
        mutex_unlock(&data.lock);

        ztimer_sleep(ZTIMER_MSEC, 250);
    }
    return 0;
}

(data è una variabile globale, quindi inizializzata a zero: è anche lo stato "libero" di un mutex_t.)

Come si legge la traccia.

1. Lo scrittore ha priorità più alta del main: appena creato, prende il mutex e scrive one; poi dorme 50 ms tenendo il mutex.
2. Il main (lettore) tenta di prendere il mutex: si blocca finché lo scrittore non lo rilascia, poi legge one two: sempre una stringa completa.
3. Lo scrittore dorme 100 ms (senza mutex), il lettore stampa e dorme 250 ms; nei periodi successivi gli accessi si alternano allo stesso modo.

Senza mutex (togliendo tutte le chiamate mutex_lock e mutex_unlock): quando lo scrittore dorme i 50 ms a metà scrittura, il buffer contiene solo one (la scrittura riparte sempre da sprintf(data.buffer, "%s", "one"), che azzera il resto): se il lettore stampa in quel momento, vede one invece di one two: contenuto incompleto, come si verifica nel simulatore. La sezione critica è proprio la sequenza "scrivi one, attendi, scrivi two" insieme alla lettura del buffer.

Compito: shell con avvio e arresto

Idea: la shell nel thread principale, due thread (scrittore e lettore) che controllano un flag condiviso attivo; il comando print on lo mette a vero, print off a falso. I thread restano sempre creati (RIOT non ha un comando semplice per "fermare" un thread dall'esterno) e quando attivo è falso, non fanno niente.

#include <stdio.h>
#include <string.h>
#include <stdbool.h>

#include "shell.h"
#include "thread.h"
#include "mutex.h"
#include "ztimer.h"

typedef struct {
    char buffer[128];
    mutex_t lock;
} data_t;

static data_t data;
static volatile bool attivo = false; /* scritto dalla shell, letto dai due thread */
static char writer_stack[THREAD_STACKSIZE_MAIN];
static char reader_stack[THREAD_STACKSIZE_MAIN];

static void *writer_thread(void *arg)
{
    (void)arg;
    while (1) {
        if (attivo) {
            mutex_lock(&data.lock);
            int p = sprintf(data.buffer, "%s", "one");
            ztimer_sleep(ZTIMER_MSEC, 50);
            sprintf(&data.buffer[p], "%s", " two");
            mutex_unlock(&data.lock);
        }
        ztimer_sleep(ZTIMER_MSEC, 100);
    }
    return NULL;
}

static void *reader_thread(void *arg)
{
    (void)arg;
    while (1) {
        if (attivo) {
            mutex_lock(&data.lock);
            printf("%s\n", data.buffer);
            mutex_unlock(&data.lock);
        }
        ztimer_sleep(ZTIMER_MSEC, 250);
    }
    return NULL;
}

static int _print_handler(int argc, char **argv)
{
    if (argc == 2 && strcmp(argv[1], "on") == 0) {
        attivo = true;
    }
    else if (argc == 2 && strcmp(argv[1], "off") == 0) {
        attivo = false;
    }
    else {
        puts("usage: print on|off");
        return 1;
    }
    return 0;
}

static const shell_command_t shell_commands[] = {
    { "print", "Start (on) or stop (off) writer and reader threads", _print_handler },
    { NULL, NULL, NULL }
};

int main(void)
{
    thread_create(writer_stack, sizeof(writer_stack), THREAD_PRIORITY_MAIN - 1,
                  0, writer_thread, NULL, "writer");
    thread_create(reader_stack, sizeof(reader_stack), THREAD_PRIORITY_MAIN - 1,
                  0, reader_thread, NULL, "reader");

    char line_buf[SHELL_DEFAULT_BUFSIZE];
    shell_run(shell_commands, line_buf, SHELL_DEFAULT_BUFSIZE);
    return 0;
}

Punti da notare: attivo è volatile perché è modificata da un thread e letta da altri (il compilatore non deve tenerla in un registro); entrambi i thread dormono (ztimer_sleep) a ogni ciclo, quindi cedono la CPU (a pari priorità in RIOT non c'è prelazione fra thread: ognuno gira finché non cede). Con print off lo scrittore, se sta scrivendo, finisce prima la scrittura (il mutex è tenuto), poi smette. Nel Makefile servono shell, ztimer, ztimer_msec (e, se si vuole controllare con ps, shell_cmds_default e ps).

Errori tipici

• Creare il thread dopo shell_run: non viene mai eseguito.
• Dimenticare lo stack globale: uno stack locale sparisce all'uscita della funzione che crea il thread.
• Confondere le priorità: in RIOT un numero minore è più prioritario; THREAD_PRIORITY_MAIN + 1 è meno prioritario.
• Scrivere o leggere il buffer senza il mutex: si vede un contenuto incompleto.
• Tenere il mutex durante la sleep del lettore (o dimenticare di rilasciarlo): blocca lo scrittore.