Capitolo01 f

DRAF

TIntroduzione alle tecniche dianalisi di modelli a reti di codeGianfranco Balbo

Dipartimento di InformaticaUniversita` degli Studi di Torino

cCopyright Gianfranco Balbo 2007

DRAF

T

2

DRAF

TCapitolo 1Introduzione: Sistemi,Modelli e Formalismi

Comprendere eettivamente il comportamento di un sistema reale e` sempredicile a causa della complessita` della sua organizzazione e delle interazioni trale sue componenti.

La progettazione e la gestione di sistemi reali spesso richiede che vengano in-dividuate le relazioni tra le scelte organizzative ed i risultati ottenuti in manierada poter decidere quali variazioni apportare allarchitettura del sistema ed al-lambiente operativo in maniera da ottenere delle prestazioni migliori.

In tutti questi casi, ragionare sul comportamento di un sistema diventa piu`adabile se sono disponibili delle descrizioni appropriate del sistema stesso cheaiutino a chiarire le relazioni tra le sue componenti. Il modo migliore per ot-tenere queste descrizioni dettagliate e` quello di costruire un modello del sistemache evidenzi le particolarita` piu` importanti della sua organizzazione e che for-nisca dei modi per quanticare le sue proprieta`, tralasciando tutti quei dettagliche sono rilevanti per la realizzazione sica reale, ma che hanno importanzamarginale rispetto allobiettivo dello studio.

I modelli possono essere sviluppati per molte ragioni che includono la neces-sita` di comprendere eettivamente il comportamento del sistema, di migliorarnele prestazioni e di prendere delle decisioni in fase di progettazione o di esercizio.In ogni caso i modelli sono utili per spiegare perche` e come certe caratteristichedi un sistema si presentino eettivamente. Infatti, il modello aiuta a sviluppareuna comprensione profonda delle modalita` di funzionamento del sistema e acapire leetto che certi paramentri possono avere sui risultati.

La formulazione matematica di un modello fornisce dei metodi per ragionarein maniera formale circa il comportamento di un sistema in un modo che e` sicuro(anche se dicile in certi casi) e passibile di automazione. In questo modo ilmodello non fornisce solamente una descrizione qualitativa del funzionamentodel sistema reale, ma introduce degli aspetti quantitativi che sono determinatiper compiere delle scelte oculate.

3

DRAF

T

4 CAPITOLO 1. INTRODUZIONE

La possibilita` di calcolare i risultati derivanti dallanalisi di un modelloe` quindi un elemento chiave per chiudere un cerchio che incomincia con la-strazione degli aspetti piu` importanti del sistema, eseguita durante la fase dicostruzione del modello, e che termina con linterpretazione dei risultati fornitidal modello e riessi sul sistema reale.

1.1 Sistemi dinamici ad eventi discreti

Il concetto di sistema e` molto generale e noi non tenteremo di denirlo conprecisione. Informalmente parlando, un sistema e` spesso descritto come unacollezione di parti (od oggetti) identicabili, dette componenti, che interagi-scono tra di loro dando luogo a delle relazioni. Queste componenti possonocorrispondere a delle entita` indivisibili (dal punto di vista del comportamentodel sistema) oppure possono rappresentare dei sottosistemi aventi la medesimanatura dei sistemi stessi. Gli oggetti sono caratterizzati dai loro attributi chesono in parte ssi ed in parte variabili. Il valore assunto da un attributo va-riabile contribuisce (in alcuni casi in maniera sostanziale) alla denizione dellostato delloggetto (stato locale). Mettendo insieme gli stati di tutti gli oggettiche compongono il sistema otteniamo uno stato del sistema (stato globale). Lostato del sistema e` quindi denito dalla situazione istantanea di tutte le suecomponenti. Le relazioni tra gli oggetti rappresentano i vincoli che guidanoi cambiamenti di stato. Astraendo dallevento particolare che determina uncambiamento di stato, noi chiamiamo transizioni questi schemi di cambiamentodi stato. Possiamo dire che le variabili di stato sono degli elementi passivi delmodello, mentre le transizioni sono attive.

I Sistemi Dinamici ad Eventi Discreti (DEDS - Discrete Event DynamicSystems) sono sistemi in cui lo spazio degli stati e` discreto (cioe` hanno un numerodi stati contabile, anche se potenzialmente innito) e la cui evoluzione non e`legata direttamente al passaggio del tempo, quanto piuttosto alloccorrenza dieventi.

Molti sistemi reali possono essere considerati come dei DEDS non a causa diloro caratteristiche intrinseche, ma per via degli aspetti del loro comportamentoche noi vogliamo evidenziare. Per esempio, un lago articiale che contiene (natu-ralmente) una quantita` di acqua variabile con continuita`, puo` essere consideratocome un DEDS se noi restringiamo la nostra attenzione al fatto che il livellodellacqua ecceda o meno una determinata soglia di guardia. In questo caso illago puo` trovarsi solamente in uno di due stati (sicuro o pericoloso) e gli eventiche possono determinare il cambiamento di stato possono essere identicati conil vericarsi di temporali e con le azioni di apertura delle paratie della diga.Questo esempio evidenzia il fatto che non tutte le componenti devono necessa-riamente essere incluse nella descrizione del sistema (e quindi nella denizionedel modello che lo rappresenta), ma solo quelle che sono rilevanti allo scopo dellostudio permettendo cos` di osservare che un modello corrisponde sempre ad unarappresentazione astratta (ad una astrazione) del sistema oggetto di studio.

DRAF

T

1.1. SISTEMI DINAMICI AD EVENTI DISCRETI 5

Noi parleremeo quindi di DEDS riferendoci sia a sistemi reali che rispondonoeettivamente ai requisiti che li caratterizzano, sia a sistemi che possono essererappresentati in questo modo limitatamente agli scopi dello studio per cui sonopresi in considerazione.

Le caratteristiche dei DEDS permettono di individuarli in ambiti applicativianche estremamente diversi.

Nei Sistemi Flessibili di Lavorazione, lo stato del sistema puo` essere rap-presentato dal numero di pezzi da lavorare (semilavorati) fermi davanti adiverse macchine utensili e gli eventi possono corrispondere alla ne dellelavorazioni eseguite dalle diverse macchine utensili stesse, alla produzionedi pezzi niti o allarrivo di nuove parti da lavorare.

In ambito informatico, lo stato di un sistema puo` corrispondere al numerodi processi in corso di esecuzione o in attesa del completamento di certeoperazioni di I/O. Esempi di eventi sono, in questo caso, la ne di unquanto di CPU o loccorrenza degli interrupt provenienti dalle unita` diI/O e delle trap conseguenti allesecuzione delle system call.

Nelle reti di telecomunicazione, lo stato puo` corrispondere al numero dipacchetti memorizzati nei diversi buer di un sistema e gli eventi relativiallinvio di messaggi o alle azioni specicate dai protocolli.

Nel caso di traco stradale, lo stato del sistema puo` corrispondere alnumero di automobili ferme in un posteggio o in attesa di attraversareun incrocio o ancora in viaggio su un certo tratto di strada, mentre glieventi potranno essere degli arrivi e delle partenze di automobili o anchecorrispondere al cambiamento del colore dei semafori.

Nel caso di sistemi biologici, lo stato puo` essere rappresentato dal nu-mero di molecole di diverse specie presenti in una cellula e gli eventi dalvericarsi di reazioni chimiche che le trasformano.

In tutti questi casi, indipendentemente dal signicato reale delle diverse com-ponenti del sistema, capire il loro comportamento e` normalmente piuttosto dif-cile a causa della complessita` intrinseca del problema (per esempio, il numerodi parti e di macchine utensili in un sistema essibile di lavorazione puo` dareorigine a milioni di stati che sono dicili da immaginare e da tenere sotto con-trollo anche solo mentalmente), delle interferenze anche subdole che si possonodeterminare tra le componenti del sistema (per esempio, nei sistemi di traco,la presenza di strettoie - colli di bottiglia - temporaneamente nascoste da altripunti di congestione che generano degli enormi intasamenti, possono vanicarei miglioramenti attesi a seguito di interventi anche costosi volti a rimuovere ipunti di congestione primari) e di relazioni controintuitive che legano i funzio-namenti di certe componenti (si pensi per esempio, nel caso di un sistema dicalcolo, al fenomeno del thrashing che insorge quando si cerca di aumentarelutilizzazione della CPU aumentando il livello di multiprogrammazione e si ot-tiene invece leetto opposto a causa di un incremento piu` che proporzionale

DRAF

T


della paginazionedel sistema). In tutti questi casi, ragionare sul comporta-mento del sistema reale e` dicile se non si dispone di strumenti appropriatirappresentati proprio dalla presenza di modelli adeguati. Possiamo allora direche i modelli (formali) sono la base per sviluppare una comprensione appro-fondita delle modalita` di funzionamento di sistemi esistenti complessi e per laproposta di soluzioni innovative ecienti ed ecaci.

1.2 Modellazione

Un sistema che evolve nel tempo e` descritto dalla storia dei suoi stati (o succes-sione cronologica degli stati). Questa storia rappresenta un cammino attraversolo spazio di tutti i possibili stati del sistema.

Un modello di un sistema e` una rappresentazione del sistema in esame capacedi riprodurre con precisione suciente gli aspetti salienti del suo comportamen-to che sono rilevanti al ne dello studio. Segue che ogni stato del modello devecorrispondere ad uno stato del sistema (e viceversa) e che levoluzione del mod-ello deve fornire una rappresentazione precisa ed adabile della storia degli statidel sistema.

Il fatto che lo scopo di un modello sia quello di rappresentare solamentecerti aspetti della realta` del sistema oggetto di studio, implica che il modellorappresenti sempre una semplicazione (o astrazione) della realta` a cui esso siriferisce. Questo vuole anche dire che un modello di uno stesso sistema risultera`adeguato in generale solo per la conduzione di determinati studi. In altri contestiesso potra` risultare troppo semplicato o anche troppo dettagliato. In ognicaso, e` importante tenere presente che il modello, in quanto rappresentazionesimbolica del sistema a cui esso si riferisce, deve sempre rispondere a requisitidi adeguatezza per il tipo di studio che si vuole condurre.

Si puo` dire allora che la modellazione rappresenti larte della costruzione dimodelli di sistemi naturali ed articiali. Arte perche, se e` vero che la model-lazione e` basata su tecniche matematiche e statistiche ben denite, alcuni suoiaspetti fondamentali, quali la denizione del modello del fenomeno reale o lascelta del livello di astrazione, richiedono lintuito e lesperienza dellanalista checompie lo studio.

Nella descrizione di un modello e` importante distinguere lesistenza di tretipi di variabili

Le variabili di ingresso (spesso chiamate parametri) sono quelle che pos-sono essere manipolate dallesterno per studiare la dinamica del modello,cioe` la sua risposta al variare di questi parametri.

Le variabili di stato sono quelle che descrivono lo stato del sistema o diuna sua componente.

Le variabili di uscita (spesso chiamate indici di prestazione) sono variabilidipendenti generate dallinterazione tra le variabili di ingresso (parte dellevariabili indipendenti) e le variabili di stato.

DRAF

T

1.2. MODELLAZIONE 7

La denizione di un modello si conclude identicando le caratteristiche fun-zionali che descrivono linterazione tra le variabili. Queste sono le identita`(denizioni) e le caratteristiche operative rappresentate da ipotesi (in generaledelle equazioni matematiche) che pongono in relazione le variabili di uscita conquelle di ingresso.

Molti dei fenomeni che noi analizzeremo hanno natura completamente de-terministica. Nel funzionamento di un calcolatore, per esempio, nulla (o quasi)avviene per caso. A livello microscopico e` sempre possibile individuare sequenzedi azioni che sono completamente deterministiche; da un punto di vista macro-scopico pero` il funzionamento di un calcolatore e` condizionato da un cos` grannumero di variabili che risulta impossibile tenerne conto in maniera esplicita.Molti fenomeni vengono allora considerati aleatori, anche quando aleatori nonsono, solamente perche` sono il risultato della interazione di un gran numero divariabili che da` luogo ad un campo di possibilita` molto vasto. In questi casisi preferisce (o si e` costretti) a descrivere questi fenomeni con delle funzioniprobabilistiche che deniscono la frequenza con cui si vericano determinatieventi.

In questi casi i modelli discreti deterministici diventano modelli discretistocastici in cui la storia degli stati diventa una realizzazione della variabilealeatoria rappresentante il comportamento del sistema.

1.2.1 Modelli analitici e modelli di simulazione

Dato il modello matematico di un sistema, e` talora possibile ottenere infor-mazioni circa il suo comportamento per via analitica. Questo corrisponde alfatto di essere in grado di ottenere relazioni funzionali tra le variabili di ingressoe quelle di uscita. I vantaggi oerti da questa capacita` sono rappresentati dallapossibilita` di stabilire lesistenza di relazioni di causa eetto tra ingressi ed usci-te, di ottenere la soluzione del modello con costi limitati e di poter utilizzare ilmodello in maniera semplice. Oltre allimmediatezza del calcolo della soluzione,modelli di questo tipo hanno il vantaggio di essere suscettibili di analisi ra-nate che forniscono molte informazioni sul comportamento dei sistemi che essirappresentano, quali, ad esempio, la sensibilita` alle variazioni dei parametri diingresso.

Purtroppo questi aspetti positivi hanno spesso una portata limitata a causadel fatto che le classi di modelli per cui e` possibile calcolare la soluzione analiticasono relativamente poche e ristrette.

In alcuni casi, pur essendo in grado di scrivere delle relazioni funzionali traingresso ed uscita in forma implicita, non e` possibile esprimere queste stesserelazioni in forma esplicita semplice. In questi casi il calcolo della soluzionepuo` avvenire solo per via numerica (esempio tipico: soluzione di un sistemadi equazioni dierenziali o lineari) e quindi per mezzo delluso di algoritmi chepossono essere computazionalmente convenienti, ma che non permettono unostudio diretto delle proprieta` delle soluzioni trovate. In particolare, le analisidi sensitivita` di questi modelli possono essere condotte solo attraverso la ripe-tizione del calcolo della soluzione per famiglie di valori dei parametri di ingresso.

DRAF

T


Nonostante i progressi tecnologici fatti dai calcolatori delle ultime generazioni,esistono molti casi reali in cui i metodi numerici disponibili richiedono capacita`di calcolo eccessive e rendendo questi modelli troppo costosi e quindi di rilevanzapratica limitata.

Per rendere certi modelli risolvibili analiticamente ed, in certi casi, anchesolo per rendere possibile la scrittura di relazioni tra uscita ed ingresso, lanali-sta si trova nella necessita` di introdurre semplicazioni molto drastiche che, percerti studi, non sono assolutamente accettabili. In tutti i casi in cui modelli re-alistici del sistema oggetto di studio richiedono livelli di dettaglio tali da rendereil problema non piu` trattabile analiticamente o numericamente, lunica risorsache rimane allanalista e` quella di riprodurre la storia degli stati del sistema va-lutando le caratteristiche di comportamento per mezzo di misure condotte sulmodello stesso. Questa tecnica e` quella comunemente nota come tecnica di sim-ulazione con la quale levoluzione di un sistema e` riprodotta dal comportamentodinamico di un modello ottenuto per mezzo di un elaboratore digitale.

I modelli utili per condurre esperimenti con la tecnica della simulazione sonochiamati modelli di simulazione. I modelli matematici costruiti per scopi di sim-ulazione sono spesso di natura diversa da quelli utilizzati per ottenere soluzionianalitiche dei problemi, tuttavia questa dierenza non rappresenta una con-dizione necessaria che deve essere sempre vericata. La dierenza piu` impor-tante e` che un modello di simulazione e` normalmente libero da quelle ipotesilimitative che sono invece necessarie per rendere possibile lanalisi matematicadei modelli analitici.

I modelli di simulazione possono essere classicati mettendoli in corrispon-denza con i modelli matematici di cui forniscono la soluzione. Avremo quindimodelli continui, discreti, deterministici, stocastici, ecc. ecc. Noi prenderemoesclusivamente in considerazione i modelli discreti in cui i cambiamenti di sta-to sono predominantemente discontinui ed avvengono ad intervalli di tempo dilunghezza arbitraria e quindi quei modelli che sono naturalmente adatti perrappresentare il comportamento dei DEDS. La loro analisi sara` quindi condot-ta con la tecnnica simulativa che, applicata a questi modelli discreti, e` spessochiamata simulazione ad eventi discreti. Come vedremo meglio in seguito, nelcontesto simulativo il vericarsi di un evento assume una valenza piu` generaleperche, oltre a determinare una variazione del valore di una variabile di stato,puo` anche condurre alla creazione/distruzione di una componente del sistema,o allattivazione/disattivazione di una funzione.

I vantaggi di generalita` oerti dai modelli di simulazione sono purtroppocontrobilanciati da due aspetti negativi di questa tecnica

I risultati (le misure) ottenuti non permettono di stabilire delle relazionifunzionali di causa-eetto tra uscita ed ingresso.

Gli esperimenti di simulazione richiedono normalmente tempi di calcolomolto lunghi (sono quindi costosi).

Questi svantaggi devono spingere un analista a dare precedenza alluso dimodelli analitici. La tendenza corretta dovrebbe sempre essere quella di ana-

DRAF

T

1.3. MODELLI GERARCHICI E MODULARITA` 9

lizzare il problema reale in modo da scoprire e comprendere quali aspetti dellarealta` sono essenziali e quali sono marginali rispetto a quello che e` lobiettivodellanalisi. I modelli di simulazione dovrebbero quindi essere adottati solamentequando esperimenti (analisi) precedenti abbiano dimostrato linadeguatezza deimodelli analitici.

Lesperienza pratica insegna che spesso molti dettagli che rendono un mo-dello non trattabile analiticamente non sono cos` importanti come appaiono aprima vista e che, in ogni caso, la loro presenza inuisce solo marginalmente sullecaratteristiche generali di comportamento del sistema. Lo sforzo che lanalistacompie per capire in profondita` le modalita` di funzionamento del sistema oggettodi studio e per decidere (in conseguenza) quali semplicazioni sono apportabilial modello, fornisce spesso delle indicazioni preliminari non trascurabili circa ilcomportamento reale del sistema.

Evidentemente esistono numerosi casi in cui la simulazione discreta rimanelunica metodologia di analisi disponibile. In questi casi i costi (svantaggi)della simulazione rappresentano il prezzo da pagare per lo studio del comporta-mento del sistema che altrimenti sarebbe impossibile.

1.3 Modelli gerarchici e modularita`

Abbiamo osservato in precedenza come il livello di dettaglio di un determinatomodello dipenda dal tipo di studio del funzionamento del sistema reale chelanalista intende condurre. Esistono evidentemente dei casi in cui non si puo`fare a meno di introdurre certi dettagli nel modello. In queste situazioni ilmodello diventa dicile da trattare e non solo puo` perdere la caratteristica dianaliticita`, ma la sua stessa simulazione puo` diventare troppo costosa. Unatecnica per aggirare questa dicolta` puo` essere quella di studiare il problemaper mezzo di unanalisi gerarchica del modello. Lidea che sta alla base diquesto approccio e` che in sistemi molto complessi, in cui entrano in gioco ungran numero di variabili, e` molto spesso possibile individuare dei sottosistemi(aggregare gruppi di variabili) tali che :

esiste un grado di interazione molto alto tra le componenti del sottosistema le interazioni tra i sottosistemi sono relativamente deboli.

In questi casi si puo` pensare che, mediamente, il sottosistema, sollecitato dauninterazione con il suo ambiente esterno riesca a raggiungere un funzionamen-to di equilibrio prima che avvenga linterazione successiva. Questa proprieta`denita in maniera cos` vaga corrisponde in realta` a caratteristiche ben precisedel modello matematico del sistema. Queste proprieta` matematiche verrannoriprese piu` tardi in queste note. Per il momento ci basti osservare che sistemi diquesto tipo possono essere rappresentati con modelli in cui i sottosistemi ven-gono considerati come scatole nere le cui caratteristiche sono il risultato diuno studio condotto preliminarmente considerando il funzionamento di ognunadi esse in isolamento, cioe` staccate dal resto del sistema.

DRAF

T


secondi

millisecondi

microsecondi

Figura 1.1: Rappresentazione schematica della frequenza di interazione tracomponenti di un sistema

Nel caso dei sistemi di calcolo moderni, lindividuazione dei sottosistemie` spesso abbastanza facile a causa dello stile di programmazione strutturatacomunemente adottata e delle metodologie moderne di implementazione deisistemi software avanzati che si basano sulla composizione e sul riuso di compo-nenti piu` semplici. Lidea dellanalisi gerarchica e` anche molto ane, e resa piu`semplice da applicare, alle tecniche di ranamento top-down della soluzione diproblemi complessi.

1.3.1 Modello Gerarchico di un Sistema di Calcolo

Un caso in cui la costruzione di una sequenza di modelli gerarchici e` abbastanzasemplice e` quando si ha a che fare con sistemi in cui le varie attivita` avvengonocon scale dei tempi molto diverse (vedi Fig. 1.1).

Prendendo spunto da questa considerazione, incominciamo a vedere come siapossibile costruire un modello di un sistema di calcolo iniziando a considerarele sue componenti hardware e ranandone la sua struttura in passi successivi.

Livello dellutente esterno A questo livello di astrazione ogni utente cheusa il sistema inviando dei comandi da terminale (sistema client-server), vede ilsistema stesso come ununica scatola nera capace di rispondere alle sue richiestecon un certo ritardo. Un primo modo di rappresentare questa situazione puo`essere quello delineato in Fig. 1.2 in cui sono evidenziati proprio i terminali(client) ed il sistema centrale (server) nel suo complesso.

DRAF

T


Sistema

Centrale

coda diattesa

...

1

2

N

Terminali

Figura 1.2: Rappresentazione di un sistema time-sharing visto a livello utente

In questo modello ogni job fatto eseguire dallutente (un comando di ricercadi una stringa di caratteri in fase di editing di un le e` un job!) viene consideratocome unentita` indivisibile ed eseguito dal sistema senza interruzione. Il fattoche il sistema non risponda immediatamente alla richiesta dellutente perche`(eventualmente) impegnato nella elaborazione di un altro job e` rappresentatodalla coda di attesa di fronte al sistema centrale.

Possiamo pensare che lintervallo di tempo che separa mediamente linvio didue comandi successivi da parte di un medesimo utente possa essere dellordinedei secondi.

Livello del sistema In realta` noi sappiamo che tutti i sistemi moderni sonomultiprogrammati e che le operazioni di Input/Output richieste da un certo jobsono sovrapposte ad elaborazioni da parte della CPU compiute per un altrotask. Lesecuzione di un programma puo` essere considerata come il susseguirsidi periodi di attivita` della CPU e di periodi di attivita` delle unita` periferiche.Dopo un numero appropriato di cicli lelaborazione termina ed il risultato vienerestituito allutente. Ragioni siche impongono che un numero massimo K dijob possano essere eseguiti in parallelo. K viene chiamato il livello massimo dimultiprogrammazione. Per rendere piu` eciente questo tipo di organizzazione,lattivita` della CPU puo` anche essere interrotta. Questa operazione, chiamatatime-slicing viene eseguita per impedire che un job monopolizzi la CPU a scapi-to dellesecuzione di tutte le altre richieste, rendendo cos` inattivi i processoridedicati alla gestione delle unita` periferiche.

Questi dettagli sono ovviamente tutti ignorati dal modello precedente, mapossono essere presi in considerazione ranando la rappresentazione della sca-tola nera che prima corrispondeva al sistema centrale.

A questo livello di astrazione, una schematizzazione del funzionamento delnostro sistema puo` essere quella contenuta in Fig. 1.3 dove un job in esecuzionepuo` essere immaginato come un oggetto che si muove ripetutamente tra le varie

DRAF

T


...

1

2

N

CPU

DISK

DRUM

Terminali

K

DRAF

T


...

1

2

N

CPUDISK

DRUM

Terminali

K

DRAF

T


iR/Wdata

address

.... .... DISKDRIVER

process i

signal to process i for completion

Figura 1.5: Rappresentazione schematica dellinterazione tra un processo logicoed una unita` periferica sica

Input/Output, oppure alla necessita` di attendere davanti ad un semaforo perragioni di sincronizzazione, oppure alla scadenza di un time slice del processore.

Quando il calcolatore su cui girano questi processi e` un multiprocessore, lecondizioni di sincronizzazione possono provocare delle vere e proprie attese daparte di un processore.

Per fornire un esempio di un processo specializzato, possiamo considerarelesecuzione di unoperazione di I/O in un sistema operativo organizzato aprocessi.

In questo contesto il processo che desidera eseguire loperazione di I/O, nonsi incarica sicamente di questa azione, ma invia un comando opportunamentecodicato ad un processo specializzato che ha il solo compito di gestire unadeterminata unita` periferica. Quando loperazione di trasferimento sara` giun-ta a conclusione, questo processo avvertira` il processo originale dellavvenutocompletamento ed incomincera` a servire unaltra richiesta.

Questa situazione puo` essere rappresentata dallo schema contenuto in Fig. 1.5dove la coda di ingresso al driver contiene la codica dei comandi (Read e Write)da eseguire sullunita` sica (ad un certo indirizzo) per conto di un certo processo(Pi) ed e` quindi una struttura dati a cui possono accedere piu` processi.

Il processo Pi che invia il comando e il processoDriver che interpreta il mes-saggio ed esegue loperazione di trasferimento possono allora essere consideraticome processi cooperanti.

Evidentemente, esistono dei problemi di sincronismo che devono essere af-frontati per evitare (cosa che potrebbe capitare con la coda vuota) che il proces-so Pi ed il processo Driver possano accedere contemporaneamente alla stessaposizione della coda. Analogamente, e` anche necessario evitare che due proces-si Pi e Pj depositino contemporaneamente i loro due messaggi nella medesimaposizione della coda.

Per questa ragione, la struttura dati rappresentante la coda deve esseremodicata solo allinterno di una regione critica2.

Gli eventuali altri processi che vogliano accedere alla struttura dati, se laregione critica e` occupata, dovranno attendere allesterno.

2Una regione critica e` un costrutto software che, in ogni istante, permette al suo internouno ed uno solo processo.

DRAF

T


1

M

Analisi del dead-lock

Retedi

modulinon

critici

Regioni critiche

...

Figura 1.6: Accesso coordinato di processi concorrenti a regioni critiche

Premesse queste considerazioni, un sistema di calcolo che possiede piu` pro-cessori puo` essere modellato da un punto di vista software rappresentando imoduli software come entita` siche statiche, mentre i processori possono essereconsiderati come degli oggetti che circolano da un modulo software allaltro edeventualmente attendono in coda quando intendono eseguire una porzione diprogramma racchiusa allinterno di una regione critica gia` in uso da parte di unaltro processore.

Evidentemente la presenza di regioni critiche in un sistema puo` portare adelle situazioni di dead-lock. In generale, ci sara` allora un modulo software che,prima di permettere ad un processo di accodarsi nella lista di attesa di unaregione critica, analizzera` lo stato del sistema e verichera` che questa mossanon porti il sistema in dead-lock3.

Lesecuzione dei processori puo` allora essere immaginata come una serie dicicli del seguente tipo:

esecuzioni di moduli non critici

esecuzione del modulo contenente il meccanismo di analisi del dead-lock

esecuzione della regione critica

Un possibile modello risultante e` quello riportato in Fig. 1.6.

Modelli di questo tipo sono stati utilizzati in letteratura per analizzare lef-fetto della presenza di regioni critiche in sistemi multi-processore. Un risultatopossibile di unanalisi di questo tipo e` la quanticazione del vantaggio realederivante dallaggiunta al sistema di un processore in piu`.

3Un approccio di questo tipo viene chiamato nel contesto della teoria dei sistemi operatividead-lock avoidance

DRAF

T


Modello dettagliato

(livello di astrazione

basso)

Modello risultante

(livello di astrazione

elevato)

sottosistema i sottosistema j

Esperimenticontrollati

stazione

equivalente

SISTEMA

j

i

stazione

equivalente

SISTEMA

sottosistema i

sottosistema j

Figura 1.7: Rappresentazione schematica dellanalisi gerarchica di un modellocomplesso

1.4 Implicazioni pratiche della modellazione ger-

archica

Lo sviluppo di modelli gerarchici si basa sullipotesi, gia` accennata in preceden-za, che sia possibile individuare allinterno di un sistema (di calcolo) complessola presenza di gruppi di componenti (sottosistemi) il cui comportamento siasucientemente indipendente da quello del resto del sistema (dal contesto incui sono inseriti). In questi casi, detti sottosistemi possono essere analizzati inisolamento con lobiettivo di costruirne delle rappresentazioni equivalenti chepossano essere utilizzate in modelli di alto livello, mascherando il loro compor-tamento interno ed esibendo solamente quegli aspetti che li caratterizzano dalpunto di vista delle loro interazioni. In pratica, questo corrisponde alla con-duzione di esperimenti, detti controllati, i cui risultati possono essere utilizzatiper parametrizzare una stazione equivalente (una scatola nera che li rappresen-ta) che puo` cos` venire utilizzata in modelli del sistema corrispondenti ad unlivello di astrazione superiore, come indicato schematicamente in Fig. 1.7. Letecniche usate per lanalisi dei sottosistemi in isolamento possono essere le piu`svariate e quindi si puo` pensare di studiare il comportamento del sottosistemautilizzando un modello analitico, oppure un modello di simulazione, oppure unapproccio gerarchico piu` dettagliato. Queste metodologie possono essere uti-lizzate contemporaneamente per studiare diverse componenti di un medesimosistema dando cos` luogo a quella che e` chiamata una Simulazione Ibrida.

DRAF

T

1.5. VALUTAZIONE DELLE PRESTAZIONI 17

1.5 Valutazione delle prestazioni dei sistemi di-

namici ad eventi discreti

Una delle ragioni per lo sviluppo di un modello di un DEDS e` quella dellarealizzazione di una rappresentazione formale che possa essere utilizzata perottenere degli indicatori numerici utili per guidare la scelta tra alternative ar-chitetturali diverse in modo da progettare un sistema con le migliori prestazionipossibili e per assistere le strategie operative necessarie per assicurare un buonfunzionamento anche in presenza di possibili guasti.

Per raggiungere questo obiettivo e` necessario che il formalismo utilizzato persviluppare il modello permetta di includere delle speciche temporali (normal-mente espresse in termini di ritardi necessari per compiere determinate azioni)e delle informazioni relative allinstradamento di oggetti allinterno del sistemain maniera naturale.

La grande diversita` dei sistemi reali e` comunemente riessa nel modello permezzo delluso di variabili casuali che portano alla costruzione (ed alla successivasoluzione) di modelli probabilistici.

La valutazione delle prestazioni e delladabilita` dei sistemi e` lambito sci-entico che usa i modelli matematici e simulativi per il calcolo di indici diprestazione legati al tempo.

I modelli introdotti nelle sezioni precedenti si congurano come delle reti dicode (o di le di attesa o di punti di congestione) rappresentati per mezzo diun formalismo che non e` specico dei questi sistemi, ma che ha una validita` piu`generale. Lanalisi di modelli di questo tipo e` condotta utilizzando una brancadella probabilita` applicata che si chiama Teoria delle code.

Modelli a rete di code vengono usati per rappresentare situazioni di tracoche possono presentarsi con signicati e in contesti molto diversi:.

traco urbano (automobili, strade, semafori, rotonde,...) traco di persone (clienti di una banca o di un supermercato, pazienti inunospedale,...)

traco di oggetti (sistemi di produzione con pezzi lavorati da piu` macchinein cascata, carrelli trasportatori, ...)

traco di comunicazioni (messaggi telefonici, pacchetti circolanti in unarete di telecomunicazione, ...)

traco di processi (componenti software di sistemi operativi o di basi didati, ussi organizzativi, work-ow, ...)

Questo elenco fa vedere come le metodologie che tratteremo nei prossimicapitoli non sono solamente utilizzabili in ambito informatico, ma hanno unavalenza molto piu` ampia.

Nella discussione generale condotta no a questo punto si e` sempre generica-mente parlato di studio del comportamento di un sistema, senza precisare megliogli obiettivi di questanalisi.

DRAF

T


Negli esempi precedenti abbiamo visto come i sistemi possano essere rappre-sentati da reti di code che interagiscono tra di loro. E allora abbastanza naturalepensare che le prestazioni dei sistemi che noi esamineremo saranno valutate inbase al comportamento di queste code o stazioni di servizio.

Le grandezze a cui noi rivolgeremo la nostra attenzione sono:

Lunghezze delle code Tempi di attesa trascorsi dai job (clienti) nelle code del sistema prima diricevere servizio

Utilizzazioni delle stazioni di servizioPoiche abbiamo deciso di studiare il comportamento dei DEDS per mezzo

di modelli stocastici, tutte queste grandezze non hanno un valore preciso eunico, ma sono piuttosto caratterizzate da distribuzioni di probabilita` ovveroda frequenze con cui i loro valori sono stati osservati durante diversi periodi dimisura.

Queste distribuzioni sono spesso dicili (o costose) da calcolare ed e` per-tanto comunemente accettata la prassi di denire il comportamento del sistemaspecicando i seguenti indici (medi) di prestazione:

Utilizzazione (U): Frazione di tempo durante il quale una stazione e`risultata occupata

Throughput (X): Numero medio di operazioni completate dalla stazionedi servizio nellunita` di tempo

Lunghezza media della coda (n): Numero medio di job (clienti) in attesadi ricevere (e/o riceventi) servizio dalla stazione

Tempo medio di soggiorno (w): Durata media dellintervallo di tempointercorrente tra listante di arrivo di un job (cliente) alla stazione diservizio e quello della sua partenza

A questi indici medi di prestazione si puo` anche aggiungere la distribuzioneseguente:

pi(n) che rappresenta la frazione di tempo durante cui la stazione diservizio di indice i ha avuto n job (clienti) al suo interno (in coda e/oservizio), sapendo che spesso essa non verra` calcolata per ogni possibilevalore di n, ma solamente per alcuni punti signicativi

1.6 Pianificazione di un esperimento di model-listica

Indipendentemente dal metodo di analisi utilizzato per studiare il comportamen-to di un determinato sistema, lesperimento di studio per mezzo di un modellodovrebbe sempre essere preparato seguendo una procedura di questo tipo:

DRAF

T

1.6. PIANIFICAZIONE DEGLI ESPERIMENTI 19

1. Formulazione del problema

2. Acquisizioni di dati dal sistema reale

3. Formulazione del modello

4. Stima dei parametri e delle caratteristiche operative del sistema reale

5. Analisi preliminare del modello

6. Calcolo degli indici di prestazione

7. Convalida dei risultati del modello

8. Progetto degli esperimenti

9. Analisi dei risultati

Non ce` accordo unanime sulla necessita` e sullordine con cui queste fasidevono susseguirsi. Evidentemente, i vari punti assumono rilevanza diversaa seconda degli studi che vogliono essere condotti e delle metodologie usate,tuttavia una pianicazione di questo tipo assicura una migliore interpretazionedei risultati dellesperimento.

Formulazione del problema Formulare il problema signica ssare gli obi-ettivi dello studio e stabilire i criteri per valutare le soluzioni al problema.

Tra gli obiettivi di un esperimento di studio con modelli, possiamo identi-care tre casi:

Progettazione (Dimensionamento) di sistemi: Stima degli indici diprestazione del sistema reale (non ancora esistente), sulla base di ipotesirelative ai parametri ed alle caratteristiche funzionali di comportamnento,per decidere come scegliere tra varie alternative.

Miglioramento di sistemi: Valutazione (calcolo) degli indici di prestazionedi un sistema esistente e studio degli eetti del cambiamento dei parametrio delle caratteristiche funzionali sul comportamento del sistema. Analisidelle strozzature e comportamento asintotico al variare dellintensita` delcarico.

Scelta di sistemi: Valutazione delle prestazioni di diversi sistemi es-istenti sottoposti a condizioni di carico simili o confrontabili.

Acquisizioni di dati dal sistema reale La denizione dei parametri diun modello rappresenta una delle operazioni piu` dicili da eseguire. I risul-tati di un modello sono fortemente condizionati dalla precisione della stima deiparametri di ingresso. Spesso la scarsa attendibilita` dei risultati di un modellodeve essere attribuita piu` allinaccuratezza dei parametri di ingresso che nonalle decienze strutturali del modello stesso. Quando si ha a disposizione unsistema reale di cui si vuole costruire un modello, i parametri di questultimo

DRAF

T


devono essere ottenuti da misurazioni eseguite sul sistema reale. In fase di pro-getto, i parametri vanno ricavati da misure eseguite su sistemi confrontabili.Nel caso del progetto di sistemi veramente nuovi, questi parametri devono es-sere ipotizzati. Un aspetto particolarmente interessante e dicile da trattare e`la stima delle distribuzioni associate ai parametri dingresso. La denizione deiparametri dingresso e` spesso resa piu` dicile dallincertezza relativa alle per-sone che interagiscono con il sistema e che ne rappresentano il carico. Questoaspetto diventa particolarmente importante quando lobiettivo dello studio e` lascelta tra soluzioni alternative perche` in realta` scelte diverse comportano anchespesso modi diversi di utilizzo.

Formulazione del modello La specica del modello avviene in tre fasi:

Specicazione delle componenti Specicazione delle variabili Specicazione delle relazioni funzionaliLa specicazione delle componenti e` direttamente legata al tipo di studio che

si deve compiere e che denisce il livello di astrazione con cui il modello deverappresentare il sistema reale. La scelta del modello e` pero` anche condizionatada considerazioni circa la complessita` (logica e computazionale) del modellostesso, la scelta della metodologia di analisi ed i costi dellesperimento.

La specicazione delle variabili ha un impatto notevole sulle dimensioni delproblema da analizzare. Per esempio, la scelta di una descrizione troppo det-tagliata dello stato del sistema puo` condurre, oltre che ad un problema di piu`dicile soluzione, anche alluso di quantita` di risorse (memoria e tempo) de-cisamente elevate. La scelta delle variabili di ingresso che hanno rilevanza perlo studio che si vuole compiere ha unimportanza particolare. La specicazionedelle relazioni funzionali e` normalmente legata al tipo di problema che si staanalizzando.

Stima dei parametri e delle caratteristiche operative del sistema realeQuesto passo ha il compito di trasferire nel modello i parametri e le carat-teristiche operative del sistema reale, stimate sulla base dei dati raccolti inprecedenza. Esso si traduce nellapplicare tecniche statistiche per la stima deitipi di distribuzioni interessate e dei loro momenti. In questa fase rientranoanche i metodi per lapprossimazione di caratteristiche operative a partire dainformazioni ricavate sperimentalmente (metodi dei minimi quadrati, analisi diregressione, ...).

Analisi preliminare del modello La validita` della stima dei parametri din-gresso e delle loro distribuzioni deve essere accertata facendo uso di test stati-stici. In questa fase e` consigliabile fare anche uso delle proprieta` matematiche estatistiche delle componenti del modello per rendersi conto dellimportanza checerte scelte possono avere sui risultati dellesperimento. Per esempio, carichi

DRAF

T

1.6. PIANIFICAZIONE DEGLI ESPERIMENTI 21

di lavoro molto vicini alla capacita` massima di una stazione di servizio dannoluogo a code molto lunghe e tendono a rallentare la velocita` con cui il sistema siporta in condizioni operative di equilibrio. Oppure, certe discipline di gestionedella coda di attesa possono avere eetti diversi sui momenti (valori medi difunzioni) delle grandezze usate per il calcolo degli indici di prestazione.

Calcolo degli indici di prestazione Questa fase corrisponde alla stesura delprogramma che dovra` calcolare gli indici di prestazione del modello. Se il meto-do di analisi e` la simulazione, la prima cosa importante da decidere e` la sceltadel linguaggio di programmazione o del package applicativo da adottare. Unelemento importante che compare nella programmazione di un modello di sim-ulazione e` la scelta dello stato iniziale e del metodo di raccolta delle statistichedel modello che serviranno per il calcolo degli indici di prestazione.

Se la tecnica di analisi utilizzata e` quella analitica o numerica, occorrera`decidere quale metodo di calcolo utilizzare e se ricorrere alluso di programmispecializzati reperibili commercialmente.

Convalida dei risultati del modello In questa fase e` necessario vericareladeguatezza del modello nel rappresentare il sistema reale oggetto di stu-dio. Eventuali discordanze possono essere dovute sia ad errori di implemen-tazione (errori logici di programma ed errori di scrittura) sia alla validita` edalla rilevanza delle ipotesi introdotte nella fase di costruzione del modello.

Per vericare la presenza di errori di implementazione, si puo` applicare ilprogramma a casi noti controllando lattendibilita` dei risultati ottenuti. Laconvalida delle ipotesi viene invece condotta facendo uso dei test statistici diipotesi.

Progetto degli esperimenti Quando i parametri di ingresso possono varia-re allinterno di certi intervalli piuttosto ampi, combinazioni diverse dei valoriassunti dagli stessi possono dare luogo a scenari molto dierenti e quindi a risul-tati molto diversi fra loro. Si dice in questo caso che lo spazio degli esperimentie` molto ampio e che e` necessario progettare linsieme degli esperimenti da con-durre per ottenere le indicazioni desiderate con il minimo costo. Questa fasearonta quindi due ordini di problemi:

Problemi di pianicazione strategica destinata alla progettazione di uninsieme di esperimenti da condurre

Problemi di pianicazione tattica intesa a stabilire le modalita` di con-duzione del singolo esperimento.

La strategia deve stabilire con quali criteri il sistema debba essere guidato at-traverso lo spazio degli esperimenti possibili e quale livello di signicativita`attribuire alle variazioni dei risultati osservati nei vari esperimenti. La tatticadeve stabilire come eseguire gli esperimenti. Nel caso della simulazione, questopuo` voler dire decidere quante esecuzioni del simulatore fare per ogni esperimen-to. Nel caso delluso di metodo analitici o numerici, puo` voler dire come variare

DRAF

T


i livelli di precisione con cui si devono calcolare i risultati o come assegnare gliindici alle diverse stazioni di servizio del sistema.

Analisi dei risultati Questa ultima fase, e` una delle piu` dicili ed e` stretta-mente legata al tipo di problema analizzato ed alla tecnica di analisi utilizzata.In ogni caso, linterpretazione dei risultati deve tenere conto dei seguenti punti:

Sensibilita` dei risultati ad errori (o variazioni) dei parametri dingresso Identicazione delle variabili di ingresso e di stato eettivamente rilevantiai ni dello studio condotto

Studio esplicito dellimportanza delle ipotesi introdotte nelle fasi di costruzionee di scelta dei parametri del modello.

1.7 Osservazioni finali

Prima di terminare questa parte introduttiva, ricordiamo che per il caso specicodello studio delle prestazioni del comportamento dei sistema di calcolo e ditelecomunicazione, loggetto da valutare e` in realta` un sistema schematizzabilenel seguente modo:

non-deterministico deterministico

WORKLOAD(carico di lavoro) SISTEMA

Figura 1.8: Rappresentazione di un sistema time-sharing visto a livello dellecomponenti di hardware

Il problema della valutazione delle prestazioni di un sistema di questo tipoconsiste quindi nella caratterizzazione del carico di lavoro a cui e` sottoposto ilsistema e nella scelta delle tecniche di analisi da utilizzare.

Il carico di lavoro e` la quantita` di servizio richiesta (od imposta) ad undeterminato sistema e corrisponde quindi alla specicazione delle variabili diingresso del modello espressa normalmente in termini di:

DRAF

T

1.7. OSSERVAZIONI FINALI 23

Processo con cui le richieste sono sottoposte al sistema (frequenza degliarrivi, variabilita` della cadenza, ...)

Quantita` di attivita` di CPU associata ad ogni richiesta Quantita` di memoria centrale usata da ogni programma Quantita` di operazioni di I/O associate ad ogni programma Numero di moduli software usati da ogni programmaIl funzionamento del sistema, che e` spesso intrinsecamente deterministico, as-

sume quindi una connotazione stocastica proprio per eetto delle caratteristichedel carico di lavoro che tiene conto al suo interno della natura aleatoria dellin-terazione del sistema con la componente umana. Interagendo quindi il sistemacon delle persone, diventa indispensabile considerare la natura stocastica del-loggetto di studio e quindi sviluppare tecniche di analisi basate essenzialmentesullo studio dei processi stocastici.

DRAF

T


DRAF

TBibliografia

25

Documents

Capitolo01 f