5.4 KiB
Primitive Sincrone
- Send bloccante e receive bloccante (vedi slides)
Guardie di output
Una guardia solitamente era trattata come una recv bloccante (guardia di input), ma possono esistere anche guardie della forma:
(<espr. booleana>); <primitiva send>
Che e' definita come guardia di output. Mescolare guardie di input e guardie di output puo' creare situazioni di deadlock. (vedi slides per esempi) Questo e' dovuto principalmente alla scelta non deterministica tra piu' guardie valide. Per questo motivo si decide di non utilizzare le guardie di output, a parte in alcuni casi specifici.
Processi servitori: gestione di pool di risorse equivalenti
Caso sincrono (slides per implementazione)
Processi servitori: gestione di una risorsa dedicata
(vedi slides)
Simulazione di un semaforo
Le primitive sincrone hanno lo stesso potere di tutte le primitive viste precedentemente. (vedi slides per implementazione semaforo)
Prod/Cons con buffer di lunghezza finita
(slides per implementazione)
Il processo buffer e' un server che gestisce inserimento ed estrazione dalla coda.
Vedi anche esempio con guardie di output, che utilizza primitive di send per mandare i dati al consumatore.
Prod / Cons con N processi server
Il buffer di N dati e' realizzato da N processi dati, produttore e consumatore estrerni. (slides per implementazione) Questa soluzione e' semplice, ma presuppone hardware con elevato parallelismo.
Specifica di strategie di priorita'
(slides per implementazione) I processi aspettano per ottenere una risorsa, ma quando questa si libera viene svegliato il processo con priorita' piu' alta. Caso analogo con send asincrona. I clienti in attesa sono inseriti in ordine di priorita' in una coda, e si presuppone un'unica risorsa (non un pool). E' praticamente uguale al caso asincrono.
Lettori / Scrittori
(slides per implementazione) Soluzione identica al caso asincrono. In questa soluzione pero' non e' necessario gestire le code.
Note sulle primitive sincrone
Difficilmente sono implementate a livello kernel, perche' e' possibile realizzarle con le asincrone.
Chiamate di procedura remota e rendez-vous (esteso)
Chiamata di procedura remota e rendez-vous esteso sono due concetti simili:
-
Chiamata di procedura remota e' relativa alle soluzioni multithreading
-
Rendez-vous esteso e' relativo alle soluzioni single thread (single server con interrupt) La loro funzione e' pero' la stessa:
-
Il client effettua una richiesta sul server, richiedendo una procedura. Nel caso RPC, questa procedura viene eseguita su un processo (thread) separato. Nel caso del rendez-vous esteso, l'operazione richiesta e' specificata come una serie di istruzioni che possono comparire in un punto qualunque del server. Il server usa quindi un accept che interrompe l'esecuzione e passa all'esecuzione delle istruzioni. (vedi slides per dettagli e implementazione)
Esempio RPC: servizio di sveglia
Insieme di N processi clienti possono richiedere di essere svegliati da un processo servitore, dopo un tempo da loro prefissato. (slides per grafico)
Il server utilizzera' quindi un clock, che opera su un processo separato, e una serie di N thread relativi ai singoli processi, che sono spawnati una volta che il clock raggiunge i tempi prefissati. I thread si occupano di svegliare i processi.
(slides per implementazione)
Rendez-vous
Il servizio richiesto e' specificato come insieme di istruzioni che possono comparire in un punto qualunque del processo servitore:
accept<servizio> (in <param-ingresso>,
out <param-uscita>);
(S1, ... , SN) -> S0;
- Nota: S1, ... SN sono servizi da eseguire in rendez-vous, mentre S0 e' una procedura eseguita solo dal server, non in rendez-vous.
Accept
- Bloccante: se non sono presenti richieste, provoca la sospensione del server
- Se lo stesso servizio e' richiesto da piu' processi, si utilizza una coda FIFO
- Lo schema di comunicazione e' quindi asimmetrico da molti a uno.
(slides per grafico di esecuzione)
Selezione delle richieste in base ai parametri di ingresso
Con accept, la selezione della richiesta da servire puo' dipendere anche dai parametri d'ingresso della richiesta stessa. In questo caso la guardia logica che condiziona l'esecuzione dell'azione puo' essere espressa anche in termini dei parametri di ingresso. Questo richiede una doppia interazione tra server e client, la prima per trasmettere i parametri, la seconda per la richiesta stessa. NB: il numero di parametri deve essere limitato
Esempio: sveglia
In questo esempio con rendez-vous del processo sveglia ci sono 3 tipi di richieste: (vedi slides) (slides per implementazione) In questo esempio, il client manda due richieste: nella prima manda il tempo dopo cui vuole essere svegliato, nella seconda manda l'effettiva richiesta di sveglia. Il server riceve la prima richiesta e la memorizza. Quando riceve la seconda richiesta, riordina il vettore tempo-di-sveglia in cui ha inserito il tempo indicato, e sveglia il processo dopo il tempo ricevuto.
Esempio: r&w
I lettori fanno tutte le call, gli scrittori fanno tutti gli accept. (vedi slides per implementazione)
Linguaggi CSP: Communication Sequential Process
Modello di interazione tra processi, che utilizzano una comunicazione sincrona (di solito sono sulla stessa board, vari processori). (vedi slides)