Processi e Concorrenza nei Sistemi Distribuiti

Transcript

1 Università degli Studi di Roma Tor Vergata Dipartimento di Ingegneria Civile e Ingegneria Informatica Processi e Concorrenza nei Sistemi Distribuiti Corso di Sistemi Distribuiti e Cloud Computing A.A. 2016/17 Valeria Cardellini Processi nei SD Sistema distribuito: composto da un insieme di processi in esecuzione su più nodi del sistema I processi possono comunicare, sincronizzarsi e cooperare con le stesse modalità sia se sono in esecuzione su nodi remoti, sia sullo stesso nodo Algoritmo distribuito: algoritmo eseguito da un insieme {P 1, P 2,, P n } dove P i è un processo Nessun processo conosce lo stato attuale dell intero sistema I processi basano le proprie decisioni sui dati che possiedono Il fallimento di un processo non dovrebbero compromettere lo scopo dell algoritmo Valeria Cardellini - SDCC 2016/17 1

2 Processori, processi e thread Costruire processori virtuali a livello software, al di sopra dei processori fisici Processore: fornisce un insieme di istruzioni, con la capacità di eseguire una sequenza di queste istruzioni Thread: processore software minimale nel cui contesto può essere eseguita una sequenza di istruzioni Eseguire un thread: eseguire una sequenza di istruzioni nel contesto di quel thread Salvare il contesto del thread: interrompere l esecuzione corrente e salvare tutti i dati necessari a continuarne l esecuzione successivamente Processo: processore software nel cui contesto possono essere eseguiti uno o più thread Valeria Cardellini - SDCC 2016/17 2 Processi e thread in Unix Processo Unix Thread in un processo Unix Valeria Cardellini - SDCC 2016/17 3

3 Processi e thread a confronto Cambio di contesto più costoso tra processi: occorre salvare tutte le informazioni richieste nel descrittore di processo Creazione e distruzione di thread: molto meno costosa Gestione di thread: richiede meno risorse di sistema Valeria Cardellini - SDCC 2016/17 4 Thread vs process creation time Creation of processes/threads (time in sec) - Thead creation is around 1 order of magnitude faster than process creation Source: Valeria Cardellini - SDCC 2016/17 5

4 Processi e thread a confronto (3) I processi offrono trasparenza alla concorrenza, ma ad un costo relativamente alto in termini di prestazioni Meccanismi di Inter-Process Communication (IPC): semafori, pipe, code di messaggi, memoria condivisa, socket Cambi di contesto legati all uso di un meccanismo di IPC I thread offrono concorrenza con un grado minore di trasparenza Applicazioni con prestazioni migliori (in molti casi) ma con codifica e debug più difficile Difficoltà legate alla sincronizzazione tra thread Valeria Cardellini - SDCC 2016/17 6 Ulteriori vantaggi del multithreading In generale si ottimizza l esecuzione dei programmi - Miglioramento delle fasi di allocazione ed esecuzione (condivisione dello stato e dello spazio di indirizzamento) Possibilità di sfruttare implicitamente il parallelismo disponibile nelle architetture multiprocessore e multicore Più adatto per applicazioni di grandi dimensioni Comunicazione più economica rispetto a IPC Valeria Cardellini - SDCC 2016/17 7

5 Performance improvement on SMPs for on-node communications Source: MPI: on-node communication via shared memory (at least one memory copy operation) Pthreads: no intermediate memory copy Valeria Cardellini - SDCC 2016/17 8 Implementazione di thread Principali modalità alternative per fornire il supporto di thread Implementazione a livello utente (N:1) Implementazione a livello kernel (1:1) Implementazione ibrida (N:M) Distinzione in base alla corrispondenza tra numero di thread a livello applicativo e numero di entità schedulabili dal kernel Valeria Cardellini - SDCC 2016/17 9

6 Implementazione di thread: livello utente A livello dello spazio utente (anche schema N:1) N thread a livello applicativo, 1 entità schedulabile dal kernel La libreria di thread viene eseguita completamente in modalità utente Tutte le operazioni sui thread sono completamente gestite all interno di un singolo processo Non interviene il kernel del SO per creare, terminare, schedulare per l esecuzione, sospendere, o risvegliare un thread Implementazione molto efficiente (tempo di cambio di contesto tra thread molto basso) Tutti i servizi forniti dal kernel del SO sono per conto del processo in cui il thread risiede Se un thread si blocca in attesa di un operazione di I/O sincrona, il kernel blocca l intero processo a cui appartiene il thread Esempio: GNU Portable Threads Valeria Cardellini - SDCC 2016/17 10 Implementazione di thread: livello utente (2) Svantaggio principale: i thread si bloccano su una base per-evento Poiché il kernel non distingue i thread di un processo, non può segnalare l occorrenza di eventi ai singoli thread Si perde il vantaggio del multithreading nella gestione di eventi di I/O Ulteriore svantaggio: mancanza di parallelizzazione su architetture multiprocessore o multicore Esempi: libreria green threads in Solaris Valeria Cardellini - SDCC 2016/17 11

7 Implementazione di thread: kernel A livello del kernel (anche schema 1:1) 1 thread a livello applicativo, 1 entità schedulabile dal kernel Il kernel contiene l implementazione del pacchetto di thread A ciascuna funzione per la gestione dei thread corrisponde una chiamate di sistema Le operazioni che bloccano un thread non sono più un problema come nello schema N:1 Il kernel può schedulare un altro thread disponibile all interno dello stesso processo La gestione di eventi di I/O è semplice Il kernel (che cattura tutti gli eventi) schedula il thread associato all evento Supporta la parallelizzazione su architetture multiprocessore o multicore Esempio: libpthread, NPTL per Linux (ora integrata con la libreria GNU C) Valeria Cardellini - SDCC 2016/17 12 Implementazione di thread: kernel (2) Quasi tutti i SO attuali adottano lo schema 1:1 Linux, MS Windows, Mac OS X Per sapere quale supporto per thread è attivo su Linux: getconf GNU_LIBPTHREAD_VERSION Problema principale dello schema 1:1 rispetto a N:1 - Perdita di efficienza dovuta al fatto che ogni operazione del thread richiede una trap al kernel Valeria Cardellini - SDCC 2016/17 13

8 Implementazione di thread: ibrida Per sfruttare i vantaggi degli schemi N:1 ed 1:1 riducendone gli svantaggi: combinare thread a livello utente e a livello kernel (detto schema N:M) Soluzione ibrida: N thread a livello applicativo sono mappati su M entità schedulabili dal kernel, con N >= M Maggiore complessità di implementazione rispetto agli schemi N:1 e 1:1 Esempi: IRIX, HP-UX, Tru64 Unix, Netscape Portable Runtime (API indipendente dalla piattaforma per funzioni di sistema e funzioni libc) Valeria Cardellini - SDCC 2016/17 14 Thread e SD: lato client Client multithread: per nascondere la latenza delle comunicazioni Esempio: browser multithread Ogni risorsa inclusa in una pagina è gestita da un thread, che si occupa di una singola richiesta e risposta HTTP Esempio: chiamate/invocazioni remote multiple per subtask appartenenti allo stesso task (RPC o Java RMI) Il client effettua molteplici chiamate contemporaneamente, ciascuna gestita da un diverso thread Attende finché non ottiene tutte le risposte Speedup lineare se le chiamate sono a server diversi Valeria Cardellini - SDCC 2016/17 15

9 Thread e SD: lato server Server multithread: per incrementare l efficienza di prestazioni e la modularità architetturale (specializzazione, semplicità) Prestazioni Thread più economico di un processo per gestire una richiesta in ingresso Scalabilità del server in architettura multiprocessore o multicore Nascondere la latenza di rete reagendo alla richiesta successiva mentre si risponde alla precedente Struttura migliore In caso di elevata richiesta di I/O: l uso di chiamate di sistema bloccanti semplifica la struttura complessiva I programmi multithread tendono ad essere di dimensioni minori e più semplici da capire per il controllo di flusso semplificato Valeria Cardellini - SDCC 2016/17 16 Problematiche lato client: trasparenza Il client comprende componenti per ottenere la trasparenza della distribuzione Trasparenza di accesso: generalmente gestita attraverso la generazione di un client stub Trasparenza all ubicazione, alla migrazione e al riposizionamento: generalmente il client tiene traccia della locazione effettiva Trasparenza alla replica: molteplici invocazioni gestite dal client stub Trasparenza ai guasti: spesso gestita solo lato client (cercando di mascherare malfunzionamenti del server o della comunicazione) Valeria Cardellini - SDCC 2016/17 17

10 Problematiche lato server: porta Già analizzate (in altri corsi) diverse questioni inerenti la progettazione di un server: Server concorrenti, distribuzione verticale, Come fa il client a conoscere la porta su cui contattare il server? Porta preassegnata e nota Porta assegnata dinamicamente (interazione con daemon) Daemon in ascolto su porta preassegnata delle richieste per alcuni servizi Richieste per lo stesso servizio girate su porta assegnata dinamicamente di cui viene informato il server corrispondente Attivazione dinamica di server (interazione con superserver) Per richieste non frequenti non conviene mantenere server attivi Il superserver ascolta le porte corrispondenti e per ogni richiesta in arrivo risveglia (o crea dinamicamente) il server corrispondente Ad es. inetd e xinetd per Linux, launchd per OS X Valeria Cardellini - SDCC 2016/17 18 Problematiche lato server: interrompibilità Si può interrompere un server una volta che ha accettato una richiesta di servizio? Soluzione 1: interruzione della connessione Comporta l interruzione del servizio Soluzione 2: dati out-of-band Usare una porta di controllo separata Il server ha un thread (o processo) in attesa di messaggi urgenti Quando arriva un messaggio urgente, la richiesta di servizio associata viene sospesa Oppure usare i meccanismi di comunicazione out-of-band forniti dal livello di trasporto Ad es. TCP permette di trasmettere dati urgenti sulla stessa connessione Valeria Cardellini - SDCC 2016/17 19

11 Problematiche lato server: stato Server senza stato (stateless) Non mantiene informazioni accurate (ad es. informazioni di sessione) sullo stato del client e non deve informarlo di eventuali cambi di stato lato server Ad es. non invalida la cache di un client Ad es. non registra che un file è stato aperto Conseguenze: Client e server sono indipendenti Si riducono le inconsistenze di stato dovuto a crash del client o del server Possibile perdita di prestazioni, ad es. il server non può anticipare il comportamento del client Server con stato (stateful) Mantiene informazioni persistenti sullo stato del client Ad es. registra che un file è stato aperto, in modo da poterne fare il prefetching Ad es. conosce il contenuto della cache di un client e consente ad un client di mantenere una copia locale di dati condivisi Ad es. informazioni di sessione Valeria Cardellini - SDCC 2016/17 20