Costrutti Cobegin e Coend

Costrutti Cobegin e Coend

Un problema degli algoritmi come quello indicato qui sopra è che, a causa della loro non linearità, può essere difficile capire intuitivamente in ogni istante quanti e quali processi siano attivi una volta che il programma sia in esecuzione. I costrutti Cobegin e Coend consentono di rappresentare in modo intuitivo e semplice diramazioni parallele di un grafo di processi. Un listato del tipo

begin

P0;

cobegin

P1;

P2;

Pn;

coend;

Pz;

end;

equivale ad un grafo il cui nodo radice è P0 e l'unico nodo foglia è Pz: i processi interni al costrutto Cobegin-Coend formano nodi allo stesso livello intermedio tra P0 e Pz e vengono eseguiti tutti in parallelo; chiaramente l'adozione dei costrutti Cobegin-Coend in modo innestato consente di sviluppare grafi più complessi, ma non consente di rappresentare tutti i possibili grafi di precedenza. Detto cammino parallelo una generica sequenza di nodi il cui primo nodo è un nodo Cobegin (ovvero da esso parte una diramazione) e il cui ultimo nodo è un nodo Coend (ovvero in esso collassano almeno due nodi), un grafo di precedenza può essere tradotto con i costrutti Cobegin-Coend solo se per ogni coppia X,Y di nodi Cobegin-Coend del grafo si verifica che tutti i cammini paralleli che originano da X collassano in Y e tutti quelli che collassano in Y originano da X, ovvero ogni sottografo deve essere di tipo One In - One Out.

Il grafo di precedenza relativo al programma di Lettura, Elaborazione e Scrittura dell'array non verifica questa condizione: dato il generico cammino parallelo L(i) - E(i) - S(i), si osserva che da L(i) origina il cammino L(i+1) - E(i+1) - S(i+1) che non collassa in S(i) e che in S(i) collassa il cammino L(i-1) - E(i-1) - S(i-1) che non origina da L(i), quindi in teoria non è possibile riprodurre quell'algoritmo usando i costrutti Cobegin-Coend. In realtà, riducendo il grado parallelismo (il che non significa necessariamente perdita di efficienza) al massimo a 3 processi, è possibile sviluppare un grafo alternativo traducibile con i nuovi costrutti: a partire dal nodo radice L1, abbiamo una serie di paralleli (Cobegin-Coend impilati) con L2 ed E1 al secondo livello, e L(i+1) - E(i) - S(i-1) ai livelli successivi ottenendo un algoritmo di facile interpretazione

var A, B, C : T; Usiamo solo 3 variabili buffer

(l'array è implicitamente acceduto dalla routine Leggi)

i : 2..N; Variabile di indice

begin

Leggi(A);

cobegin

Elabora(A);

Leggi(B);

coend;

for i:= 3 to N do begin Inizio ciclo For

C:=A;

A:=B;

cobegin

Elabora(A);

Leggi(B);

Scrivi(C);

coend;

end; Fine ciclo For

cobegin

Stampa(A);

Elabora(B);

Stampa(B);

coend;

end.

Risorse

Sulla base della sua definizione un processo è una entità attiva del sistema. Si definisce Risorsa un qualunque componente passivo - hardware o software - del sistema, di cui i processi (e i loro thread) si servono nei rispettivi flussi di controllo. Un processo è composto da istruzioni, le istruzioni sono composte da codici operativi e questi ultimi lavorano su operandi (anche in mancanza di operandi espliciti esiste almeno un operando implicito) quindi è corretto dire che le risorse di un processo sono i suoi operandi; una risorsa software è chiaramente un oggetto allocato e accessibile in memoria, ma anche con una risorsa hardware si può interagire, di fatto, attraverso una opportuna interfaccia costituita in ultima analisi da registri, ai quali un processo può accedere e di cui può modificare il contenuto; generalizzando si può affermare che una risorsa, indipendentemente dalla sua natura, dal punto di vista di un processo, è sempre una struttura dati (di un qualche tipo elementare o a sua volta strutturato) allocata in memoria, cui un processo può accedere con delle procedure opportunamente definite, dette metodi di accesso: l'oggetto risorsa si assume quindi costituito da una struttura dati e dai suoi metodi di accesso.

Allocare una risorsa ad un processo significa dargliene visibilità e quindi, salvo vincoli, dargli la facoltà di utilizzarla. Quando una risorsa viene allocata staticamente, un processo ne conserva la visibilità per tutta la sua durata, da quando viene creato fino a quando viene terminato; viceversa se allocata (e deallocata) dinamicamente durante la sua evoluzione, il processo ne ha visibilità solo in determinati intervalli di tempo. In base alla modalità di allocazione e al numero di processi coinvolti una risorsa può essere:

dedicata se è allocata (staticamente o dinamicamente) ad un solo processo

privata (o locale) se è dedicata e allocata staticamente

condivisa se è allocata (staticamente o dinamicamente) a più processi

comune (o globale) se è condivisa e allocata dinamicamente

ad uso esclusivo se è condivisa ma deve essere usata da un solo processo per volta

Un allocatore o gestore di risorse è un'entità preposta ad allocare risorse ai processi garantendo il rispetto dei vincoli imposti dal tipo stesso di risorsa gestita (dedicata, privata, condivisa, comune, ad uso esclusivo) e può essere lo stesso programmatore se si tratta di risorse logiche o un componente del SO o componente dell'elaborazione - d'obbligo se si tratta di risorse fisiche - che a sua volta può essere un processo gestore o una risorsa gestore: può allocare dinamicamente una generica risorsa ad un unico processo per volta, se la risorsa è allocata staticamente può usare qualche criterio per disciplinarne le richieste, oppure può eseguire esso stesso le operazioni per conto dei processi richiedenti. Per svolgere la sua funzione il gestore necessita di una struttura di gestione (che memorizza lo stato della risorsa gestita e gli identificatori dei processi che la usano o che sono in attesa di usarla) e di procedure che operano su di essa (che servono alla verifica della soddisfacibilità di una richiesta e del rilascio della risorsa successiva all'uso): tale struttura rappresenta una risorsa privata del proceso gestore oppure costituisce essa stessa la risorsa gestore allocata staticamente dal programmatore nella memoria comune condivisa da tutti i processi che desiderano accedere alla risorsa gestita.

Modelli di programmazione concorrente

Le macchine concorrenti seguono due modelli fondamentali: il modello a Memoria Globale (o Comune) e il modello a Scambio di Messaggi o a Memoria Locale; nel primo modello la macchina ha una o più CPU che condividono un'unica memoria, e chiaramente anche le risorse che risiedono su tale memoria saranno condivise, essendo accessibili da ogni processo; nel secondo modello la macchina ha invece più memorie locali e di conseguenza ha risorse private.