Joe (lo straniero): Chissà cosa diavolo c'è in quella diligenza.
Silvanito: Facile da sapere, ti ci avvicini e dai una guardatina dentro, se ti sparano addosso vuol dire che c'è oro.

Per la serie “battere il ferro finché è caldo” rimarremo ancora per un po’ sul tema dei Processi già affrontato negli ultimi due articoli (qui e qui) e parleremo di IPC, ossia di Comunicazione tra Processi (e, in particolare, ci soffermeremo sulla POSIX IPC). Questo sarà il primo di una serie, perché il tema è vasto, e merita un buon approfondimento. Dubito che riuscirò a scrivere qualcosa di memorabile come il primo episodio della Trilogia del dollaro citata nel titolo, però è sempre meglio avere delle buone fonti di ispirazione. E se a qualcuno non piacciono questi articoli gli mando a casa Joe (lo straniero) per convincerlo…

Allora: la comunicazione tra processi si può realizzare in varie maniere, vediamo una lista delle principali disponibili sui sistemi POSIX:

1. Message Queues – comunicazione tra due o più processi con capacità full duplex. I processi comunicheranno tra loro pubblicando un messaggio e recuperandolo dalla coda. Una volta recuperato, il messaggio non è più disponibile nella coda.
2. Shared Memory – la comunicazione tra due o più processi viene raggiunta attraverso un pezzo di memoria condiviso tra tutti i processi. La memoria condivisa deve essere protetta dagli accessi simultanei usando meccanismi di sincronizzazione.
3. FIFO (Named Pipe) – comunicazione tra due processi non correlati (ottenuti con fork + exec, per esempio). Come spiegato dal nome stesso, il mezzo usato è un file di tipo FIFO. È una comunicazione full duplex, il che significa che il primo processo può comunicare con il secondo processo e viceversa allo stesso tempo. Si può usare anche con processi correlati (ottenuti con fork senza exec), ma non ha molto senso: meglio usare la Anonymous Pipe in questo caso.
4. Pipe (Anonymous Pipe) – comunicazione tra due processi correlati (ottenuti con fork senza exec). Il meccanismo è half duplex che significa che il primo processo comunica con il secondo processo. Per ottenere un full duplex, e cioè permettere al secondo processo di comunicare con il primo processo, è necessaria un’altra pipe.
5. UNIX domain sockets (IPC socket) – comunicazione che usa i socket del Kernel (che non usano TCP/IP)
6. Internet domain socket (Network socket) – comunicazione che usa i socket di rete classici basati su TCP/IP.

Possiamo aggiungere qualche altro dettaglio: la POSIX Message Queue e la POSIX Shared Memory hanno degli equivalenti Unix System V: SysV Messages e SysV Shared Memory. Le versioni SysV sono concettualmente molto simili a quelle POSIX (che, tra l’altro, sono nate dopo, nel disegno di standardizzazione Single UNIX Specification). E poi esiste, ovviamente, anche la versione Windows di IPC, che in alcuni casi è abbastanza simile a quelle di POSIX e SysV (del resto Windows NT è nato molto tempo dopo UNIX, ed ha attinto molte idee da lì e da openVMS, ma questa è un altra storia…).

In questa serie di articoli ho deciso di analizzare solo le versioni POSIX perché hanno una API un po’ più user-friendly (e anche per non gettare troppa carne al fuoco). Comunque SysV IPC e Windows IPC sono nella lista degli articoli futuri, non vi preoccupate. È solo una questione di tempo…

Cercheremo, quindi, di mostrare, attraverso un codice chiaro e ben commentato, come implementare questi meccanismi di IPC e, al contempo, getteremo un occhio alle prestazioni. Vi preannuncio che in rete c’è molta documentazione sull’argomento, ma è difficile trovare un condensato dei vari metodi con inclusi anche i dettagli delle prestazioni. Quindi penso e spero che questi articoli saranno molto utili!

(…e dopo cotanta introduzione si allontana, sorridendo amabilmente, tra gli applausi del pubblico…)

E vediamo il piano dell’opera: della lista dei 6 punti qua sopra scarteremo il 4 (Pipe) perché l’obiettivo è la comunicazione più difficile, quella tra processi non correlati (amo il rischio). E scarteremo anche la 6 (Internet domain socket) perché tratteremo solo processi in esecuzione sulla stessa macchina, quindi sarebbe un controsenso usare i Network socket disponendo degli IPC socket.

Ho cercato di scrivere il codice delle varie versioni nella maniera più omogenea possibile, in maniera che i vari sorgenti siano quasi sovrapponibili. Inoltre, per poter confrontare i risultati, ho usato gli stessi metodi di scambio dati per tutte le versioni, quindi avremo un processo che scrive e uno che legge, con un tipo di comunicazione simile a quello usato nei classici esempi di Socket Server/Client che sicuramente avrete tutti già visto. Ho usato questo metodo anche per la Shared Memory: so che è un po improprio (il metodo migliore e più semplice è quello usato nell’ultimo articolo) ma si può fare…

Ok, da cosa cominciamo? Io direi dal meccanismo più classico, quello della Pipe, che ripete il metodo di comunicazione molto usato anche a livello user interface con la Pipe di  shell (e bash). E, sulla falsariga dell’articolo precedente, avremo i seguenti listati:

1. Il main di un processo padre (processes.c) che crea ed segue due processi figli con fork + exec. I due processi figli si chiameranno writer e reader.
2. Il main del processo writer (writer.c).
3. Il main del processo reader (reader.c).
4. Gli header file del caso e gli eventuali file di libreria.

Ok, cominciamo da processes.c: vai col codice!

// processes.c - main processo padre
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/types.h>
#include <sys/stat.h>
#include "data.h" // funzione main()
int main(int argc, char* argv[])
{ // creo il file fifo (named pipe) remove(FIFO_PATH); if (mkfifo(FIFO_PATH, DEFFILEMODE) == -1) { printf("%s: non posso creare il fifo (%s)\n", argv[0], strerror(errno)); exit(EXIT_FAILURE); } // crea i processi figli pid_t pid1, pid2; (pid1 = fork()) && (pid2 = fork()); // test pid processi if (pid1 == 0) { // sono il figlio 1 printf("sono il figlio 1 (%d): eseguo il nuovo processo\n", getpid()); char *pathname = "reader"; char *newargv[] = { pathname, NULL }; execv(pathname, newargv); exit(EXIT_FAILURE); // exec non ritorna mai } else if (pid2 == 0) { // sono il figlio 2 printf("sono il figlio 2 (%d): eseguo il nuovo processo\n", getpid()); char *pathname = "writer"; char *newargv[] = { pathname, NULL }; execv(pathname, newargv); exit(EXIT_FAILURE); // exec non ritorna mai } else if (pid1 > 0 && pid2 > 0) { // sono il padre printf("sono il padre (%d): attendo la terminazione dei figli\n", getpid()); int status; pid_t wpid; while ((wpid = wait(&status)) > 0) printf("sono il padre (%d): figlio %d terminato (%d)\n", getpid(), (int)wpid, status); // chiude il memory mapped file ed esce printf("%s: processi terminati\n", argv[0]); exit(EXIT_SUCCESS); } else { // errore nella fork() printf("%s: fork error (%s)\n", argv[0], strerror(errno)); exit(EXIT_FAILURE); }
}

Come avrete notato è quasi identico a quello visto nell’ultimo articolo, ma con due differenze fondamentali:

1. La prima operazione eseguita è la crezione del file FIFO (e cioè della Named Pipe) che sarà usata dai processi figli.
2. Il padre non forza più l’uscita dei figli dopo 10 secondi, ma ne attende solo la terminazione: i figli usciranno autonomamente per permetterci il test delle prestazioni.

E ora vediamo l’header file data.h che ci mostra il tipo di dati scambiati e definisce il path della Named Pipe:

#ifndef DATA_H
#define DATA_H // path del file fifo (named pipe)
#define FIFO_PATH "myfifo" // numero di messaggi da scambiare per il benchmark
#define N_MESSAGES 2000000 // struttura Data per i messaggi
typedef struct { unsigned long index; // indice dei dati char text[1024]; // testo dei dati
} Data; #endif /* DATA_H */

E adesso siamo pronti per vedere il codice di writer.c:

// writer.c - main processo figlio
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include "data.h" // funzione main()
int main(int argc, char *argv[])
{ // apro il file fifo (named pipe) in modo scrittura printf("processo %d partito\n", getpid()); int fd; if ((fd = open(FIFO_PATH, O_WRONLY)) == -1) { // errore socket() printf("%s: non posso aprire il fifo (%s)\n", argv[0], strerror(errno)); return EXIT_FAILURE; } // loop di scrittura messaggi per il reader Data my_data; my_data.index = 0; do { // test index per forzare l'uscita if (my_data.index == N_MESSAGES) { // il processo esce per indice raggiunto printf("processo %d terminato (text=%s index=%ld)\n", getpid(), my_data.text, my_data.index); close(fd); exit(EXIT_SUCCESS); } // compòngo il messaggio my_data.index++; snprintf(my_data.text, sizeof(my_data.text), "un-messaggio-di-test:%ld", my_data.index); } while (write(fd, &my_data, sizeof(Data)) != -1); // il processo esce per altro motivo (errore) printf("processo %d terminato con errore (%s)\n", getpid(), strerror(errno)); close(fd); exit(EXIT_FAILURE);
}

Anche questo codice è semplicissimo e auto-esplicativo: dopo aver aperto lo stesso file FIFO del padre esegue un loop di 2000000 (due milioni! Chi offre di più?) di write() del messaggio definito in data.h, dopodiché esce. Per ridurre all’osso l’attività della CPU e non falsare i risultati, si potrebbe omettere anche la snprintf() di ogni messaggio e aggiornare solo il campo index: ho fatto dei test e, come era prevedibile, la snprintf() locale è molto più` veloce della scrittura nella pipe, e quindi, praticamente, i risultati non vengono alterati. Notare che il loop pseudo-infinito prevede una uscita forzata del processo al raggiungimento del numero di scritture prestabilite. In caso di write error si ferma il loop anticipatamente e si va all’uscita generica di errore.

Ma si, dai, passiamo al reader!

// reader.c - main processo figlio
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <time.h>
#include <sys/time.h>
#include "data.h" // funzione main()
int main(int argc, char *argv[])
{ // apro il file fifo (named pipe) in modo lettura printf("processo %d partito\n", getpid()); int fd; if ((fd = open(FIFO_PATH, O_RDONLY)) == -1) { // errore di apertura printf("%s: non posso aprire il fifo (%s)\n", argv[0], strerror(errno)); return EXIT_FAILURE; } // set clock e time per calcolare il tempo di CPU e il tempo di sistema clock_t t_start = clock(); struct timeval tv_start; gettimeofday(&tv_start, NULL); // loop di lettura messaggi dal writer Data my_data; while (read(fd, &my_data, sizeof(Data)) > 0) { // test index per forzare l'uscita if (my_data.index == N_MESSAGES) { // set clock e time per calcolare il tempo di CPU e il tempo di sistema clock_t t_end = clock(); double t_passed = ((double)(t_end - t_start)) / CLOCKS_PER_SEC; struct timeval tv_end, tv_elapsed; gettimeofday(&tv_end, NULL); timersub(&tv_end, &tv_start, &tv_elapsed); // il processo esce per indice raggiunto printf("reader: ultimo messaggio ricevuto: %s\n", my_data.text); printf("processo %d terminato (index=%ld CPU time elapsed: %.3f - total time elapsed:%ld.%ld)\n", getpid(), my_data.index, t_passed, tv_elapsed.tv_sec, tv_elapsed.tv_usec / 1000); close(fd); exit(EXIT_SUCCESS); } } // il processo esce per altro motivo (errore) printf("processo %d terminato localmente (text=%s index=%ld read error=%s)\n", getpid(), my_data.text, my_data.index, strerror(errno)); close(fd); return EXIT_FAILURE;
}

Il reader è strutturalmente identico (e speculare) al writer, quindi il loop di lettura ha due possibili uscite (forzata e per errore), ed esegue simmetricamente le stesse operazioni, solo che legge invece di scrivere. Ed ha in più la gestione del calcolo dei tempi di esecuzione, che ci servono per effettuare il benchmark che ci eravamo proposti.

In definitiva si puo` affermare che la IPC attraverso Named Pipe è veramente semplice da implementare, perchè è pura attività di read/write su un file. Tutto Ok, quindi… e i risultati? Il test l’ho effettuato su una macchina Linux (Kernel 5.4.0) con un i7 (4 core/8 thread) con 8GB di RAM. Visto che è il primo test non voglio anticiparvi se le prestazioni sono buone o cattive (spoiler: sono buone), comunque vediamo:

sono il padre (6850): attendo la terminazione dei figli
sono il figlio 1 (6851): eseguo il nuovo processo
sono il figlio 2 (6852): eseguo il nuovo processo
processo 6851 partito
processo 6852 partito
processo 6852 terminato (text=un-messaggio-di-test:2000000 index=2000000)
reader: ultimo messaggio ricevuto: un-messaggio-di-test:2000000
processo 6851 terminato (index=2000000 CPU time elapsed: 1.732 - total time elapsed:1.747)
sono il padre (6850): figlio 6851 terminato (0)
sono il padre (6850): figlio 6852 terminato (0)
./processes: processi terminati

Allora: il nostro test mostra che, usando la POSIX Named Pipe, abbiamo scambiato due milioni di messaggi tra i due processi in 1.732 secondi (quindi un messaggio ogni 0,87 us). Notare che non ho scritto nessuna ottimizzazione del sistema di lettura/scrittura: anche se i messaggi sono corti (“un-messaggio-di-test:nnnn”) si spediscono ugualmente sizeof(Data) byte (sono ben 1032 byte): ottimizzando per spedire solo il minimo necessario sarebbe ancora più veloce (spoiler: scriverò, prima o poi, un articolo sull’argomento). Nei prossimi post vedremo codice e risultati delle altre POSIX IPC in analisi: vi preannuncio che sarà molto interessante, ma non trattenete il respiro nell’attesa, mi raccomando…

Ciao, e al prossimo post!

https://italiancoders.it/per-un-pugno-di-ipc-considerazioni-sulle-prestazioni-della-posix-ipc-pt-1/