Appunti Sistemi operativi - parte 5

Sincronizzazione a modello ad ambiente locale

La sincronizzazione a modello ad ambiente locale è un modello in cui le risorse sono locali ai processi e, poiché non sono risorse condivise, tutti quei problemi di competizione che si avevano nel modello a memoria condivisa in questo modello non si hanno. Essendo le risorse locali a tutti i processi, per poter operare sulle risorse, i processi devono comunicare con altri processi. Ad esempio, se abbiamo un foglio e vanno registrate le prenotazioni all’esame, e abbiamo che il foglio è locale e non è condiviso, per effettuare una prenotazione lo studente dovrà per forza inviare un messaggio. Ecco perché questo modello prende anche il nome di modello a scambio messaggi, in quanto l’unico modo che hanno i processi per utilizzare delle risorse che sono locali ad altri processi è quello di andare a scambiare dei messaggi.

Poiché le risorse sono locali ai processi, non abbiamo problemi di mutua esclusione e ci dobbiamo solo concentrare sullo scambio di informazioni, ovvero dello scambio dei messaggi che i processi devono in qualche modo implementare per poter portare a termine l’elaborazione.

Primitive fondamentali

Le due primitive fondamentali per l’implementazione di un modello a scambi messaggi sono send e receive. Il message nella receive è un parametro di uscita mentre nella send è un parametro di ingresso. Le send e le receive si distinguono per il tipo di sincronizzazione tra i processi comunicanti e l’indirizzamento, ovvero la modalità con cui viene individuata la destinazione o il soggetto dei messaggi.

Per esempio, se qualcuno ci vuole chiamare sul cellulare, questo avrà bisogno del numero di telefono. Se si conosce il numero di telefono della controparte, si dice che la comunicazione è diretta. Se, invece, non si ha il numero di telefono della persona con la quale si vuole comunicare, ma si conosce solo l’indirizzo, la comunicazione potrà avvenire per mezzo di una lettera che potrà essere scritta e spedita all’indirizzo per mezzo posta; in questo caso, la comunicazione si dice indiretta.

Sincronizzazione

Per sincronizzazione possiamo considerare come esempio il caso in cui chiamiamo un amico ed aspettiamo che questo risponda prima di poter comunicare; in questo caso, abbiamo che la send deve essere sincrona in quanto dobbiamo aspettare prima di sincronizzarci con il nostro amico e, per poter comunicare, dobbiamo aspettare che questo sia disponibile e risponda al telefono. Se invece comunichiamo con un WhatsApp, abbiamo che non c’è bisogno che il nostro amico sia attivo e pronto a rispondere, in quanto in questo caso la comunicazione potrà essere asincrona.

Formato messaggi e sincronizzazione nei SO

Con questi esempi, abbiamo dato un'idea delle modalità con le quali si vanno a classificare la send e la receive. Un messaggio tipicamente ha un proprio formato, ha un contenuto che prende il nome di corpo del messaggio ed ha delle informazioni di controllo come un header o un’intestazione. L’header e il corpo di ogni messaggio varieranno a seconda del protocollo di comunicazione che si deciderà di utilizzare. In generale, abbiamo che il formato di un messaggio sarà come quello descritto sopra.

In quasi tutti i Sistemi Operativi (SO), la tipologia di receive che viene più utilizzata è la receive bloccante, in quanto la receive non bloccante è la meno utile perché, quando invocata, se c’è un messaggio lo prende, altrimenti continua. Di solito abbiamo che la receive serve ad effettuare delle elaborazioni a seconda che ci sia o meno un messaggio. La sincronizzazione tra chi invia un messaggio e chi lo riceve può essere di diverso tipo a seconda della tipologia di send e receive che si utilizzano.

Tipologie di sincronizzazione

Tra le quattro combinazioni viste, non tutte sono utili. Ad esempio, una send asincrona e una receive non bloccante saranno poco utili in quanto send e receive molto probabilmente non si sincronizzeranno. È come se, ad esempio, il professore a lezione in Dad cominci a spiegare non sapendo se gli studenti sono collegati, ed è intuitivo capire che questo tipo di combinazione sia poco utile. Le tipologie di sincronizzazioni più utilizzate sono allora le seguenti.

La tipologia più forte di sincronizzazione è la rendezvous. In questa tipologia di sincronizzazione, sussiste una stretta sincronizzazione tra sender e receiver. Un esempio di questa tipologia di sincronizzazione può essere la telefonata tra due persone, dove abbiamo che l’interlocutore comincia a parlare soltanto quando l’altro interlocutore dice "pronto".

Utilizzo nei server

Un altro tipo di sincronizzazione è quella che forse viene ad essere maggiormente utilizzata nelle reti di calcolatori, come ad esempio i Server e Web Server, che utilizzano una send asincrona e una receive bloccante. Il Server, ad esempio, si mette in attesa di ricevere un messaggio come può essere una pagina HTML; quando riceve la richiesta, la elabora e si mette in attesa di un altro messaggio. I processi Client, come i Web Browser, non hanno proprio una necessità di sincronizzarsi con il Server; fanno infatti una richiesta e poi fanno altre cose, quindi fanno una send asincrona.

Gli altri casi, come send asincrona e receive non bloccante e send sincrona e receive non bloccante, sono poco utilizzati. Addirittura, send sincrona e receive non bloccante è pericolosa in quanto provoca lo stallo del processo che esegue una send.

Send asincrona e problemi di rilevazione

La send asincrona, come abbiamo detto, è una send che, una volta invocata, non necessita di porsi in attesa che il messaggio sia stato effettivamente ricevuto. Se si fa una serie di send asincrone e, per esempio, se ne perde una, sarà difficile rilevarlo durante la trasmissione e quindi solo alla fine di un treno di messaggi sarà possibile capire quale messaggio è stato perso ed eventualmente ritrasmetterlo. In alcuni casi questo va bene, come ad esempio nel flusso di dati multimediali come Netflix, in quanto se durante la visione di un film viene perso un frame, nella maggior parte dei casi non ce ne si accorge, ma poi non sarà possibile andarlo a ritrasmettere, ad esempio dopo 10 minuti, in quanto questo non avrebbe senso. Ci sono casi come transizioni bancarie oppure operazioni su conto corrente dove andare ad usare una send asincrona può essere pericoloso, in quanto sarà possibile rilevare la perdita di un pacchetto, ma sarà difficile recuperarla. Bisogna quindi stare attenti alla send asincrona specialmente quando si trasmettono treni di messaggi.

Send sincrona e receive bloccante

Tipicamente, all’interno dei sistemi come UNIX, non viene fornita l’implementazione di una send sincrona. In UNIX, infatti, non viene data un’implementazione di send sincrona e questa dovrà essere sviluppata dal programmatore a partire da una send asincrona. Supponiamo di avere una send asincrona e di avere una receive bloccante; per realizzare una send sincrona, dobbiamo andare a sincronizzare sender e receiver. Infatti, abbiamo una send sincrona quando, ad esempio, due processi si sincronizzano e si rendono pronti per comunicare. Per fare ciò, dobbiamo avere che il sender dovrà inviare al receiver un messaggio di Request to Send (RTS); questo lo possiamo assimilare alla chiamata che fa squillare il telefono. Se il receiver riceve la chiamata, dovrà inviare al sender un messaggio di Ok to Send (OTS). Se il sender riceve il messaggio, avremo che sender e receiver sono sincronizzati e quindi potranno cominciare a comunicare.

Implementazione di send sincrona

N.B. Questo argomento è importante in quanto nei compiti può uscire di andare ad implementare una send sincrona a mezzo di una send asincrona. La send sincrona la possiamo quindi vedere come destinazione-messaggio ed il messaggio viene inviato solo a valle della sincronizzazione (rendezvous). La receive fa invece sorgente-messaggio e il messaggio viene ricevuto solo a valle della sincronizzazione.

Problemi di stallo e deadlock

Per la receive bloccante, abbiamo che c’è un potenziale problema di stallo, deadlock, in quanto se nessuno manda un messaggio, il receiver potrà attendere un tempo indefinito la ricezione. N.B. Per le send e le receiver, soprattutto in ambito delle reti di calcolatore, è possibile impostare un time-out che rappresenterà il tempo massimo che una receiver potrà bloccarsi in attesa di un messaggio. Se questo time-out scade, allora la receive genererà un’eccezione e si uscirà dall’attesa. Per noi che facciamo comunicazione dei processi all’interno di un SO, il time-out non sarà un problema che ci porremo molto, in quanto stando all’interno dello stesso sistema sarà difficile che un messaggio si vada a perdere.

Indirizzamento

Vediamo ora l’indirizzamento: come anticipato in precedenza, abbiamo che l’indirizzamento potrà essere diretto o indiretto a seconda che la sender conosca l’indirizzo del destinatario e quindi il destinatario sappia da chi può ricevere il messaggio. Abbiamo poi che la comunicazione potrà essere diretta simmetrica o asimmetrica. La comunicazione diretta simmetrica è quella comunicazione in cui nella send andiamo ad inserire l’indirizzo del destinatario che, nel nostro caso, è il Process Identifier del destinatario e nella receive andiamo ad indicare esplicitamente il Process Identifier del mittente. Quindi questo tipo di comunicazione prende il nome di comunicazione diretta simmetrica ed è come se volessimo chiamare una persona e questa è in attesa di chiamate da noi.

Comunicazione diretta asimmetrica

La comunicazione diretta può anche essere asimmetrica, come ad esempio accade nelle applicazioni Web in cui nella send indichiamo il PID destinatario perché nella send, se vogliamo mandare una request http ad un Web Server, dobbiamo individuare ed indicare l’indirizzo del Web Server, mentre invece nella receiver il PID è un parametro di uscita; abbiamo una situazione simile ad una telefonata, quando componiamo un numero di telefono abbiamo che il PID nella sender (chiamata) è un parametro di ingresso in quanto serve per poter effettuare la chiamata, mentre quando riceviamo una chiamata abbiamo che il numero (PID) rappresenta un parametro di uscita che ci dice da chi abbiamo ricevuto la chiamata. In questo caso stiamo implementando una comunicazione diretta asimmetrica in quanto siamo noi ad inserire il destinatario (numero, PID) e chi riceve riceverà tutto ma avrà le informazioni sul destinatario come parametro di uscita.

Comunicazione indiretta

Nel sistema operativo UNIX vedremo che una forma di comunicazione usata molto oggi è la comunicazione indiretta. La comunicazione indiretta fa sì che un sender possa comunicare con un receiver senza per questo conoscere l’indirizzo del receiver; un esempio possono essere le mailbox. La comunicazione diretta prende anche il nome di schema a pipeline, ogni processo sa con chi può comunicare e da chi può ricevere messaggi e quindi si possono fare schemi come sopra, dove abbiamo che la send deve specificare come parametri di ingresso a chi vuole inviare il messaggio mentre la receiver indica come parametro di ingresso da chi vuole ricevere il messaggio.

Mailbox

Nella comunicazione diretta asimmetrica abbiamo invece che chi invia il messaggio specifica l’indirizzo del destinatario, mentre chi riceve un messaggio, come ad esempio un processo Server, l’indirizzo costituisce solo un parametro di uscita e serve a capire da chi si è ricevuto il messaggio. La comunicazione indiretta invece consiste nell’interporre tra i sender e receiver un’entità che è un buffer che in UNIX prende il nome di mailbox. Sostanzialmente la presenza di una mailbox disaccoppia la comunicazione tra i sender e i receiver. Tipicamente, la mailbox si comporta come un buffer distribuito. La mailbox è una sorta di coda distribuita in cui si possono inserire e prelevare dei messaggi. Un processo che è intenzionato a produrre dei messaggi si collega alla mailbox e può in qualche modo inviare un messaggio attraverso una send o delle primitive che prendono il nome di push. La mailbox prende il messaggio e lo mette all’interno della coda segnando ad esempio un messaggio di tipo T; ci sono poi dei processi receive che sono interessati a ricevere dei messaggi di tipo T e quindi invocano una receive specificando il tipo T sulla mailbox. Receiver e sender non si conoscono e vengono ad essere disaccoppiati attraverso questa mailbox. Impareremo che questa mailbox può essere una coda che potrà essere attiva o passiva; diremo che la mailbox è passiva quando sono i processi ad invocare delle primitive su questa mailbox. Una mailbox può essere anche attiva perché, ad esempio, un processo fornisce una funzione di preleva messaggio e quindi sarà la mailbox che avrà un’attività nel prelievo di un messaggio da un processo.

Comunicazione in Linux

In base a quanto detto, non dobbiamo meravigliarci quando in Linux diremo che in un messaggio è obbligatorio fornire un tipo che altro non è che un intero che descrive la tipologia di messaggio. La comunicazione attraverso mailbox distribuita avviene ad esempio nei cartelloni degli aeroporti. Nei cartelloni degli aeroporti abbiamo al check-in cartelloni elettronici per la partenza e per gli arrivi. La comunicazione tra i cartelloni di arrivi e partenze non è una comunicazione diretta e simmetrica, ma è una comunicazione che prevede ogni volta che si aggiunge un cartellone di andare sulla rete prendere l’indirizzo del cartellone, configurarlo in modo che questo comunichi alla rete se è un cartellone per gli arrivi o le partenze e poi avvisare la torre di controllo che si è aggiunto un altro cartellone comunicandole l’indirizzo, perché questo andrebbe a complicare notevolmente la situazione. Succede allora che tipicamente quello che viene ad essere fatto in un aeroporto è questo: si configurano due mailbox, una per gli arrivi e un’altra per le partenze. Si hanno allora due code di messaggi. A sinistra nell’immagine sopra abbiamo la torre di controllo che è interfacciata con tutto il mondo avionico; la torre di controllo possiede poi i piani di volo e conosce quindi tutti gli orari aggiornati sulle partenze e sugli arrivi. Quando la torre di controllo riceve aggiornamenti sulle partenze, andrà a fare una send del piano di volo sulla mailbox delle partenze; quando invece ha aggiornamenti sul piano di volo degli arrivi, farà una send sulla mailbox degli arrivi. In aeroporto abbiamo cartelloni per gli arrivi e per le partenze; questi cartelloni si sottoscrivono alle relative mailbox e fanno una receive per le partenze e gli arrivi rispettivamente. Quando si deve aggiungere un nuovo cartellone, basterà prendere il tabellone e dargli l’indirizzo della relativa mailbox per le sender o per le receive.

Si potrebbe anche avere una sola mailbox che gestisce due tipologie di messaggi: uno per gli arrivi ed uno per le partenze. Infatti, nelle mailbox possono essere memorizzate diverse tipologie di messaggi in cui ad esempio ad uno viene assegnato il valore 0 e ad un altro il valore 1. N.B. A Dublino, nei primi anni 2000, venne implementato un sistema di mailbox sicure che serviva a guidare in caso di incendi le persone affette da disabilità o persone che erano incapacitate a correre e quindi che potevano trovare ausilio alla fuga con delle sedie a rotelle verso delle uscite ausiliarie differenti da quelle verso cui erano dirottate la maggior parte delle persone.

Comunicazione nei processi server

La comunicazione diretta asimmetrica è quella che viene tendenzialmente usata nei processi Server. Processi Server sono quei processi che hanno una richiesta, una coda di messaggi, le richieste vengono ad essere elaborate e poi si fornisce una risposta al processo cliente.

Quando parliamo di un protocollo sincrono, parliamo di una stretta sincronizzazione tra produttore e consumatore. L’esercizio proposto è molto semplice, in quanto, poiché è richiesto un protocollo sincrono, bisogna avere una send sincrona ed una receive bloccante. Il problema del produttore e consumatore sta nel fatto che il produttore deve fare una send sincrona del messaggio ad una certa coda ed il consumatore dovrà fare una receive del messaggio alla sua coda. Il problema sta quindi tutto nell’implementare una send sincrona. Per realizzare una send sincrona, come abbiamo già detto, bisogna andare ad implementarla a partire da una send asincrona; come abbiamo detto, sostanzialmente bisogna inviare un messaggio di tipo Request to Send e attendere un Ok to Send e poi sarà possibile inviare il messaggio. Request to Send e Ok to Send sono due tipologie di messaggi e pertanto vanno inviate su due code diverse. In questo caso abbiamo che la receive riceverà sulla prima coda la Request to Send, dopodiché invierà sulla seconda coda un Ok to Send, infine sulla coda dei messaggi vengono ad essere scambiati i messaggi da consumare.

Schema grafico del protocollo

Graficamente, per avere questo protocollo singolo, abbiamo bisogno concettualmente di 3 code di messaggi: queue1, queue2 e queue3. Il produttore invierà una Request to Send sulla coda 1 che riceverà il consumatore; se il consumatore riceve la richiesta, dovrà rispondere Ok to Send al produttore e a questo punto abbiamo il vero e proprio rendezvous; a questo punto potrà essere inviato il messaggio che potrà essere consumato. Ci sono mailbox in cui, quando un messaggio è prelevato, non ci sarà più e mailbox che, quando è presente un messaggio, lo distribuisce a tutti quanti. Se consideriamo una mailbox con delle code di messaggi e supponiamo che ci sono dei processi receiver R1, R2 e Rn che devono ricevere il messaggio, questi processi forniscono una così detta call back che è una funzione che ad esempio si chiama receive o pop e che contiene il messaggio; tutti i receiver devono implementare questa funzione, la send dovrà contenere la lista R1, R2 e Rn di tutti i receiver e appena arriva un messaggio M la mailbox su ogni receiver sottoscritto invocherà la receive passandogli M, in questo modo tutti i receiver avranno il messaggio.

Metodi di gestione della mailbox

Ci sono, ricapitolando, due metodi:

• Metodo push -> in questo metodo abbiamo che è la mailbox che invia i messaggi a receiver
• Metodo con mail box -> in cui ogni receiver richiede attivamente il messaggio.