Università degli Studi di Roma Tor Vergata Dipartimento di Ingegneria Civile e Ingegneria Informatica

Transcript

1 Università degli Studi di Roma Tor Vergata Dipartimento di Ingegneria Civile e Ingegneria Informatica 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 Una failure di un processo non dovrebbero compromettere lo scopo dell algoritmo Valeria Cardellini - SDCC 2013/14 1

2 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 2013/14 2 Processo Unix Thread in un processo Unix Valeria Cardellini - SDCC 2013/14 3

3 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 2013/14 4 Creazione di processi/thread (tempo in sec) Fonte: Valeria Cardellini - SDCC 2013/14 5

4 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 2013/14 6 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 il parallelismo disponibile nelle architetture multiprocessore e multicore Più adatto per applicazioni di grandi dimensioni Comunicazione più economica rispetto a IPC Valeria Cardellini - SDCC 2013/14 7

5 Source: MPI: on-node communication via shared memory (at least one memory copy operation) Pthreads: no intermediate memory copy Valeria Cardellini - SDCC 2013/14 8 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 2013/14 9

6 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 2013/14 10 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 Valeria Cardellini - SDCC 2013/14 11

7 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: Native Posix Threads Library (NPTL) per Linux Valeria Cardellini - SDCC 2013/14 12 Quasi tutti i SO attuali adottano lo schema 1:1 Per sapere quale supporto per thread è attivo su Linux: getconf GNU_LIBPTHREAD_VERSION Problema principale dello schema 1:1 rispetto ad N:1: perdita di efficienza dovuta al fatto che ogni operazione del thread richiede una trap al kernel Soluzione possibile: cercare di combinare i concetti di thread a livello utente ed 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 Soluzione supportata ad es. da Netscape Portable Runtime (API indipendente dalla piattaforma per funzioni di sistema e funzioni libc) Valeria Cardellini - SDCC 2013/14 13

8 Client multithread: per nascondere la latenza delle comunicazioni distribuite Esempio: un browser è generalmente multithread Ogni risorsa inclusa in una pagina è gestita da un thread, che si occupa di una singola richiesta e risposta HTTP Esempio: chiamate multiple di tipo richiesta/risposta ad altre macchine (RPC) 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 2013/14 14 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 2013/14 15

9 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 2013/14 16 Già analizzate (in altri corsi) diverse questioni inerenti la progettazione di un server: Server iterativi e concorrenti Distribuzione orizzontale e verticale Come può il client 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 2013/14 17

10 Interrompibilità del server: è possibile 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 2013/14 18 Server senza stato (stateless) Non mantiene informazioni accurate 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 completamente indipendenti Ridotte 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 (in un server Web) Valeria Cardellini - SDCC 2013/14 19