Studio e Realizzazione di Architetture Concorrenti per Sistemi ad ...

UNIVERSITÀ DEGLI STUDI DI PARMA 

FACOLTÀ DI INGEGNERIA 

CORSO DI LAUREA IN INGEGNERIA INFORMATICA 

STUDIO E REALIZZAZIONE 

DI 

ARCHITETTURE CONCORRENTI 

Relatore: 

Chiar.mo Prof. AGOSTINO POGGI 

Correlatore: 

Dott. Ing. GIOVANNI RIMASSA 

PER 

SISTEMI AD AGENTI 

ANNO ACCADEMICO 2000/2001 

Tesi di Laurea di: 

FABIO G. ONERI

Alle persone che mi sono care 

e che sono state felici 

di vedere questo giorno 

ed a quelle 

che certamente lo sarebbero state: 

Adriano, Giacomo 

e Roberto.

SOMMARIO 

1 INTRODUZIONE .................................................................................................. 1 

1.1 SISTEMI AD AGENTI ...................................................................................... 1 

1.1.1 Gli Agenti e le discipline informatiche............................................ 1 

1.1.2 Standard per gli ISA ...................................................................... 3 

1.1.3 JADE............................................................................................. 4 

1.2 ARCHITETTURE CONCORRENTI...................................................................... 4 

1.2.1 Cosa si intende per concorrenza................................................... 4 

1.2.2 Problemi insiti nella concorrenza................................................... 5 

2 ARCHITETTURE CONCORRENTI IN PRODOTTI A LARGA DIFFUSIONE ...... 8 

2.1 IL MIDDLEWARE ........................................................................................... 8 

2.1.1 Cos'è un Middleware..................................................................... 9 

2.1.2 Il Middleware come prodotto informatico..................................... 10 

2.1.3 Problematiche connesse alla concorrenza.................................. 10 

2.2 DCOM...................................................................................................... 11 

2.2.1 Introduzione ................................................................................ 11 

2.2.2 Panoramica sull'architettura........................................................ 16 

2.2.3 Modelli di concorrenza ................................................................ 19 

2.3 CORBA.................................................................................................... 22 

2.3.1 Introduzione ................................................................................ 22 


2.3.3 Specifiche per la concorrenza..................................................... 24 

2.3.4 Un esempio d'implementazione: ORBacus ................................. 27 

2.4 EJB.......................................................................................................... 31 

2.4.1 Introduzione ................................................................................ 32 


2.4.3 Specifiche per la concorrenza..................................................... 35 

2.5 CONFRONTI ............................................................................................... 35 

2.5.1 DCOM e CORBA: creare l'infrastruttura per la comunicazione ... 36 

2.5.2 Modelli di concorrenza: flessibilità, semplicità e sicurezza.......... 37

3 JADE.................................................................................................................. 40 

3.1 ARCHITETTURA.......................................................................................... 40 

3.1.1 La piattaforma FIPA-compliant.................................................... 41 

3.1.2 L'amministrazione degli Agenti.................................................... 43 

3.1.3 Modello comportamentale........................................................... 44 

3.2 CONCORRENZA: MODELLO THREAD-PER-AGENT.......................................... 46 

4 MODELLO DI CONCORRENZA PROPOSTO .................................................. 48 

4.1 GRANULOSITÀ DELLA CONCORRENZA .......................................................... 48 

4.2 STRUMENTI ADOTTATI................................................................................. 49 

4.2.1 Il dispatcher................................................................................. 49 

4.2.2 Lo scheduling ricorsivo................................................................ 50 

4.3 MAPPING DI MODELLI CON GLI STRUMENTI SCELTI ......................................... 51 

5 IMPLEMENTAZIONE DI RIFERIMENTO........................................................... 52 

5.1 EMBEDDEDTHREAD.................................................................................... 52 

5.1.1 Scopi e funzionalità ..................................................................... 53 

5.1.2 Meccanismi di sincronizzazione degli accessi: lock .................... 54 

5.1.3 Ispezione e modifica dello stato .................................................. 55 

5.1.4 Transizioni temporizzate ............................................................. 57 

5.1.5 Ispezione ed assegnazione dell'attività ....................................... 63 

5.1.6 Mutex .......................................................................................... 65 

5.2 THREADDISPATCHER.................................................................................. 68 


5.2.2 Ispezione e modifica dei parametri del Thread-Pool ................... 70 

5.2.3 Dispatching e gestione dei thread............................................... 70 

5.2.4 Amministrazione delle richieste degli scheduler e dei thread...... 73 

5.2.5 ReadyThreadsManager............................................................... 76 

5.2.6 RequestsManager....................................................................... 79 

5.3 SCHEDULER............................................................................................... 83 


5.3.2 La classe astratta........................................................................ 84 

5.3.3 Affidamento e rimozione di Behaviour......................................... 84

5.3.4 Blocco e risveglio di Behaviour ................................................... 87 

5.3.5 Scheduling: notifiche, ispezioni, richieste e terminazione ........... 88 

5.3.6 Amministrazione dei cambiamenti di stato dei Behaviour ........... 92 

5.3.7 Cambiamenti di stato imposti ai Behaviour dall'esterno .............. 96 

5.3.8 Sottoclassi Concrete ................................................................... 99 

5.4 GESTIONE DELLE INTERRUZIONI................................................................. 100 

5.4.1 Catena ascendente................................................................... 100 

5.4.2 Catena discendente .................................................................. 102 

5.4.3 Metodi non interrompibili ........................................................... 105 

5.4.4 Problemi con InterruptedException ........................................... 107 

5.5 CLASSI DI UTILITÀ..................................................................................... 112 

5.5.1 AssociationTimerObject ............................................................ 113 

5.5.2 Deadline.................................................................................... 116 

5.6 MODIFICHE ALL'AMBIENTE ........................................................................ 117 

5.6.1 Behaviour.................................................................................. 117 

5.6.2 CompositeBehaviour................................................................. 118 

5.6.3 Agent......................................................................................... 120 

5.7 TESTING DELL'IMPLEMENTAZIONE.............................................................. 121 

6 CONCLUSIONI ................................................................................................ 123 

6.1 ULTERIORI SVILUPPI................................................................................. 124 

6.2 RINGRAZIAMENTI...................................................................................... 124 

7 BIBLIOGRAFIA ............................................................................................... 126

Introduzione - Sistemi ad Agenti 1 

1 Introduzione 

Scopo del presente lavoro è un'analisi di modelli di concorrenza per il loro utilizzo in 

applicazioni basate sugli agenti. Dopo una panoramica su diversi paradigmi già 

esistenti in applicazioni middleware ampiamente diffuse, quali DCOM, CORBA ed 

EJB, ed un loro confronto, si studierà il caso specifico di JADE (Framework per 

agenti sviluppato da TILab e l'università di Parma) e possibili miglioramenti 

apportabili. Si proporrà quindi un nuovo modello di concorrenza e relativa 

implementazione di riferimento. 

1.1 Sistemi ad Agenti 

Negli ultimi anni, avvenimenti quali la diffusione di Internet, la grande disponibilità 

d'informazioni distribuite, le diffuse potenze di calcolo disponibili anche sul lato degli 

utenti ed il crescente livello d'astrazione di applicativi, capaci di offrire interfacce 

uomo-macchina sempre più intuitive ed "intelligenti", hanno portato alla luce un 

nuovo paradigma per lo sviluppo di sistemi, basato sulla cooperazione di entità 

autonome intelligenti, capaci di muoversi in rete, reperire informazioni, collaborare tra 

loro: queste entità sono gli Agenti. 

1.1.1 Gli Agenti e le discipline informatiche 

Nella disciplina dell'Intelligenza Artificiale, e nelle sue molteplici definizioni, centrale è 

il ruolo giocato dagli Agenti. L'Artificial Intelligence (AI) si propone, infatti, come 

"quella parte della computer science il cui scopo è costruire Agenti che mostrino 

comportamento intelligente". 

Questa definizione, che rimane volutamente nel vago per consentire una più ampia 

generalizzazione, non spiega però cosa s'intenda per Agente. Esistono in realtà varie 

definizioni per questo concetto, dalle più deboli e generiche come "entità autorizzata 

ad agire per conto d'altre parti” (espressione utilizzabile ad esempio anche per gli 

"agenti finanziari"), fino ad arrivare a specializzazioni tecniche di abilità e


comportamenti che caratterizzano l'Agente stesso. Nell'ambito del presente lavoro ci 

si limiterà a considerare gli Agenti Software Intelligenti, dove con tale espressione si 

intendono "agenti artificiali operanti, con tecniche di AI, in un ambiente software“. 

Questo recente paradigma ad Agenti è assorto ad importanza nella 

computer science principalmente per alcune peculiarità insite nella definizione quali: 

?? Autonomia: un agente ha controllo diretto sulle proprie azioni e stato interno, ed è 

capace di comportamenti reattivi e pro-attivi. Può, cioè, percepire l'ambiente in cui 

opera e rispondere ai suoi stimoli, ed è capace di mostrare comportamenti 

goal-directed prendendo quindi iniziative. 

?? Delega: agisce, possibilmente con competenza, per conto di altri. 

Oltre alle suddette, altre caratteristiche rendono il modello particolarmente 

vantaggioso rispetto a metodi classici, come ad esempio: 

?? Mobilità: la capacità di alcuni Agenti di muoversi da un ambiente ad un altro (Es. 

sfruttando Internet) verso dati e risorse, evitando le tradizionali migrazioni dei dati, 

ed ottimizzando di conseguenza le prestazioni. 

?? Socialità: capacità di creare istanze multiple che operino in modo collaborativo 

parallelizzando il lavoro. 

Queste proprietà rendono gli Agenti particolarmente adatti a scenari in cui siano 

preponderanti la mole di lavoro e l'esibizione di comportamenti intelligenti (in modo 

specifico nelle interazioni con gli utenti). Tipici esempi di problemi che meglio si 

adattano ad essere risolti usando gli Agenti Software sono: 

?? Sistemi computerizzati per il controllo del traffico aereo. 

?? Personal digital assistant (PDA). 

?? Reperimento di documenti (data filtering). 

Gli attributi che si richiedono ad un Intelligent Software Agent (ISA) sono certamente 

più consoni alla descrizione che si farebbe di un essere umano, che non a quella di 

un prodotto informatico: esigiamo, infatti, qualità quali autonomia, capacità di 

prendere iniziative, mobilità, abilità sociali come comunicazione e contrattazione, 

ecc. Ci si riferisce quindi ad un ISA come ad un Sistema Intenzionale, un sistema 

cioè il cui comportamento "può essere predetto e spiegato attraverso l’attribuzione di 

atteggiamenti quali convinzioni, desideri, speranze, paure, ecc.”. Bisogna ricordare


però che non si tratta di sterile antropomorfismo, in quanto "attribuire ad una 

macchina desideri e convinzioni, … è utile quando questo possa aiutarci a 

comprenderne la struttura, comportamenti, e possibili sviluppi, … o quando si 

applichi ad entità la cui struttura sia solo parzialmente nota” [Bibl. 1] [Bibl. 2]. 

1.1.2 Standard per gli ISA 

Quanto detto sopra può far intuire quanta complessità si celi dietro la realizzazione di 

un'applicazione basata sugli Agenti, e come possa essere complicato creare le 

infrastrutture, e le standardizzazioni necessarie per l'implementazione delle attitudini 

di un ISA. Per comprendere tali problemi bisogna focalizzarsi su due punti 

fondamentali: 

1. Per implementare la Mobilità, un Agente deve essere capace di comunicare, in 

maniera indipendente dalla tecnologia, con macchine hardware eterogenee, deve 

essere capace di serializzarsi (trasformare la propria struttura ed il proprio stato 

interno in dati che possano essere trasmessi alla macchina di destinazione, ed 

usati in seguito per ricreare l'Agente), deve poter invocare azioni su agenti 

residenti su altre piattaforme, ecc. 

2. Per acquisire Socialità deve poter contare su un linguaggio e protocolli comuni tra 

Agenti diversi, utilità per l'individuazione degli Agenti presenti su una piattaforma 

e dei servizi che possono offrire, ecc. 

Dovendo standardizzare queste capacità, diversi gruppi di ricerca sono stati costituiti 

con l'intento di esplorare le problematiche insite in tali scenari, e sono infine giunti (i 

lavori sono comunque in costante sviluppo) a documenti ormai largamente accettati 

come riferimento (anche perché non legati ad alcun particolare produttore, ma 

"aperti"). Tra le diverse standardizzazioni, di notevole diffusione sono le specifiche 

FIPA per l'interoperabiltà tra applicazioni basate sugli Agenti, e lo standard CORBA 

per la creazione delle infrastrutture necessarie agli ambienti basati sugli agenti [Bibl. 

3] [Bibl. 12].

Introduzione - Architetture Concorrenti 4 

1.1.3 JADE 

JADE (Java Agent DEvelopment Framework) è un'interfaccia di sviluppo software 

pensata per facilitare il compito di quei programmatori che intendano sviluppare 

applicazioni basate sul modello degli Agenti. Il Framework è conforme agli standard 

FIPA, ed è interamente scritto usando Java per sfruttarne le funzionalità di 

programmazione object-oriented in ambienti distribuiti eterogenei (serializzazione ed 

RMI). 

L'utilizzatore del Framework può quindi trovare un valido supporto per lo sviluppo 

dell'applicazione, disinteressandosi degli aspetti di basso livello, e concentrando il 

lavoro direttamente a sull'organizzazione della comunità d'agenti da lui pensata. Il 

prodotto contiene, infatti, una piattaforma FIPA-compliant funzionante, e pacchetti 

Java per lo sviluppo di Agenti: il progettista non dovrà fare altro che usare le classi 

fornite (naturalmente sviluppando il tutto per mezzo del linguaggio Java) come 

classi-base per i suoi Agenti, ed usare la piattaforma per la messa operativa del tutto. 

La piattaforma è inoltre provvista di alcuni utili strumenti (naturalmente Agenti) che 

ne facilitano la monitorizzazione per le fasi di testing e debugging delle applicazioni 

[Bibl. 5]. 

1.2 Architetture Concorrenti 

La concorrenza è un meccanismo che consente a più entità di svolgere operazioni 

differenti nello stesso tempo. Può portare ad un sistema benefici quali collaborazioni 

tra entità, miglioramento delle prestazioni ed efficacia nell'utilizzo delle risorse, ma 

anche diversi problemi se non amministrata correttamente [Bibl. 4]. 

1.2.1 Cosa si intende per concorrenza 

In un sistema operativo, i diversi compiti che la macchina può eseguire sono detti 

processi. Un processo è essenzialmente un programma eseguito dal calcolatore. Nei 

primi sistemi operativi ogni processo impegnava totalmente la macchina, e doveva 

essere eseguito singolarmente su di essa, senza che altri compiti potessero essere


avviati prima della terminazione di quello in corso. Dal momento che un programma 

non occupa necessariamente al pieno delle proprie possibilità le risorse di un 

computer, ma è formato essenzialmente da sezioni di calcolo (che impegnano la 

CPU) ed input/output (su memorie e periferiche) che possono richiedere attese, 

accade che, durante l'esecuzione di un processo, le risorse di una macchina passino 

da momenti di attività a periodi d'inattività. 

I moderni sistemi, sfruttando tali pause nelle attività di CPU e memoria, consentono 

ad un calcolatore di eseguire più processi contemporaneamente, e quindi di 

ottimizzare l'uso delle risorse di macchina (questo non è però l'unico strumento 

adottato per ottenere il parallelismo) 

Due o più processi, per i quali l'inizio dell'esecuzione dell'uno avviene prima che altri 

abbiano terminato, sono detti concorrenti. I processi possono essere indipendenti od 

interagenti. Processi interagenti creano complessivamente un nuovo stato 

nell'esecuzione, che differisce da quello che si avrebbe se fossero eseguiti 

sequenzialmente: i processi si condizionano vicendevolmente. 

Secondo il tipo di interazione che si ha tra processi, questi possono essere: 

?? Collaboranti: quando le interazioni sono prevedibili e desiderate 

?? In competizione: se è presente l'uso di risorse comuni, ma non usabili 

simultaneamente 

?? Interferenti: quando l'interazione non è né prevista, né desiderata, ma dovuta ad 

errori di qualche genere. 

1.2.2 Problemi insiti nella concorrenza 

Quando si ha a che fare con processi, o parti di processi, interagenti, si deve 

amministrare un sistema il cui comportamento è maggiore della somma dei 

comportamenti delle parti. Sezioni di programmi che funzionano correttamente 

quando eseguite ognuna per suo conto, possono risultare interferenti se eseguite 

contemporaneamente su thread diversi. Lo studio di tali condizioni non è sempre 

agevole, in quanto ogni esecuzione ha una componente aleatoria che la rende


difficilmente riproducibile: un problema di interferenza potrebbe non presentarsi per 

diverse esecuzioni e manifestarsi quando meno lo si aspetta. 

Bisogna, innanzi tutto, tenere conto di quelle risorse e variabili condivise che 

possono essere accessibili da più linee d'esecuzione differenti. Molte risorse, infatti, 

per essere utilizzabili correttamente, hanno la necessità di "servire" un solo client per 

volta, ed eseguire i diversi comandi che questo invia loro senza che nuovi utenti 

possano frapporvene altri. Per il mantenimento della coerenza interna è spesso 

necessario che un set di più operazioni sia considerato atomicamente: nasce così 

l'esigenza di ottenere la mutua esclusione su parti di codice che sono chiamate 

"sezioni critiche". 

L'accesso a questi aggregati di operazioni (o sessioni d'utilizzo di risorse macchina), 

è regolato da costrutti di sincronizzazione che ne garantiscono un accesso 

sequenzializzato: questi possono operare a diversi livelli di astrazione e 

comprendono algoritmi specifici, semafori, mutex, regioni critiche, monitor, etc. 

Prescindendo dallo strumento utilizzato, le operazioni di sincronizzazione, che 

comportano tutte possibili attese per l'accesso alle risorse (visto che queste devono 

essere utilizzate sequenzialmente), possono essere fonte di svariati problemi che 

vanno da uno scorretto utilizzo degli accessi (con conseguente incoerenza di dati), a 

situazioni di stallo per tutto un sistema. 

Quest'ultimo problema, chiamato "deadlock", o "blocco critico", anche se 

ampiamente trattato nella letteratura dei sistemi operativi, è particolarmente grave e 

di difficile individuazione, in quanto ogni situazione è particolare e va analizzata nel 

complesso delle proprie interazioni. Un deadlock può avvenire, ad esempio, quando, 

dati due thread d'esecuzione (T1 e T2) e due risorse (A e B), con A posseduta da T1 

e B posseduta da T2, T1 cerchi di ottenere anche B (entrando nella sua coda di 

attesa ed aspettando che B sia liberata da T2) mentre, simultaneamente, T2 richieda 

A: i thread si bloccano entrambi aspettando interminabilmente che l'uno liberi l'altro. 

Il controllo e la verifica della presenza di situazioni come quella descritta, comporta, 

per il programmatore, un'approfondita analisi di tutte le possibili interazioni tra 

componenti e dei loro casi d'uso, e può risultare molto impegnativa. In fase di 

progetto diventa, quindi, molto importante dosare le prestazioni ottenibili dalla


concorrenza con la semplicità nella manutenzione dello stesso: anche piccole 

modifiche nella sequenza d'esecuzione di alcune operazioni possono essere, infatti, 

fonte di blocchi critici.

Architetture Concorrenti in prodotti a larga diffusione - Il Middleware 8 

2 Architetture Concorrenti in prodotti a larga 

diffusione 

Questo capitolo presenta una panoramica su come alcuni tra i prodotti informatici 

middleware più diffusi sul mercato affrontino la questione della concorrenza ed i 

problemi correlati con tali scelte. Dopo una trattazione generale della questione, 

saranno esposte brevemente le caratteristiche architetturali di ogni prodotto, ed una 

specifica visione degli aspetti di gestione dei thread. 

2.1 Il Middleware 

L'attuale scenario degli ambienti orientati alla computazione si presenta alquanto 

eterogeneo per hardware, sistemi operativi, tecnologie di rete e linguaggi di 

programmazione. Le ragioni di queste diversità sono solitamente storiche: le 

innovazioni tecnologiche e le innumerevoli scelte organizzative ed implementative, 

unite alla ricerca dell'ottimizzazione per ambienti specifici degli strumenti da 

utilizzare, hanno portato ad uno sviluppo incrementale, livello su livello, fino a 

giungere alle attuali diversità. Ambienti specifici hanno, per tradizione, adottato, e 

continuato ad utilizzare e sviluppare, ambienti oramai consolidati, e l'impostazione 

generale sarebbe continuata ad essere questa, se non fossero emerse, a livello 

planetario, esigenze di unificazione tra scomparti che erano considerati impermeabili 

tra loro. 

Punto di svolta può considerarsi l'enorme diffusione della rete Internet tra gli utenti di 

sistemi informatici, e soprattutto i suoi risvolti commerciali sulla popolazione in 

generale. Le varie realtà hanno cominciato a comunicare tra loro, e sono emersi tutti 

i problemi correlati a tali diversità: applicativi sviluppati per un ambiente devono 

essere modificati tante volte quanti sono gli ambienti diversi sui quali devono essere 

utilizzati, così i lati client di molte applicazioni client-server erano sempre diversi e 

non sempre il risultato era paragonabile a quello ottenuto su altre piattaforme.


Non potendo costringere realtà diverse ad uniformarsi ad un unico ambiente, il 

processo d'integrazione si è orientato allo sviluppo di applicativi di interfaccia, che 

forniscano un livello comune sopra il quale ogni risorsa, anche se diversa per 

tecnologia, possa essere vista nello stesso modo: il primo passo è stato il linguaggio 

Java (con la sua JVM), ma realtà più complesse hanno necessità di strumenti più 

potenti [Bibl. 7]. 

2.1.1 Cos'è un Middleware 

Un middleware è un nuovo concetto di applicativo che si pone a metà strada, come il 

nome stesso dichiara, tra le diversità di un mondo formato da utenti eterogenei, e le 

esigenze d'integrazione degli sviluppatori di programmi a larghissima diffusione: è 

sostanzialmente un "semilavorato informatico" da utilizzare per la creazione di 

prodotti finiti fruibili dagli utenti [Diagramma 1]. 

Diagramma 1 : Scenario d'uso del middleware 

Si può dividere il lavoro necessario per la creazione di un applicativo in due momenti 

logici separati: la realizzazione delle funzionalità specifiche che caratterizzano il 

programma, e la creazione dell'infrastruttura che ne sorregge l'insieme. In


quest'ultima fase sono comprese le esigenze d'integrazione, le funzioni di basso 

livello per gestire le comunicazioni in rete, lo sviluppo di servizi d'utilità ed 

amministrazione delle risorse, etc.: tutte cose che vanno al di là dello sviluppo delle 

funzioni di un prodotto software, ma che sono necessarie (e soprattutto potrebbero 

essere riutilizzabili). 

Un middleware si occupa di incapsulare questo livello sollevando il programmatore 

da compiti "tediosi e difficoltosi", permettendogli, invece, di concentrarsi sulle 

funzionalità ad alto livello. 

2.1.2 Il Middleware come prodotto informatico 

In realtà non esiste un unico middleware adatto alle esigenze di tutti, ma i numerosi 

prodotti sul mercato si differenziano per le scelte implementative effettuate, la 

flessibilità offerta al programmatore nel regolare i parametri di funzionamento, 

caratteristiche di sicurezza e robustezza, etc. Tutti hanno, però, in comune l'esigenza 

di una standardizzazione dell'interfaccia di comunicazione, senza la quale verrebbe 

meno lo scopo dell'utilizzo di tali strumenti: si è quindi assistito alla nascita di vari 

standard di fatto o promossi da appositi consorzi. 

I middleware che dichiarano di conformarsi ad una data specifica (operando una 

scelta tra le possibili) condividono la stessa interfaccia, e possono comunicare tra 

loro anche se sviluppati da software house differenti. 

Lo sviluppatore che intende usufruire di un middleware, si trova in ogni caso di fronte 

ad una scelta, da prendere in base agli standard adottati ed alle caratteristiche 

specifiche dell'implementazione. 

2.1.3 Problematiche connesse alla concorrenza 

Un middleware si occupa principalmente di sollevare il programmatore da aspetti 

troppo tecnici per gli scopi che si è prefisso. Questo non significa che tali aspetti 

siano trascurati, anzi vengono incapsulati nel middleware e, operando determinate 

scelte, presentate in una forma semplificata, che riduca errori di programmazione e 

di scorretto utilizzo. Le opzioni lasciate al programmatore, pensate dallo sviluppatore

Architetture Concorrenti in prodotti a larga diffusione - DCOM 11 

di middleware, caratterizzano ulteriormente il "pacchetto d'utilità" e possono orientare 

i fruitori a preferire un middleware ad un altro. Molta cura è messa nella flessibilità ed 

efficienza offerta dal sistema, senza trascurare semplicità d'uso e robustezza agli 

errori (caratteristiche che richiedono spesso un trade-off). 

La concorrenza fa parte di quelle caratteristiche che possono incrementare molto 

l'efficienza di un sistema, ma, nello stesso tempo, può causare seri problemi se 

amministrata scorrettamente [par. 1.2.2 Problemi insiti nella concorrenza]. 

Un middleware può scegliere di consentire che l'utente scelga liberamente il grado di 

concorrenza desiderato, o negargli ogni accesso a tale aspetto, ma l'importante è 

che, qualunque sia la scelta, il sistema sia in grado di consentire una buona 

prevenzione degli errori (così frequenti in interazioni tanto delicate) ed un facile 

controllo sui parametri a disposizione. 

2.2 DCOM 

Distributed COM è un'estensione del Component Object Model (COM) per 

supportare le comunicazioni tra oggetti distribuiti su macchine differenti, collegate 

tramite reti locali (LAN) od anche Internet. Entrambi i prodotti sono stati sviluppati 

dalla Microsoft Corporation e forniscono non solo un insieme di specifiche ma 

anche implementazioni e conseguenti prodotti informatici pronti all'uso. DCOM, come 

di consueto, si occupa di tutti i dettagli di basso livello riguardanti le comunicazioni in 

rete, la gestione delle risorse, etc., lasciando che il programmatore si concentri sulle 

funzionalità aggiuntive. 

2.2.1 Introduzione 

COM è uno standard mirato all'uso di componenti: stabilisce i contratti base per 

garantire una corretta comunicazione tra moduli software e relativi client. Lo scopo di 

tale standardizzazione è quello di creare un'interfaccia comune tra moduli, che 

possono essere forniti da diversi produttori anche in tempi diversi, e garantirne riuso, 

collaborazione e composizione reciproca secondo le esigenze dei consumatori.


La standardizzazione avviene a basso livello (si parla di compatibilità della struttura 

binaria), lasciando totale libertà di scelta sul linguaggio di sviluppo (C++, Java, Visual 

Basic,… ): tale caratteristica è nota come "neutralità rispetto al linguaggio". 

Ulteriore flessibilità è data dal supporto al "versioning" che consente un'ampia 

scalabilità nell'evenienza di "modifiche migliorative" dei prodotti-componenti. Nel 

caso in cui sia necessario apportare modifiche o nuove funzionalità ad un 

componente già sviluppato, l'approccio tradizionale consisterebbe in modifiche sia 

sul lato server-componente, sia su quello client (per ogni utilizzatore della risorsa) 

con molto lavoro da parte degli amministratori di sistema. COM consente ai moduli di 

presentarsi con interfacce differenti a seconda dei diversi client: vecchi utenti 

possono adoperare i soliti metodi su nuove implementazioni (sfruttabili pienamente 

dopo gli eventuali aggiornamenti dei client), viceversa, nuovi utilizzatori possono 

ancora adoperare versioni obsolete di un servizio [Diagramma 2]. 

Diagramma 2 : Versioning 

Altri importanti supporti alla scalabilità sono forniti dalle caratteristiche di: 

?? Location Independence: le chiamate ad un componente sono fatte, dal client, allo 

stesso modo indipendentemente dal fatto che il servizio risieda nello stesso 

"processo", o su di una macchina accessibile tramite web. Il codice non ha


nemmeno bisogno di essere ricompilato, ma basta modificare alcuni parametri di 

macchina [Diagramma 3]. 

Diagramma 3 : Location independence


?? Flexible Deployment: quando l'aumento di utilizzatori richiede una revisione delle 

politiche di distribuzione ed incremento dei servizi a disposizione dei client, alcuni 

componenti possono essere duplicati o spostati su altre macchine, ed il 

reindirizzamento delle connessioni tra client-component e component-component 

può essere effettuato con una semplice modifica dei registri delle locazioni 

[Diagramma 4]. 

Diagramma 4 : Flexible deployment


?? Dynamic Load Balancing: la presenza di strumenti dedicati al reindirizzamento 

trasparente delle richieste verso opportuni server (tramite i cosiddetti "referral 

component"), consente facilmente di bilanciare l'utilizzo delle risorse sul tale lato a 

seconda di parametri di carico e statistiche d'uso [Diagramma 5]. 

Diagramma 5 : Referral component


2.2.2 Panoramica sull'architettura 

2.2.2.1 Connection Management 

COM consente ad un client di connettersi ad un server-component sulla stessa 

macchina direttamente senza bisogno di passare attraverso componenti intermedi ed 

interfacce proprietarie. L'estensione DCOM, dovendo provvedere al collegamento tra 

oggetti remoti, utilizza le stesse specifiche di COM, ma ne esegue l'instradamento 

verso l'oggetto desiderato in maniera trasparente all'utente, che opera lo stesso tipo 

di chiamate che utilizzava nel caso non distribuito [Diagramma 6]. 

Diagramma 6 : Connessione tra componenti distribuiti in DCOM 

DCOM non specifica un protocollo particolare per amministrare le comunicazioni via 

rete, cosa che richiederebbe un potenziale aggiornamento sul lato client verso la 

tecnologia prescelta, ma lascia libero ogni utente di mantenere il protocollo che ha a 

disposizione implementando una politica di "Protocol Neutrality": DCOM costruisce 

un ulteriore livello sopra questi protocolli (TCP/IP, UDP,… ) ed amministra il tutto in 

maniera trasparente, aggiungendo, però, specifici controlli di sicurezza ed affidabilità 

della connessione.


Particolarmente interessanti, a questo riguardo, sono i meccanismi di pinging, 

mantenimento del numero di riferimenti, e la garbage collection distribuita: quando un 

client richiede una connessione ad un server, il componente interessato, che può 

avere diverse comunicazioni già in corso con vari utilizzatori, incrementa un 

contatore che tiene traccia del numero di connessioni in corso; durante l'interazione 

client-component, un servizio di pinging controlla se il chiamante è ancora attivo sulla 

connessione e, in caso contrario (per problemi di rete o crash sul lato client), può 

decrementare il "reference count"; quando un componente rileva, dal contatore, di 

non essere più referenziato da alcuno, può provvedere da solo alla liberazione delle 

risorse che occupava. 

2.2.2.2 Platform Neutrality 

DCOM è uno standard inter-piattaforma: consente ai componenti di non essere 

vincolati a macchine specifiche, ma di poter interagire con oggetti DCOM residenti in 

ambienti operativi eterogenei. 

L'approccio di DCOM alla "Platform Neutrality" è però molto differente da soluzioni 

adottate in altri sistemi platform-independent come Java. 

Una Java Virtual Machine (JVM) è un'astrazione di calcolatore, che fornisce 

un'interfaccia comune, indipendente dalla macchina reale sottostante, e che 

consente a tutti gli applicativi Java di essere eseguiti nel medesimo tipo d'ambiente. I 

sorgenti Java sono quindi semi-compilati in un "bytecode" specifico delle JVM, che 

provvedono ad eseguire, in modalità interpretata, le loro istruzioni. Sebbene questo 

sistema consenta ad ogni bytecode, di essere riconosciuto da ogni JVM in 

esecuzione su qualsiasi tipo di macchina, le prestazioni di un linguaggio interpretato 

sono inferiori a quelle ottenibili da un codice compilato specificatamente per un dato 

sistema. 

DCOM, invece, offre uno standard binario per-platform: ogni utente può acquistare 

componenti specifici per il proprio ambiente, che vengono quindi ottimizzati, ma che 

possono comunicare con componenti di altre piattaforme in maniera standardizzata. 

In aggiunta, viene assicurata l'interoperabilità con altri standard platform-neutral 

(quali Java) [Bibl. 8].


2.2.2.3 Remote Method Call: marshaling ed unmarshaling 

Quando un client vuole chiamare un oggetto che risiede in un differente 

address space, il passaggio dei parametri d'invocazione, e l'eventuale restituzione 

dei risultati della computazione, avvengono tramite lo stack. Quando la chiamata 

intercorre tra entità che non condividono il medesimo stack, la parte di codice che 

amministra la Remote Procedure Call (RPC) deve occuparsi di leggere i parametri 

dallo stack e scriverli in un buffer di memoria, in modo che siano trasmissibili 

attraverso una connessione di rete: tale processo e detto "marshaling", mentre 

l'operazione inversa, che deve avvenire sul lato server, è chiamata "unmarshaling"; 

dopo che lo stack è stato ricostruito, allora l'oggetto può essere invocato. 

La procedura non è per niente banale. I parametri della chiamata possono contenere 

dati complessi come strutture, puntatori ed alberi di puntatori: il codice deve navigare 

tutti i nodi e risolvere gli annidamenti. 

I dati così recuperati devono avere, per poter essere trasmessi e poi ricreati 

correttamente, una rappresentazione ben definita e standardizzata. DCOM si basa 

sullo standard DCE RPC (Distributed Computing Environment RPC), che utilizza 

NDR (Network Data Representation) per rappresentare i tipi di dati più diffusi.


Per poter effettuare una chiamata ad un oggetto, è necessario conoscere l'insieme 

dei suoi metodi, completo di parametri d'ingresso ed uscita. La descrizione 

dell'interfaccia di un oggetto è fornita usando un apposito IDL (Interface Definition 

Language): un compilatore apposito, il Microsoft IDL (MIDL) compiler, fornisce, 

partendo dagli IDL, il codice C sorgente che contiene i metodi di 

marshaling/unmarshaling separatamente per il client e per il server (tale codice è 

detto "proxy" e "stub" rispettivamente) [Diagramma 7].[Bibl. 9] 

Diagramma 7 : Comunicazione tra oggetti DCOM 

2.2.3 Modelli di concorrenza 

Non si può affermare che DCOM abbia un'architettura di threading, in quanto utilizza 

i meccanismi forniti dal sistema sottostante, ma adotta modelli per indicare come 

dovrebbero essere gestite le situazioni di concorrenza tra componenti.


A seconda del modello prescelto, DCOM garantisce un crescente livello di protezione 

od una maggiore flessibilità nell'adattarsi agli scenari desiderati dal programmatore. 

Per offrire la dovuta sincronizzazione tra chiamate che avvengono tra oggetti in 

esecuzione su differenti thread della stessa macchina, il sistema adopera lo stesso 

metodo utilizzato per le RPC: il marshaling [Diagramma 8]. 

Diagramma 8 : Invocazioni tra oggetti di thread differenti 

2.2.3.1 Single-Threaded Apartment 

In questo modello (STA) ogni oggetto vive in un solo thread (esiste anche un'ulteriore 

specializzazione del modello (STA Main thread only) nel quale TUTTE le istanze 

sono create nello stesso thread). 

Valgono le seguenti regole: 

?? Dato un oggetto in un STA, se gli oggetti residenti in altri Apartment vogliono 

comunicare con esso, i due thread vengono sincronizzati tramite marshaling. 

?? Gli oggetti residenti nello stesso Apartment non sono sincronizzati tra loro.


?? Se due oggetti risiedono nello stesso Apartment, ed uno di essi sta processando 

una chiamata, nessun'altra invocazione può essere accettata dall'Apartment, 

anche se diretta al secondo componente [Diagramma 9]. 

Diagramma 9 : Concorrenza tra invocazioni di oggetti in Apartment differenti 

2.2.3.2 MultiThreaded Apartment 

Un MTA è un modello libero di concorrenza: un oggetto non risiede in nessun thread 

specifico, ed ogni oggetto all'interno dell'Apartment (unico per ogni singolo processo) 

può essere invocato direttamente (senza bisogno di marshaling) da qualsiasi altro 

componente, anche se residente in altri thread. 

Naturalmente questo elimina gli overhead, ma demanda completamente al 

programmatore il controllo delle necessarie sincronizzazioni (tramite eventi, semafori 

o quant'altro). 

La maggiore libertà nella sincronizzazione consente, però, di poter adattare al meglio 

la gestione delle "sezioni critiche", così da ottenere un "fine tuning" dell'applicazione 

(utilizzando costrutti quali i lock manuali).

Architetture Concorrenti in prodotti a larga diffusione - CORBA 22 

2.2.3.3 Free-Threaded Marshaler 

Ogni invocazione tra componenti residenti in differenti Apartment richiede un 

processo di marshaling, e questo è molto più dispendioso di una chiamata diretta. 

DCOM mette, però, a disposizione del programmatore gli strumenti per 

personalizzare ogni processo di marshaling: sfruttando questa possibilità, lo 

sviluppatore ha la facoltà di agire anche sul "marshaling inter-thread", e quindi, di 

aggirare le operazioni di esternalizzazione e passare direttamente un riferimento al 

client invocante [Bibl. 9]. 

2.3 CORBA 

CORBA, acronimo per Common Object Request Broker Architecture, è un insieme di 

specifiche prodotto dalla OMG (Object Management Group) ed in collaborazione con 

la X/Open. Queste organizzazioni hanno lo scopo di standardizzare ed indirizzare, a 

livello globale, le nuove tecniche di programmazione orientata agli oggetti (OOP), in 

maniera indipendente da prodotti di specifici fornitori e di darne un'implementazione 

"aperta"; le specifiche in questione riguardano la standardizzazione di un ORB. 


Un ORB è un oggetto software il cui scopo è rendere possibile le comunicazioni ed il 

mutuo utilizzo tra applicazioni informatiche che si trovano distribuite su una rete 

eterogenea di macchine (diversi fornitori dell'applicativo, differenti sistemi operativi, 

linguaggi di programmazione e persino tecnologie di rete). 

Data l'integrazione che un tale sistema promette di fornire, i vantaggi di questa 

tecnologia risultano maggiormente evidenti in realtà complesse che devono dialogare 

con molti utenti differenti: un ORB è il middleware di riferimento di molti server che 

operano in Internet usando il modello client-server. 

Il livello d'integrazione platform-independent viene ottenuto tramite due meccanismi 

chiave:


1. La scelta di un linguaggio unico per specificare le interfacce degli oggetti coinvolti 

nell'interazione in rete: in modo che sia il client, sia il server sappiano, 

univocamente e senza ambiguità di sorta, quali richieste possono essere invocate 

sull'oggetto. 

2. La scelta di un protocollo comune per effettuare le comunicazioni vere e proprie 

attraverso una generica rete. 

CORBA si fonda su IDL (Interface Definition Language) anch'esso definito da OMG 

per disciplinare la descrizione delle interfacce (con i loro metodi, parametri, tipi di dati 

di ritorno, etc.), e propone IIOP (Internet Inter-ORB Protocol) come protocollo di 

comunicazione. 

Si deve ricordare che CORBA è unicamente un insieme di specifiche su come deve 

operare e quali funzioni deve fornire un ORB che voglia dirsi "CORBA compliant": 

non si dice come tali funzionalità debbano essere implementate, ma unicamente 

come debbano comportarsi. Nulla di implementativo è stato sviluppato da OMG, ma 

diversi produttori di software hanno scelto di fornire applicativi conformi a tale 

standard; limitandosi, però, CORBA alle specifiche d'interfaccia, ogni ORB sviluppato 

partendo da queste è libero di effettuare le scelte implementative volute, ed è quindi 

unico per prestazioni, flessibilità, robustezza, scalabilità, etc [Bibl. 12]. 


Un programmatore che volesse adoperare CORBA deve definire l'interfaccia di ogni 

oggetto facente parte dell'interazione sulla rete usando IDL in modo che non vi siano 

ambiguità sulle sue possibilità. La separazione tra definizione ed implementazione 

dell'oggetto è il punto di forza di CORBA, poiché lascia liberi di adoperare, in fase di 

scrittura dei metodi, qualsiasi linguaggio prescelto dal programmatore: uno specifico 

compilatore IDL si occupa, infatti, in una fase successiva, di mappare la definizione 

in due oggetti language-specific separati. Gli oggetti sono detti "stub" e "skeleton". Gli 

stub servono da proxy per le chiamate da parte di client, mentre gli skeleton 

implementano i proxy del lato server. Il progettista, una volta ottenuto lo skeleton 

della classe, contenente tutte le definizioni dei metodi precisate in fase di scrittura 

IDL, non deve fare altro che estenderlo implementando le chiamate ai metodi: stub e


skeleton, che possono essere anche molto voluminosi, incapsulano tutte le 

procedure di necessarie per le chiamate remote e la conversione delle richieste in 

dati trasmissibili. 

Il client, che pensa di chiamare un metodo di un dato oggetto, in realtà chiama il 

corrispondente metodo dello stub. Questo passa la comunicazione al lato server 

(attraverso l'ORB), ed infine la richiesta subisce un dispatch verso lo skeleton e la 

sua concretizzazione [Diagramma 10] [Bibl. 11] 

Diagramma 10 : Meccanismo d'invocazione dei metodi in CORBA 

2.3.3 Specifiche per la concorrenza 

CORBA, come già accennato, non entra nell'ambito delle specifiche implementative 

dell'ORB e quindi, per quanto riguarda le caratteristiche legate a meccanismi 

d'esecuzione, come sono quelle relative alla concorrenza, resta spesso volutamente 

nel vago. 

Per quanto concerne il lato server dell'applicazione, vengono comunque delineati dei 

blocchi e servizi di massima che devono essere forniti, e si è pensato un


meccanismo per interfacciare l'effettiva esecuzione delle richieste e specificare alcuni 

parametri fondamentali di tale comportamento. 

L'oggetto principale demandato all'attuazione delle esecuzioni in CORBA è il 

"servant": un servant, visibile solo dal lato server, è l'insieme di CPU, memoria e 

risorse necessarie per l'esecuzione di un'operazione invocata. Un oggetto CORBA 

può, infatti, essere creato e distrutto e queste operazioni delimitano il suo "lifetime" 

come visibile sia dal lato client sia da quello server: unicamente durante il lifetime di 

un oggetto un client può invocare su di esso delle operazioni, ma, per quanto 

concerne la visione del lato server, un oggetto può assumere altri stati specifici 

mentre risulta "presente". Per gestire meglio le risorse del server, infatti, sarebbe 

sconveniente che tutte le implementazioni degli oggetti necessari occupassero CPU 

e memoria contemporaneamente, ma sarebbe auspicabile una loro assegnazione 

solo quando realmente necessaria: per questo un oggetto, sul lato server, possiede 

anche le caratteristiche di essere "attivo" o "sospeso". Il modulo che si occupa di 

queste variazioni nello stato delle implementazioni è detto POA (Portable Object 

Adapter) [Bibl. 10].


Un POA si occupa del risveglio-sospensione di un oggetto e della gestione delle 

assegnazioni dei servant ad essi a tempo d'esecuzione: è l'amministratore delle 

politiche di scalabilità di un ORB; quando un client invoca una chiamata ad un 

oggetto server, questa viene filtrata dal POA che provvede, attenendosi alle politiche 

assegnate, alla sua effettiva esecuzione [Diagramma 11]. 

Diagramma 11 : Funzionamento del POA 

Il POA è completamente dipendente dall'implementazione, ma CORBA ha 

specificato alcune caratteristiche che deve possedere ed i modi per assegnargliele: 

l'oggetto Policy è dedicato a questo scopo e ne esistono differenti specializzazioni 

(sette per la precisione), tra cui anche quelle relative ai modelli di threading quando 

un ORB è implementato in maniera multi-threaded (e relative politiche di 

concorrenza). 

CORBA prevede tre differenti "threading model" incapsulati nell'oggetto 

ThreadPolicy:


1. Single Thread: ogni chiamata eseguita dal singolo POA ai servant deve essere 

processata sequenzialmente. Un POA può avere chiamate rientranti, ma 

l'esecuzione delle stesse non deve avvenire in maniera concorrente. 

2. ORB Controlled: la gestione dei thread è demandata totalmente 

all'implementazione dell'ORB. 

3. Main Thread: tutte le richieste demandate a POA che adottano questa politica 

sono eseguite sequenzialmente. 

La prima e l'ultima di queste politiche sono espressamente pensate per 

salvaguardare l'esecuzione di codice "multi-thread-unaware". 

Le specifiche di CORBA per la concorrenza sono interamente contenute in quello 

che si è presentato: per avere quadro più approfondito è necessario esaminare le 

scelte implementative dei singoli applicativi "CORBA compliant" [Bibl. 13]. 

2.3.4 Un esempio d'implementazione: ORBacus 

ORBacus è un ORB, commercializzato dalla IONA Technologies, compatibile con le 

specifiche CORBA in generale e che si rifà ad un modello implementativo sviluppato 

in C++ ed in Java (risulta quindi compatibile con i documenti "C++ Language 

mapping" e "IDL/Java Language mapping" di OMG). 

Essendo un'implementazione, fornisce maggiori specifiche per quanto riguarda il 

modello di concorrenza ed offre allo sviluppatore software diverse opportunità per 

rispondere meglio alle esigenze specifiche delle applicazioni che s'intendono creare. 

ORBacus divide i modelli che l'utente può adoperare, per definire come l'ORB 

gestisce le comunicazioni e le richieste d'esecuzione, in due categorie principali, 

Single-threaded e Multi-threaded, e lascia l'ulteriore grado di libertà di separarle per 

le implementazioni client e per quelle sul lato server. I modelli sono Blocking, 

Reactive e Threaded per il lato client e Reactive, Threaded, Thread-per-Client, 

Thread-per-Request e Thread Pool per quello server; i paradigmi Blocking e 

Reactive rientrano nella categoria dei Single-threaded, mentre i restanti in quella 

Multi-threaded. 

La politica Blocking è la più semplice: implica che l'ORB si blocca mentre il client 

manda una richiesta (nel frattempo non è possibile eseguire altre operazioni).


Il modello Reactive permette, a client e server, di mandare/ricevere richieste mentre 

stanno aspettando il ritorno di (o eseguendo nel caso del server) altre chiamate. 

I modelli Multi-threaded sono più interessanti per gli ambiti di questa trattazione e 

verranno esaminati più approfonditamente. 

2.3.4.1 Modello Threaded 

In questo modello ogni client (server) utilizza due thread separati per ogni 

connessione con un diverso server (client): un thread è utilizzato per l'invio (di 

richieste) e l'altro per la ricezione. Il server, inoltre, possiede un terzo thread per 

l'accettazione delle richieste di connessione. 

Il server, anche se può ricevere più richieste simultaneamente, è però limitato a 

doverle eseguire in modo serializzato (e quindi a bufferizzare e ritardare quelle che 

giungono durante l'esecuzione di precedenti chiamate): il modello consente un solo 

thread attivo per tutto il codice utente (server o client) [Diagramma 12]. Questa 

accortezza permette al codice di non doversi preoccupare di meccanismi di 

sincronizzazione delle invocazioni ai metodi. 

Diagramma 12 : Threaded server


2.3.4.2 Modello Thread-per-Client 

Del tutto simile al modello precedente, si differenzia per il fatto che ora è consentito 

un thread attivo alla volta per ogni distinto client: operazioni richieste da client diversi 

possono essere eseguite parallelamente (raffinando quindi la grana della 

concorrenza) [Diagramma 13]. Ancora una volta, però, se più chiamate arrivano quasi 

simultaneamente dallo stesso client (o comunque mentre una precedente operazione 

richiesta dallo stesso client deve ancora essere portata a termine), l'esecuzione della 

seconda invocazione viene differita. 

Diagramma 13 : Thread-per-Client server


2.3.4.3 Modello Thread-per-Request 

L'ORB che utilizza tale modello crea un thread d'esecuzione per ogni richiesta che gli 

perviene consentendo che nessuna richiesta venga ritardata. Il modello è 

particolarmente efficace in quei sistemi in cui il tempo d'esecuzione risulta critico e 

diviene prioritario servire ogni richiesta immediatamente, ma risulta particolarmente 

inefficiente per lo spreco di risorse e l'overhead insito nelle operazioni di creazione 

dei nuovi thread [Diagramma 14]. 

Diagramma 14 : Thread-per-Request server

Architetture Concorrenti in prodotti a larga diffusione - EJB 31 

2.3.4.4 Modello Thread Pool 

Un compromesso tra ritardi nella risposta alle chiamate ed efficienza nell'utilizzo delle 

risorse, può essere ottenuto servendosi di una collezione di thread creati una volta 

per tutte in fase di inizializzazione e riutilizzati ogni volta che ve ne sia bisogno. Non 

vi è così perdita di tempo per le operazioni di creazione dei thread e, inoltre, le 

richieste dovranno essere ritardate solo nell'evenienza che tutto il pool sia 

completamente occupato nell'istante del loro inoltro [Diagramma 15] [Bibl. 14]. 

Diagramma 15 : Thread Pool server 

2.4 EJB 

Enterprise JavaBeans è una specifica API (Application Programming Interface), 

prodotta da Sun Microsystems, che estende il modello a componenti di JavaBeans 

mettendo a disposizione degli sviluppatori d'applicativi per le imprese, un ambiente 

Object-Oriented transazionale.



2.4.1.1 JavaBeans 

JavaBeans è un'estensione di Java nata con lo scopo di creare un modello di 

componenti, finalizzato all'utilizzo in ambienti per lo sviluppo d'applicazioni (IDEs) di 

tipo "visuale". I Bean sono stati pensati per essere riusabili. 

Supportano caratteristiche quali: 

1. Introspezione: capacità, da parte dell'IDE, di analizzare come il componente 

opera. 

2. Customizzazione: possibilità, ad opera dello sviluppatore, di adattare facilmente il 

componente alle proprie esigenze. 

3. Gestione degli eventi: consente ad un Bean di interagire con gli altri componenti 

in maniera reattiva entrando a far parte della rete di connessioni. 

I componenti, essendo scritti utilizzando Java, sono portabili su diverse piattaforme e 

vengono incontro all'esigenza, sempre più sentita dalle case produttrici di software, di 

fornire ai clienti moduli componibili secondo le specifiche esigenze, piuttosto che 

applicazioni monolitiche [Bibl. 15]. 

2.4.1.2 Ambienti transazionali 

Col termine di "transazione" s'intende l'insieme di una o più operazioni che 

costituiscono un'unità d'azione logicamente inscindibile. Essendo indivisibile, 

l'insieme delle operazioni che la compongono deve essere eseguito nella sua 

interezza per poter affermare che l'operazione è andata a buon fine, altrimenti tutta la 

transazione fallisce e diventa necessario ripristinare lo stato precedente le modifiche 

già avvenute: una transazione può cominciare, eseguire alcuni passi del processo, 

ma, nel caso dovessero intervenire condizioni per le quali fosse impossibile 

proseguire nello svolgimento, potrebbe poi fallire e dover, letteralmente, "tornare sui 

suoi passi". Tale processo di recupero è detto di "rollback". 

Nella vita di tutti i giorni si è spesso in presenza di operazioni transazionali: la spesa 

in un negozio (si deve scegliere il prodotto, pagarlo e portarlo con se fuori della 

bottega), un prelievo di contante ad uno sportello bancario automatico, etc.


Certamente non si desidera che, dopo aver pagato un bene, il commerciante 

consideri conclusa l'operazione, o almeno, se non vuole darci ciò che abbiamo 

pagato, dovremmo avere indietro il denaro. 

Negli ambienti informatici, specialmente quelli legati ad ambiti commerciali in cui 

siano presenti numerosi contatti con diversi clienti contemporaneamente (quali 

banche o esercizi commerciali on-line, agenzie per la prenotazione di posti in treno o 

aereo, etc.), il problema delle transazioni è quindi centrale e richiede particolare 

attenzione. 

Non sempre, però, il programmatore vuole avere a che fare con tale livello funzionale 

e spesso sarebbe preferibile una concentrazione di risorse sui contenuti piuttosto che 

sugli strumenti: è in questo scenario che nasce l'esigenza di prodotti middleware 

quali sono quelli compatibili con le specifiche di EJB. 


Diagramma 16 : Scenario dell'architettura di EJB


EJB si basa sulla descrizione di alcuni componenti e delle interfacce che ne regolano 

il comportamento. Due sono gli attori principali dello scenario: 

1. Gli entity Bean 

2. I session Bean 

Un entity Bean non è altro che un oggetto (nel senso informatico del termine) dotato 

di alcune proprietà caratterizzanti: 

1. È permanente: mentre un comune oggetto cessa di esistere quando il programma 

che lo ha creato termina l'esecuzione, un entity Bean continua ad esistere fino a 

che non viene cancellato (o il database su cui è memorizzato il suo stato subisce 

danni irreversibili). Uno stesso oggetto può continuare le sue attività tra diverse 

sessioni d'attivazione del programma (è a prova di crash del Container che lo 

amministra). 

2. È basato sulla rete: l'entity Bean è stato pensato per l'utilizzo condiviso in rete. 

Esistono, quindi, utilità per la ricerca ed il recupero di Bean per il loro successivo 

utilizzo. 

3. È eseguito in remoto: i metodi di un entity Bean sono fisicamente eseguiti su un 

server EJB (e possono essere invocati da client remoti). 

4. È identificato da una "primary key": a ciascun oggetto è associato un identificatore 

unico per ogni istanza. 

I session Bean sono, invece, entità utilizzate per eseguire un compito specifico per 

conto d un singolo client: non sono permanenti, ma vengono creati all'occorrenza per 

isolare i sotto-compiti specifici di un'operazione. 

Esistono le specifiche anche per le interfacce associate ad un Bean. 

Queste sono: 

1. La "Home Interface": usata dai client per creare o trovare istanze di un EJB. 

2. La "Remote Interface": rappresenta le operazioni messe a disposizione dal Bean 

e necessita di un'implementazione sul lato server dell'applicazione. 

EJB specifica come le istanze dei Bean debbano essere accessibili e come il server 

debba gestirle. Il contesto di un Bean è il suo Container: entità facente parte del 

server che amministra l'esecuzione degli EJB [Diagramma 16] [Bibl. 17].

Architetture Concorrenti in prodotti a larga diffusione - Confronti 35 

2.4.3 Specifiche per la concorrenza 

EJB non entra nel merito dell'interfaccia Container-server (il cui confine non è 

neanche eccessivamente delimitato), ma si concentra particolarmente sulle 

specifiche per quella Container-Bean: per questo motivo l'amministrazione delle 

risorse è nascosta, ed operazioni come la gestione delle connessioni ai database, 

quella della memoria e dei thread sono demandati interamente al server (dipendente 

dal fornitore). Un server EJB provvede a tutta l'infrastruttura necessaria per 

l'esecuzione dei Container. 

In EJB non esistono, quindi, specifiche riguardanti le politiche di concorrenza da far 

adottare ad un server, ma alcune limitazioni concernenti vengono esplicitamente 

imposte alle implementazioni dei Bean per evitare l'insorgere di problemi di 

sicurezza, di quelli tipici del multi-threading e favorire il controllo da parte dei 

Container: 

1. Un Container deve assicurare che al più un thread possa eseguire una data 

istanza per volta: se, mentre un'implementazione è in esecuzione, giunge una 

seconda richiesta, da parte di un client, sulla stessa istanza, questa deve essere 

rifiutata e bisogna lanciare un'opportuna eccezione. 

2. Un Bean non deve adottare le primitive di sincronizzazione di Java; in particolare 

non deve mai contenere la parola chiave "synchronized". Alcuni Container 

potrebbero infatti utilizzare più di una JVM (Java Virtual Machine) per eseguire 

diverse istanze invalidando la sincronizzazione. 

3. Un Bean non deve mai cercare di amministrare thread: non può invocare primitive 

quali stop(), suspend() e resume(), né gestire priorità o gruppi di thread. Queste 

funzioni sono di competenza del Container che ne deve avere il controllo assoluto 

per l'appropriata gestione dell'ambiente [Bibl. 18] 

2.5 Confronti 

Tra i prodotti presentati, quelli più facilmente confrontabili sono DCOM e CORBA.


EJB, mentre i suddetti sono orientati principalmente alla collaborazione ed offrono 

pochi servizi supplementari, è un prodotto che si colloca ad un livello superiore. È 

stato pensato per soddisfare sì esigenze d'integrazione ed interoperabilità tra 

ambienti ed applicativi eterogenei, ma con finalità particolari (attenzione alle 

transazioni) e relativi servizi dedicati. 

Un'ulteriore precisazione andrebbe fatta per JADE [cap. 3 JADE] che è un 

framework: oltre alle specifiche implementative viene fornito all'utente un completo 

ambiente d'esecuzione per le applicazioni sviluppate (nel caso in questione, la 

piattaforma per gli Agenti). 

Superate queste differenze, tutte le tecnologie presentate hanno però in comune la 

necessità di amministrare, efficacemente ed in maniera sicura, le risorse di 

macchina, ed in particolare i thread: su questo piano comune possono essere quindi 

fatte diverse considerazioni [Bibl. 21]. 

2.5.1 DCOM e CORBA: creare l'infrastruttura per la comunicazione 

Sia DCOM che CORBA si prefiggono l'obiettivo di gestire, in maniera trasparente per 

l'utente, le chiamate a metodi di oggetti distribuiti, ma molte sono le differenze che 

separano i due standard. 

Innanzi tutto, mentre DCOM è nato come estensione di un meccanismo proprietario 

di Microsoft per la condivisione di oggetti intra-piattaforma (Object Linking and 

Embedding od OLE), e quindi possiede già tecnologie implementative consolidate, 

CORBA è semplicemente un insieme di specifiche e lascia liberi i produttori di 

middleware di implementarle come meglio credono. Questo fatto, come 

effettivamente accaduto nei tempi immediatamente successivi al rilascio di CORBA, 

può creare problemi di "interoperabilità" tra i prodotti di diversi fornitori, anche se 

d'altro canto, consente, essendo uno standard largamente supportato, una maggiore 

concorrenza ed offerta di prodotti. CORBA, inoltre, come tutte le specifiche di OMG, 

nasce da un processo "open" di creazione ed approvazione delle specifiche, che 

garantisce il contributo di diversi specialisti e quindi maggiore risposta ad esigenze 

diffuse e continuità nello sviluppo (DCOM, al contrario, ha subito nel tempo bruschi 

cambiamenti dettati da strategie di marketing di Microsoft).


Numerose differenze nascono, poi, dalla scelta del livello su cui garantire 

l'interoperabilità: CORBA opera su una compatibilità d'interfaccia, DCOM la richiede 

a livello di struttura del codice. Queste scelte comportano che: 

1. Il codice di oggetti DCOM, essendo ottimizzato per ogni piattaforma, dovrebbe 

essere più performante (fonte Microsoft), e certamente lo è rispetto ad altre 

implementazioni in Java, ma si ricorda che CORBA possiede un'ampia serie di 

specifiche per il mapping in vari linguaggi, ad esempio Java, ma anche C++, etc., 

e tale scelta condiziona le prestazioni ottenibili. 

2. CORBA è totalmente "platform-independent". Anche se DCOM dichiara lo stesso, 

il suo forte legame con le piattaforme, lo vincola a strumenti specifici per ogni 

macchina, il che può portare a differenze tra lo "stato dell'arte" su una piattaforma 

rispetto ad un'altra (nelle prime fasi del suo sviluppo, DCOM era fortemente 

supportato solo da ambienti Windows 9x ed NT). 

3. DCOM, essendo stato diffuso insieme alle piattaforme Windows, è largamente 

diffuso e non richiede l'acquisto di strumenti specifici. Il carico che un utente deve 

affrontare per utilizzare i componenti DCOM (essendo questi distribuiti in forma di 

codice specifico per-platform) è sicuramente minore di quello richiesto per 

CORBA, che necessita dell'acquisizione di un'implementazione di ORB. 

Da un punto di vista più tecnico si può notare, infine, come CORBA sia 

maggiormente orientato agli oggetti rispetto a DCOM, ed offra delle definizioni di 

interfacce più pulite e comprensibili: DCOM, pur essendo più recente di CORBA, 

nasce come estensione di tecnologie preesistenti (COM e DCE) e ne paga il prezzo 

(utilizzo di ID al posto di nomi per identificare gli oggetti, interventi su registri di 

sistema, etc.) [Bibl. 20] [Bibl. 21] [Bibl. 22]. 

2.5.2 Modelli di concorrenza: flessibilità, semplicità e sicurezza 

L'amministrazione delle risorse di sistema da parte di un middleware è sempre 

soggetta ad una serie di trade-off. I compromessi adottati nello sviluppo del software 

sono fortemente dipendenti dall'enfasi che si vuole porre su date caratteristiche, ed i 

risultati ottenibili sono spesso molto differenti: i casi presi in esame si prestano bene 

a questo tipo di confronto.


La gestione dei thread rappresenta una caratteristica molto potente, ma altrettanto 

pericolosa: un loro corretto management può migliorare notevolmente le prestazioni, 

e consentire una più equilibrata distribuzione dei compiti, ma la delicatezza legata ai 

meccanismi di sincronizzazione, se mal gestita, può causare comportamenti anomali 

e danni ad un intero sistema. 

Un dato molto importante, da prendere in considerazione quando si opera una scelta 

sul modello di concorrenza, è valutare quanto l'utilizzatore sia interessato ad 

occuparsi direttamente delle prestazioni del suo applicativo (e quindi dei thread), e 

quanto, invece, preferisca sia demandato a soluzioni "preconfezionate". Una 

maggiore ingerenza nelle questioni riguardanti i thread comporta, infatti, l'assunzione 

da parte del progettista di maggiori rischi e la distrazione da questioni più inerenti allo 

sviluppo delle funzionalità. 

L'approccio di DCOM, tecnologia che si sviluppa a più basso livello tra quelle 

esaminate, con i suoi Apartment, risulta particolarmente ricco di soluzioni e capace di 

adattarsi a diverse esigenze: il modello è uno dei più completi e consente grande 

flessibilità. Il prezzo da pagare è, naturalmente, la competenza necessaria per il suo 

utilizzo e la scarsa semplicità d'utilizzo; pagato questo scotto, un programmatore 

esperto del sistema, può ottimizzare i suoi prodotti rispetto alle prestazioni ed 

esercitare un controllo maggiore sulle cooperazioni tra oggetti. 

CORBA, essendo una specifica, si concentra poco sugli aspetti modellistici legati alla 

concorrenza, e si limita a fornire solo quei modelli che servono al programmatore per 

garantire che, nel caso di codice "multi-thread-unaware", non vi siano problemi di 

accesso a sezioni critiche o simili. 

ORBacus, d'altro canto, fornendo un'implementazione di CORBA, si sofferma 

maggiormente sul modello computazionale, e fornisce un set abbastanza ampio di 

modelli collaudati che uniscono controllo e semplicità d'utilizzo. I paradigmi sono 

indirizzati specificatamente alla ricezione e spedizione di messaggi (attività principali 

dei componenti di un ORB), e consentono una scelta consapevole tra prestazioni 

(misurate in tempi di attesa per la gestione dei messaggi), controllo delle risorse 

utilizzate (numero di thread assegnati), e gestione della sicurezza.


EJB, collocandosi a livello più alto, ha, giustamente, pensato che il programmatore 

fosse più interessato alla creazione di procedure transazionali, che non al controllo 

fisico della macchina, cosa che, essendo le transazioni "oggetti" complicati da 

gestire, avrebbe potuto portare a facili errori. Lo scopo principale di EJB è garantire 

che le delicate transazioni possano avvenire in totale sicurezza, ed il modo migliore 

per ottenere questo risultato è mantenere il più alto controllo possibile sulle 

computazioni interne e, quindi, impedire che i programmatori possano interferire con 

il modello scelto. Per questa ragione, più che un modello di concorrenza, EJB 

fornisce dei vincoli che l'utilizzatore di applicazioni EJB-compliant deve rispettare: 

astenersi assolutamente da manipolare caratteristiche legate all'amministrazione dei 

thread. 

Ne risulta che ogni prodotto, secondo l'utilizzo per il quale è stato progettato, ha 

adottato modelli differenti ponendo l'accento su caratteristiche diverse che questi 

dovevano presentare: DCOM ha puntato sulla flessibilità, CORBA (ed ORBacus) 

sulla semplicità, ed EJB sulla sicurezza. Ne segue che, una volta forniti gli strumenti 

per eseguire modelli concorrenti, molta importanza deve essere data alle interfacce 

tra questi e gli utilizzatori.

JADE - Architettura 40 

3 JADE 

Java Agent DEvelopment Framework è un middleware pensato per fornire un 

supporto allo sviluppo ed all'esecuzione di applicazioni basate sugli Agenti software. 

È nato dalla collaborazione tra TILab S.p.A. (precedentemente conosciuto come 

CSELT) e gli ambienti universitari, in particolare l'ateneo di Parma. Il prodotto è 

completamente codificato in Java e gli applicativi sviluppati usandolo, devono 

adoperare il medesimo linguaggio di programmazione. L'ambiente è compatibile con 

gli standard FIPA per gli agenti intelligenti, ed è composto da una piattaforma per 

Agenti FIPA-compliant ed un pacchetto Java per lo sviluppo degli Agenti [Bibl. 5]. 

3.1 Architettura 

Il software è suddiviso in diversi pacchetti a seconda delle funzionalità sviluppate. I 

più importanti di questi sono: 

?? jade.core: implementa il nucleo del sistema. Contiene la classe Agent, che 

rappresenta la classe-base per tutte le estensioni create dagli utenti, ed un 

sotto-pacchetto jade.core.behaviour, che fornisce gli strumenti per assegnare 

compiti agli Agenti. 

?? jade.domain: contiene tutte le entità di supporto agli Agenti che devono essere 

fornite dalla piattaforma secondo le specifiche FIPA, quali l'Agent Management 

System (AMS) ed il Directory Facilitator (DF). 

?? jade.proto: raccoglie i protocolli d'interazione standardizzati da FIPA. 

I rimanenti pacchetti forniscono i supporti per i linguaggi utilizzati nelle comunicazioni 

degli agenti (ACL, SL-0 ed i linguaggi definiti dall'utente), per il debugging e 

l'interfacciamento con gli utilizzatori, strumenti di utilità, etc.


3.1.1 La piattaforma FIPA-compliant 

Diagramma 17 : Architettura di una piattaforma FIPA 

La piattaforma per Agenti implementata in JADE è compatibile con le specifiche FIPA 

per la separazione e gestione dei servizi che deve fornire agli Agenti-utilizzatori. Una 

piattaforma FIPA deve essere composta dai seguenti servizi [Diagramma 17]: 

1. L'Agent Management System (AMS), agente che si occupa della supervisione e 

del controllo degli accessi alla piattaforma, dell'amministrazione dei life-cycle degli 

Agenti e della loro registrazione (tramite un servizio di "white-page"). 

2. Il Directory Facilitator (DF), anch'esso un agente, che si occupa della gestione 

delle "yellow-page": un servizio che consente agli Agenti di registrarsi, per 

rendere disponibile ad altri una descrizione dei compiti che possono svolgere e 

come rintracciarli. 

3. Il Message Transport System (detto anche Agent Communication Channel o 

ACC) che si occupa della supervisione di tutto il traffico di messaggi di una 

piattaforma (sia intra-platform, sia inter-platform). 

JADE offre inoltre la possibilità di distribuire la piattaforma su "host" differenti per 

scalarne le mansioni: in questo caso vengono creati differenti "Agent-Container" (uno


per macchina) gerarchicamente legati al "main-container" (unico per singola 

piattaforma) che è quello dove risiedono fisicamente i moduli-Agenti FIPA (AMS, etc.) 


Diagramma 18 : Distribuzione della piattaforma JADE su host differenti


3.1.2 L'amministrazione degli Agenti 

Anche alcuni aspetti caratteristici degli agenti si conformano al modello FIPA, in 

modo particolare la rappresentazione dello stato interno di un istanza e le transizioni 

tra questi. Il complesso di queste caratteristiche prende il nome di "life-cycle" 

dell'Agente. FIPA prevede diversi stati pensati per modellare le attività di un Agente: 

si parte da quelli "classici", come ACTIVE,SUSPENDED e WAITING, per giungere a 

stati particolari per amministrare la mobilità, quali TRANSIT,COPY e GONE 


Diagramma 19 : Ciclo di vita di un'Agente FIPA


3.1.3 Modello comportamentale 

Le attività di un Agente, attività che possono essere eseguite solo nello stato 

ACTIVE, sono state modellate seguendo il paradigma dei behaviour. La classe base, 

per l'appunto Behaviour, fornisce l'interfaccia per amministrare i compiti: contiene 

metodi specifici per le funzioni di sospensione/riattivazione di un'attività 

(block()/restart()), metodi per l'ispezione dello stato (done(), isRunnable()), e metodi 

astratti che l'utente deve implementare per creare il compito che si prefigge 

(onStart(), action() ed onEnd()). 

Il metodo action() rappresenta il vero nucleo del behaviour, ed è il codice che esegue 

il compito voluto. I metodi onStart() ed onEnd() servono nel caso sia necessario 

eseguire delle operazioni subito prima o dopo che la action() sia eseguita: 

prenotazione e rilascio di risorse, o terminazione appropriata di un'operazione.


Nel caso in cui si abbia a che fare con comportamenti complicati da modellare, la 

classe supporta meccanismi di composizione che consentono di creare behaviour 

complessi partendo da gruppi di altri più semplici. Il sistema, inoltre, fornisce alcuni 

modelli di composizione tra i più adoperati (con relative politiche d'esecuzione), già 

pronti per l'uso: si ha una classe che esegue i suoi sub-behaviour sequenzialmente, 

una per le esecuzioni concorrenti ed una che implementa un automa a stati finiti 

(FSM) [Diagramma 20]. 

Diagramma 20 : UML Class Diagram per la gerarchia dei Behaviour

JADE - Concorrenza: modello Thread-per-Agent 46 

Una volta che il programmatore ha esteso, implementandoli, i propri Behaviour, 

utilizzando se necessario anche le tecniche di composizione, le classi create 

possono essere istanziate ed aggiunte all'Agent tramite i metodi preposti alla loro 

gestione (addBehaviour()/removeBehaviour()). 

3.2 Concorrenza: modello Thread-per-Agent 

Ogni Agente JADE è composto da un unico thread d'esecuzione. Uno scheduler, 

implementato dall'Agent e nascosto al programmatore, esegue un algoritmo di 

selezione dei Behaviour di tipo round-robin, distribuendo il tempo di macchina alle 

diverse azioni. 

In realtà, il tempo di macchina non viene distribuito uniformemente sulle diverse 

istanze dei Behaviour, ma vengono concessi "quanti d'azione" ad ogni compito. Il 

modello d'esecuzione è infatti non-preemptive, e prevede che ad ogni Behaviour sia 

concesso di eseguire la propria action(), senza interruzioni da parte del sistema: 

quando la chiamata ad action() ritorna, lo scheduler può selezionare il Behaviour 

successivo e ricominciare il ciclo. 

La politica adottata pone delle limitazioni nella creazione dei compiti ai 

programmatori. Il corpo di una action() non deve contenere cicli infiniti o bloccarsi 

indefinitamente: essendo l'Agent single-threaded, un Behaviour non può essere 

eseguito finché la precedente action() (in esecuzione sul medesimo Agent) non ha 

terminato. È Inoltre consigliabile spezzare compiti lunghi in più brevi sotto-compiti da 

eseguire sequenzialmente (usando le composizioni): una action() troppo lunga 

sottrae tempo ad altri compiti, impedendo una distribuzione più equilibrata delle 

risorse di CPU. 

Il modello di concorrenza thread-per-Agent adottato da JADE limita, inoltre, il 

parallelismo possibile in tutte quelle situazioni (comuni per gli agenti) nelle quali un 

compito sia bloccato in attesa di eventi comunicativi: un Behaviour che attende su 

un'operazione di tipo read bloccante, sospende ogni altra attività dell'agente che 

potrebbe nel frattempo essere eseguita. La presenza di un ParallelBehaviour è poi 

del tutto illusoria: all'interno di questo è implementato lo stesso algoritmo round-robin

JADE - Concorrenza: modello Thread-per-Agent 47 

che esiste nello scheduler dell'Agent, ed i sub-behaviour sono anch'essi eseguiti 

sequenzialmente. 

Il superamento di questi limiti, passando a modelli multi-threaded, può portare, se 

ben amministrato, ad un aumento dell'efficienza degli Agenti, riducendo in modo 

sensibile i tempi d'attesa dovuti ai protocolli di comunicazione.

Modello di Concorrenza proposto - Granulosità della concorrenza 48 

4 Modello di Concorrenza proposto 

Per fare in modo che un Agent diventi realmente multi-threaded, occorre 

abbandonare l'attuale ciclo di scheduling ed esecuzione della relativa action() che sta 

alla base del main-loop dell'Agent quando questo è nel suo stato ACTIVE. 

Un tipico ciclo per amministrare il multi-threading dovrebbe comprendere i passi 

seguenti: 

1. Chiamare lo scheduler per ottenere un Behaviour 

2. Ottenere un thread per l'esecuzione 

3. Fare in modo che il Behaviour sia posto in esecuzione sul thread 

4. Occuparsi, solo al suo ritorno, delle operazioni di managing dello stato 

5. Eseguire i passi precedenti fino a che ci si trova nello stato ACTIVE 

Si vuole evidenziare come il passo 4 non comporti necessariamente l'attesa passiva 

del ritorno di un Behaviour dall'esecuzione: una volta effettuati i passi fino al 3, il ciclo 

può occuparsi di gestire subito altre richieste d'esecuzione. 

4.1 Granulosità della concorrenza 

Altra questione da considerare, una volta creata la disponibilità del multi-threading, è 

la scelta della granulosità che si vuole dare al modello concorrente. Il problema è 

simile a quello che si è presentato con l'attuale scelta Thread-per-Agent. Tale 

modello può considerarsi concorrente, ma solo a livello della comunità di agenti, 

nella quale ogni Agent è capace di effettuare un'operazione simultaneamente agli 

altri; quando si considerano i Behaviour affidati ad un singolo Agent, invece, la 

concorrenza svanisce. 

Richiamando quanto appena esposto, è possibile affidare un unico Thread-Pool ad 

ogni singolo agente o lasciare che un Agent amministri differenti pool, affidandoli, in 

modo esclusivo, a sottoinsiemi dei suoi Behaviour secondo politiche basate, ad 

esempio, sulla realizzazione di servizi differenti.

Modello di Concorrenza proposto - Strumenti adottati 49 

Mentre il primo modello potrebbe essere referenziato come Thread-Pool-per-Agent 

(in contrapposizione a quello Thread-per-Agent della versione attuale di JADE), si 

potrebbe parlare del secondo come del modello ibrido o Thread-Pool-Cluster. Questo 

modello ha il vantaggio, oltre quello di una più precisa distribuzione delle risorse, 

della possibilità di consentire una "transizione morbida" nel passaggio tra modello 

single-threaded e multi-threaded, dando modo all'Agent di creare, accanto al modello 

concorrente, una partizione con un solo thread per l'esecuzione dei Behaviour più 

vecchi. 

4.2 Strumenti adottati 

Fondamentale quando si deve implementare un modello è la scelta degli strumenti 

da adottare. In base alla bontà degli strumenti a disposizione, o a quelli che si è 

pensato di sviluppare, il modello può acquistare caratteristiche importanti quali 

flessibilità, robustezza e semplicità d'uso. 

4.2.1 Il dispatcher 

Per implementare il ciclo precedentemente descritto per il multi-threading, si devono 

innanzi tutto separare le azioni di scheduling dalla reale esecuzione dei Behaviour, 

per consentire che le chiamate ad action() possano avvenire su thread differenti. Per 

fare questo è necessario affidarsi ad un modulo che, ricevuto un Behaviour, si occupi 

di porlo in esecuzione in maniera asincrona (senza aspettarne il ritorno), così da 

poter processare più richieste mentre i Behaviour sono in esecuzione; tale 

componente dovrà, naturalmente, amministrare in modo asincrono anche il ritorno 

dalle sessioni d'esecuzione delle action(): questo modulo è quello che si chiama 

dispatcher. 

Il dispatcher deve poter attingere, per ottenere le risorse per l'esecuzione, ad una 

"fonte di thread", che può o no amministrare lui stesso: tale oggetto è spesso indicato 

come Thread-Pool e può avere a disposizione risorse illimitate o vincolate ad un 

determinato numero massimo.

Modello di Concorrenza proposto - Strumenti adottati 50 

Con la disponibilità di un dispatcher il ciclo principale di un agente diventa: se il 

dispatcher può ottenere un thread, passagli un Behaviour per l'esecuzione, altrimenti 

attendi che si liberino le risorse già utilizzate. 

4.2.2 Lo scheduling ricorsivo 

I modelli di differente granulosità della concorrenza sopra descritti possono essere 

ulteriormente estesi se combinati con il modello composizionale utilizzato da JADE 

per la creazione di Behaviour complessi. La classe CompositeBehaviour, infatti, può 

essere vista come un semplice contenitore di Behaviour, ed alcune sue 

implementazioni concrete (come ParallelBehaviour) si prestano particolarmente a 

tale concetto. Dotando un CompositeBehaviour di un dispatcher ed un Thread-Pool 

personali, oltre allo scheduler che implicitamente vi è già contenuto, si può ricostruire 

al suo livello la stessa configurazione presente nell'Agent, creando così una struttura 

gerarchica: come un Agent amministra i Behaviour affidatigli tramite scheduler e 

dispatcher, così può fare ogni CompositeBehaviour nei confronti dei suoi 

sub-behaviour. 

Questa possibilità permette di distinguere altri due modelli: il modello 

Top-Level-Scheduling, nel quale ogni agente possiede un solo dispatcher e 

scheduler ai quali è demandato anche il lavoro dei livelli inferiori, ed il modello 

Recursive-Scheduling, nel quale ogni CompositeBehaviour rappresenta un'unità 

autonoma d'esecuzione. 

Mentre il primo modello ha alcuni gravi svantaggi, ad esempio il fatto che lo 

scheduler mescola tra loro Behaviour top-level e Behaviour provenienti da livelli 

inferiori (che potrebbero sottrarre risorse ai primi), il secondo offre un sistema 

semplice per implementare il modello Thread-Pool-Cluster: raggruppare tutti i 

Behaviour di un cluster sotto il controllo di un ParallelBehaviour cui è stato affidato il 

Thread-Pool desiderato.

Modello di Concorrenza proposto - Mapping di modelli con gli strumenti scelti 51 

4.3 Mapping di modelli con gli strumenti scelti 

Gli strumenti scelti per implementare la concorrenza, il dispatcher e lo scheduling 

ricorsivo sfruttando i CompositeBehaviour, consentono una grande flessibilità e la 

possibilità di adattare il modello a diverse esigenze, anche a quelle di simulare 

modelli già noti. 

?? Thread-per-Agent: questo è il modello attualmente adottato da JADE che deve 

necessariamente essere supportato per motivi di compatibilità. È facilmente 

ottenibile fornendo all'Agent un Thread-Pool single-threaded, e facendo lo stesso 

con ogni CompositeBehaviour. 

?? Thread-per-Behaviour: ogni richiesta d'esecuzione da parte di un Behaviour viene 

immediatamente assolta da un nuovo thread (non vi è mai attesa per carenza di 

risorse). È ottenibile fornendo il top-dispatcher di un pool illimitato. 

?? Thread-Pool-per-Agent: ad ogni Agent è assegnato un numero massimo di thread 

da suddividere tra le varie richieste. I thread, una volta creati, potrebbero 

rimanere attivi e pronti per un nuovo utilizzo più o meno a lungo. È ottenibile 

limitando la capacità del pool del dispatcher e fissando opportune deadline per i 

thread.

Implementazione di riferimento - EmbeddedThread 52 

5 Implementazione di riferimento 

Il presente capitolo descrive le classi create per implementare quanto 

precedentemente illustrato [cap. 4 Modello di Concorrenza proposto]. Per ogni classe 

sono descritti: scopi e responsabilità dell'oggetto, i metodi d'interfaccia (ed alcuni 

privati) suddivisi per funzionalità correlate, interazioni con sotto-componenti, scelte 

realizzative salienti e, quando ritenuto significativo, parti di codice e problemi 

incontrati nella realizzazione. 

Si prendono successivamente in esame le modifiche che è necessario apportare a 

classi già facenti parte di JADE, come Behaviour, CompositeBehaviour e Agent: 

questa fase risulta particolarmente delicata per motivi di compatibilità all'indietro. 

Infine s'illustra brevemente un piccola "suite di testing" utilizzata per verificare la 

correttezza delle soluzioni implementate (lungi dal considerarsi completa). 

5.1 EmbeddedThread 

EmbeddedThread 

Mutex 

(from EmbeddedThread) 

Diagramma 21 : UML Class Diagram di EmbeddedThread e componenti 

1 

1


5.1.1 Scopi e funzionalità 


+$ CREATED : int = 1 

+$ RUNNING : int = 2 

+$ ABOUT_TO_SUSPEND : int = 3 

+$ SUSPENDED : int = 4 

+$ ABOUT_TO_TERMINATE : int = 5 

+$ TERMINATED : int = 6 

+$ ABOUT_TO_INTERRUPT : int = 7 

+$ INTERRUPTED : int = 8 

+ EmbeddedThread(td : ThreadDispatcher) : EmbeddedThread 

+ setBehaviour(b : Behaviour) 

+ getBehaviour() : Behaviour 

+ start() 

+ run() 

+ suspend() 

+ suspend(timeout : long) : boolean 

+ resume() 

+ stop() 

+ stop(timeout : long) : boolean 

+ interrupt() 

+ getThreadState() : int 

Diagramma 22 : UML Class Diagram di EmbeddedThread 

La classe EmbeddedThread si occupa di incapsulare, in maniera appropriata per i 

particolari scopi cui è prefissa, un thread di Java e di fornire all'utente tutti i metodi 

necessari per gestirne opportunamente stato e compiti. 

Le sue funzionalità possono essere divise in: 

1. Ispezione e modifica dello stato del thread. 

2. Ispezione ed assegnazione dell'attività del thread.


5.1.2 Meccanismi di sincronizzazione degli accessi: lock 

La classe, avendo lo stato interno accessibile da più linee d'esecuzione, adotta 

particolari sistemi di protezione che, pur non essendo i suoi metodi dichiarati 

synchronized, assicurano una corretta sequenzializzazione delle chiamate alle 

funzioni e, di conseguenza, il mantenimento della coerenza interna. Particolare 

attenzione è stata posta nel limitare i vincoli di mutua esclusione alle sole parti di 

codice in cui fossero strettamente necessari, in modo da consentire la più ampia 

sovrapposizione tra le diverse chiamate ai metodi ed il normale ciclo d'esecuzione 

del thread stesso. 

Per ottenere questo risultato si è scelto di adottare, ed incapsulare nella classe, un 

oggetto generico (un'istanza di Object) con il solo scopo di usare il suo monitor 

interno (presente in ogni oggetto Java) per i fini di sincronizzazione: l'oggetto è stato 

adoperato come "lock". Il costrutto implementato prevede che, ogni volta che si 

debba accedere ad una sezione critica di codice, questa sia dichiarata all'interno di 

un blocco synchronized sul lock stesso: così facendo, il primo thread d'esecuzione 

che entra nel blocco di codice protetto acquisisce il monitor del lock impedendo ad 

altre chiamate concorrenti di accedervi prima del suo rilascio e quindi, in generale, 

della terminazione del blocco stesso [Riquadro 1]. 

... 

private Object stateLock = new Object(); 

... 

public void start() 

{ 

synchronized(stateLock) 

{ 

if(threadState==CREATED) 

{ 

threadState=RUNNING; 

theThread.start(); 

} 

} 

} 

... 

Riquadro 1 : Sincronizzazione degli accessi allo stato tramite stateLock


Tale procedura è servita per serializzare le modifiche allo stato del thread 

incapsulato in modo che le transizioni del suo automa a stati finiti (FSM) fossero 

gestite correttamente. 

La scelta dello stateLock si è rivelata utile anche per la possibilità, ampiamente 

sfruttata, di poter usare i suoi meccanismi di attesa e notifica (wait() e notify()) per 

sincronizzare gli effettivi cambiamenti di stato che avvenivano all'interno del thread 

incapsulato. 

5.1.3 Ispezione e modifica dello stato 

resume() 

Created 

Running 

start() 

suspend() 

About to Suspend 

interrupt() 

stop() 

Suspended Terminated 

These transitions 

are executed 

internally by the 

thread 

Diagramma 23 : UML State Diagram per EmbeddedThread 

Interrupted 

About to Interrupt 

interrupt() 

About to Terminate


Molta importanza è stata assegnata nel progetto della classe alla rappresentazione 

interna dei diversi stati in cui può trovarsi il thread incapsulato ed ad una loro 

robustezza di gestione. 

Il progetto è stato basato sulle critiche (e relativi interventi migliorativi consigliati) 

mossi dalla Sun Microsystem stessa ai metodi stop(), suspend() e resume() della 

classe Thread di Java nel relativo documento delle API [Bibl. 6]. 

Tale documento pone in enfasi i problemi di inconsistenza derivanti dall'uso di metodi 

coercitivi per terminare o bloccare linee d'esecuzione dall'esterno, visto che tali 

chiamate rilasciano ogni monitor del thread in questione con relativa propagazione 

dei danni su altri oggetti che ne erano protetti. Il suggerimento per evitare tali 

inconvenienti è quello di fornire metodi che settino delle variabili per segnalare 

semplicemente i cambiamenti di stato e lasciare che sia il thread stesso a 

controllarne i valori durante l'esecuzione ed a prendere gli adeguati provvedimenti 

(sospensione volontaria e riattivazione dell'esecuzione utilizzando wait() e notify() del 

monitor interno). 

Invece di usare più variabili booleane, nel progetto si è adoperata una variabile intera 

con significato di variabile di stato, affiancata da costanti pubbliche per facilitarne 

l'associazione valore-stato; inoltre per la sospensione è stato usato un oggetto 

apposito [par. 5.1.6 Mutex].


Mentre molti stati non hanno bisogno di commenti essendo i nomi stessi 

autoesplicativi della situazione, una buona parte di questi risulta sdoppiata per 

distinguere tra momenti diversi che accadono durante il life-cycle del thread: ci si 

riferisce alle coppie "STATE" e "ABOUT_TO_STATE" (dove "STATE" sta al posto di 

un effettivo stato del sistema) [Riquadro 2]. 

... 

public static final int CREATED=1; 

public static final int RUNNING=2; 

public static final int ABOUT_TO_SUSPEND=3; 

public static final int SUSPENDED=4; 

public static final int ABOUT_TO_TERMINATE=5; 

public static final int TERMINATED=6; 

public static final int ABOUT_TO_INTERRUPT=7; 

public static final int INTERRUPTED=8; 

private int threadState; 

... 

private Object stateLock = new Object(); 

private Mutex suspendLock=new Mutex(); 

... 

Riquadro 2 : EmbeddedThread: definizione delle costanti di stato ed oggetti per la sospensione 

e la sincronizzazione degli accessi. 

L'apparente replica dello stato, è da attribuire al fatto che, mentre la chiamata ad un 

metodo può solo notificare una "richiesta di cambiamento", il cambiamento effettivo 

può unicamente avvenite all'interno del thread d'esecuzione stesso dopo 

l'apprendimento della avvenuta notifica [Riquadro 4]. Questo sistema, consentendo 

delle transizioni di stato interne al thread stesso, dà la possibilità di esercitare un 

controllo più preciso sulla forza con cui un determinato passaggio di stato deve 

essere compiuto: è così possibile fare al thread richieste sincrone, asincrone e 

temporizzate. 

5.1.4 Transizioni temporizzate 

Come già detto precedentemente, il sistema adoperato per le modifiche dello stato 

distingue tra richieste di transizioni ed effettiva esecuzione delle stesse. Una richiesta


di transizione può quindi essere gestita ad un livello di dettaglio maggiore e la 

relativa chiamata assumere diversi significati: 

1. Richiesta asincrona: la richiesta viene inoltrata (modificando lo stato in 

"ABOUT_TO_STATE") ed il metodo ritorna senza preoccuparsi se il passaggio 

sia avvenuto o no [Diagramma 24]. 

td : Thread 

Dispatcher 

stop( ) 

et : Embedded 

Thread 

action( ) 

return from action() 

b : 

Behaviour 

Diagramma 24 : UML Sequence Diagram di uno stop() asincrono 

If action() doesn't 

return (is 

blocked) stop() 

does nothing


2. Richiesta sincrona: una volta inoltrata la richiesta, il metodo attende sino a che 

l'effettiva transizione del thread ha corso (nel caso questa non dovesse mai 

avvenire, il chiamante attende indefinitamente) [Diagramma 25]. 


Dispatcher 

stop(long) 

return from stop() 

et : Embedded 


action ( ) 

Diagramma 25 : UML Sequence Diagram di uno stop() sincrono 

b : 

Behaviour 

return from action() Stop() waits till 

action() returns: 

if action() is 

blocked also 

stop() blocks


3. Richiesta temporizzata: la richiesta viene inoltrata; se il thread modifica il suo 

stato entro un parametrizzato lasso di tempo, allora la chiamata ritorna 

segnalando l'avvenuto successo, altrimenti, una volta trascorso il tempo fissato 

senza che sia avvenuta transizione, la chiamata ritorna ugualmente segnalando il 

fallimento [Diagramma 26]. 


Dispatcher 

stop(long) 

return from stop() 

et : Embedded 


action( ) 

return from action() 

b : 

Behaviour 

Diagramma 26 : UML Sequence Diagram di uno stop() con deadline 

Stop() waits action() 

to return at most for 

a specified ammount 

of time, then returns 

anyway signaling if it 

failed or not 

Il primo paradigma può essere rischioso se il chiamante basa operazioni successive 

sulla riuscita della transizione, in quanto questa non fornisce alcuna garanzia che il


thread compia effettivamente la modifica dello stato desiderata; d'altro canto, l'ultima 

variante supera il limite della seconda che può causare un blocco in caso di problemi 

del thread nell'attuare le richieste. 

Tali tipologie differenti sono state riunite in un unico metodo parametrizzato (per 

stesso genere di transizione), il cui argomento è la "deadline" del metodo: il tempo 

massimo entro cui il metodo deve tornare al chiamante [Riquadro 3]. 

1 public boolean suspend(long expiration) 

2 { 

3 Deadline.checkExpiration(expiration); 

4 synchronized(stateLock) 

5 { 

6 if(threadState==RUNNING || threadState==ABOUT_TO_SUSPEND) 

7 { 

8 threadState=ABOUT_TO_SUSPEND; 

9 try 

10 { 

11 if(expiration!=Deadline.NOW) 

12 if(expiration==Deadline.NEVER) stateLock.wait(); 

13 else stateLock.wait(expiration); 

14 } 

15 catch(InterruptedException ie) {} 

16 } 

17 return (threadState==SUSPENDED); 

18 } 

19 } 

Riquadro 3 : EmbeddedThread.suspend(expiration) 

Per standardizzare l'argomento di tali generi di metodi "temporizzati", è stata creata 

una classe apposita, evitando così di dover duplicare costanti e creare confusione tra 

i valori di queste [par. 5.5.2 Deadline]. 

SI è scelto di applicare questo costrutto a transizioni considerate critiche per la loro 

importanza e per il controllo che si voleva avere sul loro effettivo accadimento: 

suspend() e stop(); anche interrupt() è stata, in un certo senso, temporizzata, ma in 

maniera differente e nascosta all'utente, che quando interrompe un thread si aspetta 

che questo accada in ogni caso: si vedrà che ciò non sempre è vero [par. 5.4.3 

Metodi non interrompibili].


Nel Riquadro 3 si possono notare, nelle linee 11-13, i meccanismi di temporizzazione 

differenziati secondo il parametro ed alla linea 17 la notifica del successo o meno 

della transizione; nel Riquadro 4 invece appaiono le linee di codice in cui il thread, 

una volta controllata l'avvenuta richiesta di cambiamento, la esegue e ne da notifica 

usando il lock: alle linee 13-17 abbiamo la sospensione, alle 21-25 la terminazione 

ed alle linee 29-33 l'avvenuta interruzione. 

1 public void run() 

2 { 

3 try 

4 { 

5 while(threadState!=ABOUT_TO_TERMINATE) 

6 { 

7 if(theBehaviour!=null) theBehaviour.action(); 

8 suspend(); 

9 theThreadDispatcher.requestBehaviour(this); 

10 


12 { 

13 if(threadState==ABOUT_TO_SUSPEND) 

14 { 

15 threadState=SUSPENDED; 

16 stateLock.notify(); 

17 } 

18 } 

19 if(threadState==SUSPENDED) suspendLock.mWait(); 

20 } 


22 { 

23 threadState=TERMINATED; 


25 } 

26 } 

27 catch(InterruptedException ie) 

28 { 


30 { 

31 threadState=INTERRUPTED; 


33 } 

34 theThreadDispatcher.notifyInterrupted(this); 

35 } 

36 } 

Riquadro 4 : EmbeddedThread.run()


5.1.5 Ispezione ed assegnazione dell'attività 

L'attività di un EmbeddedThread consiste nell'esecuzione del metodo action() del 

Behaviour assegnatogli. 

Il modello non-preemptive di JADE prevede che il tempo d'esecuzione sia diviso in 

quanti d'azione, ed il metodo action() ne racchiude appunto uno. Il ciclo principale di 

un EmbeddedThread prevede l'esecuzione della action() e la volontaria sospensione 

fino all'eventuale assegnazione di un nuovo Behaviour da eseguire: ciò fa sì che 

momenti ideali per questo compito siano gli stati CREATED e SUSPENDED, mentre 

diviene privo di significato eseguire un cambiamento di compito durante stati come 

RUNNING o TERMINATED.


Il metodo setBehaviour() si occupa dell'assegnazione del Behaviour e dei relativi 

controlli sullo stato per evitare errori; analogamente, un metodo getBehaviour() 

restituisce il "comportamento" attualmente in esecuzione sul thread, per i compiti di 

notifica e rilevamento di stadi superiori [par. 5.2 ThreadDispatcher] [Diagramma 27]. 

Diagramma 27 : UML Sequence Diagram per l'assegnazione, ed ispezione, dei Behaviour ad un 


s : 

Scheduler 

b:=schedule ( ) 

notifyExecuted (b) 


Dispatcher 

assignBehaviour (et,s) 

setBehaviour (b) 

requestBehaviour (et) 

b:=getBehaviour ( ) 

s:=get b's scheduler 

et : Embedded 

Thread


5.1.6 Mutex 

La classe Mutex, incapsulata all'interno di EmbeddedThread, implementa il costrutto 

del "semaforo", utilizzato dalla classe contenitrice per l'effettiva sospensione del 

thread d'esecuzione. 

L'utilizzo del semaforo, al posto del più semplice oggetto generico utilizzato come 

"lock", si è reso necessario per evitare problemi di corse critiche che avrebbero 

potuto portare al deadlock. 

I normali metodi wait() e notify() forniti dalla classe Object, infatti, funzionano 

correttamente quando si è certi che ogni notify() segua temporalmente il relativo 

wait(), in modo da risvegliare un thread così sospeso, ma nel caso in cui, 

malauguratamente, il wait() tardi ed il notify() venga lanciato prima del dovuto, tale 

messaggio di notifica va perso senza lasciare traccia, causando l'attesa illimitata da 

parte del successivo wait(). 

Mutex 

(from EmbeddedThread) 

+ Mutex(initVal : int = 0) : Mutex 

+ mSignal() : int 

+ mWait() : int 

Diagramma 28 : UML Class Diagram di EmbeddedThread::Mutex 

Per evitare questo inconveniente, la classe Mutex definisce i metodi mWait() ed 

mSignal(), che a differenza degli analoghi suddetti, lasciano traccia esplicita della 

loro esecuzione in una variabile contatore interna alla classe stessa. Detta variabile 

intera, solitamente inizializzata a zero, viene decrementata ad ogni esecuzione di 

mWait() e, viceversa, incrementata ad ogni mSignal(). Internamente a tali metodi 

sono poi eseguite le vere chiamate a wait() e notify(), ma condizionatamente al 

valore della variabile (così da formare una sorta di "guardia" alle sospensioni 

indesiderate): un wait() viene eseguito solo se il contatore è minore o uguale a zero.


Con questo sistema un mSignal() che dovesse arrivare prima del relativo mWait(), 

porterebbe da zero ad uno il valore della variabile interna, che divenendo maggiore 

di zero eviterebbe il blocco successivo. 

Controllando il codice relativo all'uso di Mutex all'interno del metodo run() di 

EmbeddedThread [Riquadro 5] ci si può rendere conto delle motivazioni che hanno 

portato a questa scelta: 

... 


{ 

if(threadState==ABOUT_TO_SUSPEND) 

{ 

threadState=SUSPENDED; 

stateLock.notify(); 

} 

} 

if(threadState==SUSPENDED) suspendLock.mWait(); 

... 

Riquadro 5 : EmbeddedThread.run(): blocco per la sospensione del thread. 

StateLock, come già detto, è l'oggetto usato per implementare la mutua esclusione 

tra i blocchi che devono ispezionare e modificare lo stato interno del thread, mentre 

suspendLock è l'istanza di Mutex di nostro interesse.


Bisogna innanzi tutto notare che la sospensione sul semaforo avviene al di fuori del 

blocco synchronized in quanto una wait() annidata su più oggetti sincronizzati libera 

soltanto il monitor dell'oggetto più interno, lasciando bloccati i livelli superiori: il 

blocco relativo alla modifica dello stato del thread non sarebbe mai abbandonato, 

poiché i notify() necessari al risveglio del mutex vengono lanciati anche loro 

dall'interno di blocchi sincronizzati sul monitor del medesimo oggetto (stateLock) 

[Riquadro 6]. 

public void resume() 

{ 


{ 

if(threadState==ABOUT_TO_SUSPEND || threadState==SUSPENDED) 

{ 

if(threadState==SUSPENDED) 

{ 

threadState=RUNNING; 

suspendLock.mSignal(); 

} 

else threadState=RUNNING; 

} 

} 

} 

Riquadro 6 : EmbeddedThread.resume() 

Nel Riquadro 5 si può osservare come, una volta liberato il monitor dello stateLock e 

prima di eseguire l'effettiva sospensione sul mutex, la classe contenitrice 

EmbeddedThread dichiari già di essere "SUSPENDED": questo è il punto in cui 

potrebbe verificarsi la condizione di corsa critica; un resume(), ad esempio, 

riporterebbe lo stato a RUNNING ed eseguirebbe un notify() che andrebbe perduto; il 

successivo wait() bloccherebbe il thread in un fittizio stato "attivo" indefinitamente.

Implementazione di riferimento - ThreadDispatcher 68 

5.2 ThreadDispatcher 

ReadyThreadsManager 

(from ThreadDispatcher) 

ThreadDispatcher 

Diagramma 29 : UML Class Diagram di ThreadDispatcher e componenti 

1 

1 

1 

1 

RequestsManager 

(from ThreadDispatcher)



+$ UNLIMITED_POOL : int = 0 

+$ SINGLE_THREADED : int = 1 

Diagramma 30 : UML Class Diagram di ThreadDispatcher 

La classe ThreadDispatcher è l'oggetto che si occupa fisicamente di porre in 

esecuzione i Behaviour su un thread. 

Amministra un pool di EmbeddedThread, che può variare da zero ad infinito 

(potenzialmente), e ne gestisce il life-cycle. Comunica da un lato con le istanze di 

EmbeddedThread di cui si occupa, dall'altro con uno o più scheduler, ai quali 

richiede, secondo necessità, i Behaviour. 

Le funzionalità offerte possono suddividersi in: 

1. Ispezione e modifica dei parametri del Thread-Pool 

2. Dispatching e gestione dei thread 

ThreadDispatcher 

+ ThreadDispatcher(a : Agent, s : Scheduler, td : TimerDispatcher) : ThreadDispatcher 

+ ThreadDispatcher(cb : CompositeBehaviour) : ThreadDispatcher 

+ setReadyThreadsExpiration(expiration : long) 

+ getReadyThreadsExpiration() : long 

+ setPoolCapacity(threadsNumber : int) 

+ getPoolCapacity() : int 

+ dispatch() 

+ stop(expiration : long) 

+ stopRunningThreads(expiration : long) : int 

+ requestScheduling(s : Scheduler) : boolean 

+ requestBehaviour(et : EmbeddedThread) 

+ notifyInterrupted(et : EmbeddedThread) 

- assignBehaviour(et : EmbeddedThread, s : Scheduler) 

3. Amministrazione delle richieste degli scheduler e dei thread


5.2.2 Ispezione e modifica dei parametri del Thread-Pool 

La classe offre la possibilità di agire sui parametri che caratterizzano il pool di thread 

anche a tempo d'esecuzione. Le caratteristiche modificabili del pool sono il numero 

massimo di thread consentite (la capacità del pool) ed il periodo massimo di inattività 

concesso ad un thread prima di venire eliminato per liberare risorse di sistema. 

Il periodo d'inattività dei thread è amministrato tramite i metodi 

setReadyThreadsExpiration() e getReadyThreadsExpiration() che richiamano, per 

l'effettiva esecuzione i relativi metodi della classe ReadyThreadsManager 

(incapsulata all'interno di ThreadDispatcher) [par. 5.2.5 ReadyThreadsManager]. 

La capacità del pool viene invece gestita direttamente dalla classe e dai suoi metodi 

setPoolCapacity() e getPoolCapacity().Per agevolare la gestione della capacità sono 

state introdotte nella classe alcune variabili statiche per associare valori numerici a 

stati, come SINGLE_THREADED per assegnare un solo thread al pool e 

UNLIMIED_POOL per consentire modelli senza limite massimo per il numero di 

thread (Thread-per-Behaviour). 

Il metodo setPoolCapacity() non si limita a modificare il valore della variabile 

associata al limite massimo del pool, ma effettua anche operazioni di notifica e 

rinormalizzazione delle risorse allocate. Quando la capacità massima del pool viene 

aumentata, potrebbe infatti accadere che un ThreadDispatcher, precedentemente 

bloccato in attesa che si liberassero dei thread, abbia ora la possibilità di mandare in 

esecuzione dei nuovi Behaviour. Analogamente, quando il pool viene ridotto è 

necessario fare in modo che il numero di istanze di EmbeddedThread non superi, nel 

computo complessivo di ready e running, la nuova capacità. Nel caso questo 

avvenga si procederà con l'eliminare innanzitutto i readyThread in eccesso, e, se ciò 

non dovesse bastare, si procederà con l'eliminazione degli attuali running solo dopo 

che la loro sessione d'esecuzione ha termine. 

5.2.3 Dispatching e gestione dei thread 

L'operazione principale di un ThreadDispatcher, fare in modo che ogni Behaviour 

venga eseguito da un thread, è effettuata tramite chiamate a dispatch(). Tale


metodo, appoggiandosi alle classi incapsulate, attende fintanto che non vi siano uno 

scheduler che abbia un Behaviour da eseguire e un EmbeddedThread disponibile 

per l'esecuzione. Il thread per l'esecuzione può essere creato, recuperato dai ready, 

o appena tornato da una sessione precedente, secondo che la capacità del pool sia 

stata raggiunta o no. 

Il metodo ha due modalità d'esecuzione distinte. Nel caso il pool sia di tipo 

single-threaded, nessuna istanza di EmbeddedThread viene creata, ma il corpo 

stesso di dispatch() contiene il codice per un'esecuzione diretta di action() entro lo 

stesso thread dell'invocante (che attende quindi la sua esecuzione). Nelle situazioni 

multi-threaded, invece, dispatch() assegna il Behaviour da eseguire ad un 

EmbeddedThread e ritorna immediatamente.


Il metodo dispatch() può lanciare l'eccezione InterruptedException nel caso fosse 

interrotto mentre in attesa delle condizioni per il dispatching. Se l'interruzione 

avviene, invece, durante l'esecuzione di action() (solo per il caso single-threaded), 

questa viene catturata internamente e gestita tramite la catena di segnalazioni che 

corre tra i componenti del modello [Riquadro 7]. 

public synchronized void dispatch() throws InterruptedException 

{ 

if(state==ACTIVE) 

{ 

while(!requests.thereIsAReadyThread() && 

(!requests.thereIsAReadyScheduler() || poolIsFull())) 

{ 

if(theAgent!=null && hasNoRunningThreadsBelow()) 

theAgent.doIdle(); 

wait(); 

} 

Scheduler theScheduler=requests.getReadyScheduler(); 

if(poolCapacity==SINGLE_THREADED) 

{ 

Behaviour theBehaviour=null; 

try 

{ 

theBehaviour=theScheduler.schedule(); 

actionWrapper(theBehaviour); 

theScheduler.notifyExecuted(theBehaviour); 

} 

catch(InterruptedException ie) 

{ 

theScheduler.notifyInterrupted(theBehaviour); 

} 

} 

else 

synchronized(readyThreads) 

{ 

EmbeddedThread theThread; 

if(requests.thereIsAReadyThread()) 

theThread=requests.getReadyThread(); 

else if(readyThreads.size()>0) 

theThread=readyThreads.get(); 

else 

theThread=new EmbeddedThread(this); 

assignBehaviour(theThread,theScheduler); 

} 

} 

} 

Riquadro 7 : ThreadDispatcher.dispatch()


Il codice di dispatch() appare particolarmente compatto, non, come si potrebbe 

pensare, per la semplicità dell'operazione svolta, ma poiché buona parte della 

complessità è nascosta, ed incapsulata, nei diversi metodi interni che richiama. 

Oltre alle operazioni di dispatching, la classe offre due metodi per la gestione 

dell'interruzione delle attività del ThreadDispatcher utili per operazioni riguardanti la 

mobilità, o nel caso richiesto da altre attività (come il metodo Scheduler.reset() 

[par. 5.3.7 Cambiamenti di stato imposti ai Behaviour dall'esterno]): questi sono 

stop() e stopRunningThreads() entrambi con parametro una deadline [par. 5.4 

Gestione delle interruzioni]. Mentre il secondo interrompe i running thread che non 

terminano entro il limite fissato dalla deadline (e pone quelli che finiscono tra i ready), 

il primo blocca ogni tipo d'attività, interrompe i running, elimina i ready e rimuove le 

richieste degli scheduler [par. 5.2.6 RequestsManager]. 

5.2.4 Amministrazione delle richieste degli scheduler e dei thread 

Per evitare il polling dei thread del pool e degli scheduler che si affidano ad esso, il 

ThreadDispatcher ricorre a meccanismi di notifica da parte degli EmbeddedThread 

che hanno terminato la sessione d'esecuzione dei Behaviour loro assegnati e degli 

scheduler che hanno disponibilità di nuovi Behaviour da schedulare [par. 5.3.5.2 

Richieste di scheduling].


La gestione di tali richieste è affidata interamente al RequestsManager [par. 5.2.6 

RequestsManager], a parte le operazioni di notifica conseguenti la terminazione 

dell'esecuzione di un Behaviour [Riquadro 8] [Diagramma 31]. 

public synchronized void requestBehaviour(EmbeddedThread et) 

{ 

Behaviour b=et.getBehaviour(); 

if(b!=null) 

{ 

Scheduler s=(Scheduler) associationBS.remove(b); 

s.notifyExecuted(b); 

} 

if(state==ACTIVE) 

{ 

requests.add(et); 

notify(); 

} 

else 

{ 

runningThreads.remove(et); 

et.stop(Deadline.NEVER); 

} 

} 

Riquadro 8 : ThreadDispatcher.requestBehaviour()



Dispatcher 

EmbeddedThread (td) 

setBehaviour (b1) 

start ( ) 


et : Embedded 


action( ) 

suspend ( ) 

At this point the thread is 

waiting on the Mutex 

setBehaviour (b2) 

resume ( ) 


stop ( ) 

suspend ( ) 

b1 : 

Behaviour 

action( ) 

b2 : 

Behaviour 

Diagramma 31 : UML Sequence Diagram per il ciclo base esecuzione/richiesta di Behaviour


5.2.5 ReadyThreadsManager 

La classe ReadyThreadsManager, incapsulata in ThreadDispatcher, è stata pensata 

per agevolare le operazioni riguardanti la gestione di quei thread che, avendo già 

eseguito il loro compito ed essendo il ThreadDispatcher privo di nuovi Behaviour da 

eseguire, non hanno momentaneamente nulla da fare e, teoricamente, potrebbero 

essere eliminati: quando il ThreadDispatcher avrà nuovi compiti da mandare in 

esecuzione, allora saranno creati dei nuovi thread appositamente per lo scopo. 

Le operazioni di creazione-distruzione di thread, anche se meno impegnative delle 

corrispettive per i task, sono comunque dispendiose in termini di risorse di macchina 

(con particolare riferimento al tempo) ed in caso di frequenti richieste di questo tipo, 

come certamente sarebbe nel caso in esame, data la piccola mole di lavoro affidata 

ai thread (si tratta di eseguire il solo codice della action()), andrebbe sprecato molto 

tempo di calcolo. 


ReadyThreadsManager 

+ ReadyThreadsManager(td : TimerDispatcher = null) : ReadyThreadsManager 

+ assignTimerDispatcher(td : TimerDispatcher) 

+ setExpiration(millis : long) 

+ getExpiration() : long 

+ add(et : EmbeddedThread) : boolean 

+ get() : EmbeddedThread 

+ remove(et : EmbeddedThread) : boolean 

+ stopOne() 

+ stopAll() 

+ doTimeout(t : Timer) 

+ contains(et : EmbeddedThread) : boolean 

+ size() : int 

Diagramma 32 : UML Class Diagram di ThreadDispatcher::ReadyThreadsManager 

Per limitare il numero d'operazioni di creazione-distruzione di thread, si è pensato di 

introdurre una specie di "deposito" per i thread privi di compiti, in modo che possano


essere immediatamente disponibili quando si presenti l'evenienza: un Behaviour che 

debba essere eseguito, prima di portare alla creazione di un nuovo thread, può 

controllare ed usufruire dei thread del deposito. Questi thread, essendo sospesi e 

non in esecuzione (running), sono detti ready. 

Essendo i thread un'importante risorsa del sistema, risulta d'altra parte sconveniente 

che questi, una volta creati, possano rimanere inattivi indefinitamente: per questa 

ragione ad ogni thread divenuto ready è assegnata una deadline temporale entro la 

quale deve essere riutilizzato, o verrà eliminato. Tale limite può essere fissato per 

tutta la classe ed anche modificato a tempo d'esecuzione (con validità a partire dai 

thread inseriti successivamente), e può variare il comportamento della classe 

dall'immediata distruzione dei thread non più attivi, fino al deposito a tempo 

indeterminato; questa particolare funzionalità è stata realizzata includendo nel 

ReadyThreadsManager un'istanza della classe Deadline [par. 5.5.2 Deadline]. 

La presenza di azioni temporizzate (nella fattispecie la distruzione di thread) richiede, 

come ovvio, l'utilizzo del TimerDispatcher della piattaforma e delle strutture dati 

correlate [par. 5.5.1 AssociationTimerObject]: la classe implementa l'interfaccia 

TimerListener e si può notare la presenza di metodi per l'assegnazione di un 

TimerDispatcher.


Come già accennato precedentemente, al momento dell'inserimento di un thread tra i 

ready, tramite il metodo add(), a questo viene assegnata la deadline attuale; inoltre, 

per far parte del deposito, l'istanza di EmbeddedThread deve trovarsi nello stato 

CREATED o SUSPENDED [Riquadro 9]. 

public synchronized boolean add(EmbeddedThread et) 

{ 

if(et==null) throw new IllegalArgumentException(); 

int threadState=et.getThreadState(); 

if(threadState!=EmbeddedThread.CREATED && 

threadState!=EmbeddedThread.ABOUT_TO_SUSPEND && 

threadState!=EmbeddedThread.SUSPENDED) 

throw new IllegalArgumentException(); 

if(threads.contains(et)) throw new IllegalArgumentException(); 

boolean result; 

if(threadState==EmbeddedThread.ABOUT_TO_SUSPEND) 

result=et.suspend(Deadline.NEVER); 

else result=true; 

if(result) 

{ 

long expiration=deadline.getExpiration(); 

if(expiration!=Deadline.NOW) 

{ 

et.setBehaviour(null); 

threads.add(et); 

if(theTimerDispatcher!=null && expiration!=Deadline.NEVER) 

{ 

Timer t=new TimerTestingImpl(System.currentTimeMillis()+ 

expiration,this); 

t=theTimerDispatcher.add(t); 

pendingTimers.addPair(et,t); 

} 

} 

else et.stop(); 

} 

return result; 

} 

Riquadro 9 : ThreadDIspatcher::ReadyThreadsManager.add() 

Per ottenere un thread dal deposito si adopera il metodo get(), che restituisce (senza 

eliminarlo dalla lista) l'EmbeddedThread con scadenza più prossima [Riquadro 10]; 

l'eliminazione dalla lista è demandata a remove(). Sono forniti, inoltre, due metodi per 

terminare i thread inseriti nel caso servisse liberare risorse: stopOne() ne elimina uno


per chiamata partendo da quello con deadline più prossima, mentre stopAll() li 

elimina tutti. 

public synchronized EmbeddedThread get() 

{ 

EmbeddedThread theThread=null; 

if(threads.size()>0) 

{ 

if(pendingTimers.size()>0) 

theThread=(EmbeddedThread)pendingTimers.getNextToExpire(); 

else 

theThread=(EmbeddedThread)threads.get(0); 

} 

return theThread; 

} 

Riquadro 10 : ThreadDispatcher::ReadyThreadsManager.get() 

5.2.6 RequestsManager 


RequestsManager 

+ add(o : Object) : boolean 

+ thereIsAReadyScheduler() : boolean 

+ thereIsAPendingThread() : boolean 

+ thereIsAReadyThread() : boolean 

+ getReadyScheduler() : Scheduler 

+ getPendingThread() : EmbeddedThread 

+ getReadyThread() : EmbeddedThread 

+ remove(o : Object) : boolean 

+ removeAll() 

+ contains(o : Object) : boolean 

Diagramma 33 : UML Class Diagram di ThreadDispatcher::RequestsManager 

La classe RequestsManager di ThreadDispatcher ha il compito di fornire, all'istanza 

di ThreadDispatcher che la contiene, una serie di agevolazioni per la gestione delle


richieste di operazioni che provengono alla classe contenitrice sia dai thread 

incapsulati in EmbeddedThread, sia dalle istanze di Scheduler che si affidano ad 

essa per l'esecuzione dei Behaviour a loro affidati. Compito di ThreadDispatcher è, 

infatti, quello di far incontrare richieste ed offerte provenienti dalle suddette classi. 

La classe, però, non è un semplice contenitore di richieste, ma si occupa di parte 

dell'elaborazione, soprattutto di quella mirata a filtrare quelle richieste per le quali non 

è possibile l'incontro tra domanda ed offerta. 

La classe opera su due fronti: 

1. Richieste, da parte di oggetti EmbeddedThread, di ricevere un nuovo Behaviour 

da eseguire, avendo terminato l'action() del precedente. 

2. Notifiche, da parte di uno o più Scheduler, che questi hanno a disposizione (al 

momento) dei Behaviour pronti per essere schedulati. 

Per quanto riguarda il primo tipo di chiamata, la classe si occupa di gestire solo 

l'eventuale nuova assegnazione, in quanto la corretta gestione della terminazione del 

Behaviour precedente è affidata interamente al ThreadDispatcher.


Un thread che ha appena terminato l'esecuzione di un Behaviour può, in condizioni 

normali, essere immediatamente disponibile per l'impiego con un nuovo compito, ma 

in alcuni casi è necessario operare diversamente: 

1. Nell'intervallo temporale tra la precedente assegnazione e la nuova richiesta, il 

pool a disposizione del ThreadDispatcher è stato ridimensionato ed i thread 

attualmente in esecuzione eccedono la nuova capacità: dopo il loro corretto 

ritorno non sono più necessari e devono essere eliminati. I thread così scremati 

vengono definiti "pendingThread" in quanto sono pronti all'esecuzione ed in 

attesa di un'eventuale assegnazione di Behaviour [Riquadro 11]. 

public synchronized boolean thereIsAPendingThread() 

{ 

while(behaviourRequestsQueue.size()>0) 

{ 

EmbeddedThread theThread= 

(EmbeddedThread)behaviourRequestsQueue.get(0); 

if(poolCapacity==SINGLE_THREADED || 

(runningThreads.size()>poolCapacity && 

poolCapacity!=UNLIMITED_POOL)) 

removeBRAndStopT((EmbeddedThread)behaviourRequestsQueue.get(0)); 

else break; 

} 

return (behaviourRequestsQueue.size()>0); 

} 

Riquadro 11 : ThreadDispatcher::RequestsManager.thereIsAPendingThread() 

2. Se l'assegnazione non può essere portata a termine (perché al momento non vi 

sono Scheduler con compiti disponibili), i pendingThread vengono comunque 

mantenuti attivi per utilizzi futuri ed affidati al ReadyThreadsManager [par. 5.2.5 

ReadyThreadsManager]. Quando, al contrario, un thread trova uno Scheduler 

disponibile è effettivamente pronto per l'esecuzione ed è detto (in questo 

contesto) "readyThread". 

Per quanto concerne le richieste provenienti dagli Scheduler, la condizione normale 

prevederebbe che, una volta esaminata la richiesta il ThreadDispatcher procedesse 

direttamente alle operazioni di scheduling, sennonché il meccanismo adottato 

concede allo Scheduler massima libertà di azione fino a che il ThreadDispatcher non


effettua l'effettivo controllo sulla disponibilità di Behaviour dello Scheduler stesso: se, 

nel lasso di tempo intercorrente tra la segnalazione, da parte dello Scheduler, della 

presenza di Behaviour da schedulare ed il controllo della loro effettiva disponibilità, 

dovessero cambiare le condizioni dello Scheduler (Es. se il Behaviour pronto per 

l'esecuzione venisse cancellato e non ve ne fossero altri), allora la richiesta di 

scheduling potrebbe essere infondata e dovrebbe essere scartata. Gli Scheduler 

restanti vengono designati come "readyScheduler" [Riquadro 12]. 

public synchronized boolean thereIsAReadyScheduler() 

{ 

while(schedulingRequestsQueue.size()>0) 

{ 

Scheduler theScheduler= 

(Scheduler)schedulingRequestsQueue.get(0); 

if(theScheduler.hasNothingToSchedule()) 

removeSchedulingRequest(theScheduler); 

else break; 

} 

return (schedulingRequestsQueue.size()>0); 

} 

Riquadro 12 : ThreadDispatcher::RequestsManager.threreIsAReadyScheduler() 

Si ricorda che la politica adottata per lo Scheduler prevede che un Behaviour diventi 

"running" (e quindi certo di una sua esecuzione a meno di eventi catastrofici) 

unicamente a seguito di una chiamata diretta a schedule() o ad 

hasNothingToSchedule() [par. 5.3.5 Scheduling: notifiche, ispezioni, richieste e 

terminazione]. 

I metodi riguardanti le richieste di scheduling si occupano inoltre di notificare allo 

Scheduler richiedente l'avvenuta presa in considerazione (o meno) della loro 

chiamata: questo evita possibili blocchi dello Scheduler dovuti al meccanismo di 

notifica adottato [par. 5.3.5.2 Richieste di scheduling]. 

Infine i metodi remove() e removeAll() sono stati inseriti per essere usati in fasi 

collegate con il blocco delle attività del ThreadDispatcher: eliminano una o più 

richieste mantenendo la coerenza dello stato degli oggetti client.

Implementazione di riferimento - Scheduler 83 

5.3 Scheduler 


Lo scheduler è l'entità preposta alla selezione della sequenza d'esecuzione dei 

Behaviour. 

ParallelScheduler 

Amministra il loro life-cycle occupandosi di collocarli opportunamente in liste interne 

che ne rispecchiano lo stato e gestendo direttamente l'esecuzione di azioni quali 

block(),restart() ed affini. Dialoga da un lato con l'utente (o chi per lui) che gli da in 

consegna i Behaviour o ne richiede l'eliminazione, dall'altro con il ThreadDispatcher 

che ne chiama le funzioni di scheduling. È dipendente dal sistema run-time di JADE 

per le operazioni di risveglio temporizzato dei Behaviour e per la notifica dell'arrivo di 

nuovi messaggi (che causa il risveglio di tutti i Behaviour affidatigli). 

Le sue funzionalità possono essere suddivise in: 

1. Affidamento e rimozione di Behaviour 

2. Blocco e risveglio di Behaviour 

Scheduler 

SequentialScheduler FSMScheduler 

Diagramma 34 : UML Class Diagram di Scheduler e classi derivate 

3. Scheduling: notifiche, ispezioni, richieste e terminazione 

4. Amministrazione dei cambiamenti di stato dei Behaviour


5. Cambiamenti di stato imposti ai Behaviour dall'esterno 

5.3.2 La classe astratta 

Diagramma 35 : UML Class Diagram di Scheduler 

Scheduler 

+ Scheduler(td : TimerDispatcher) : Scheduler 

+ Scheduler(cb : CompositeBehaviour) : Scheduler 

+ add(b : Behaviour) : boolean 

+ remove(b : Behaviour) : boolean 

+ removeAll(b : Behaviour) : boolean 

+ restartLater(b : Behaviour, millis : long) 

+ notifyRestarted(b : Behaviour) 

+ doTimeout(t : Timer) 

+ notifySchedulingRequestProcessed() 

+ hasNothingToSchedule() : boolean 

# check() : boolean 

+ schedule() : Behaviour 

# choose() : Behaviour 

+ notifyExecuted(b : Behaviour) 

+ notifyInterrupted(b : Behaviour) 

+ restartAll() 

+ reset(expiration : long) 

+ hasTerminated() : boolean 

Le suddette funzioni, comuni ad ogni tipologia di scheduler, sono state implementate 

in una classe base astratta, priva di politiche decisionali per la scelta dell'ordine e 

delle modalità d'attivazione dei Behaviour. Le sue sottoclassi concrete hanno il 

compito di colmare la lacuna implementando specifici metodi. 

5.3.3 Affidamento e rimozione di Behaviour 

L'utente che desidera l'esecuzione di un dato Behaviour, precedentemente 

istanziato, da parte di un agente, passa a questo un puntatore a tale oggetto. L'Agent 

a sua volta inserisce ed affida il Behaviour al suo top-Scheduler che si occupa di


gestirlo ed interagire con il ThreadDispatcher opportuno per la sua effettiva 

esecuzione. 

Il metodo add() consente questo tipo di affidamento. Lo scheduler controlla innanzi 

tutto lo stato del Behaviour passatogli e lo memorizza nell'opportuna lista [Riquadro 

28]. 

public synchronized boolean add(Behaviour b) 

{ 

boolean result=false; 

if(result=!b.done()) 

{ 

pushIn(b); 

if(b.isRunnable()) addToReadyBehaviours(b); 

else blockedBehaviours.add(b); 

} 


} 

Riquadro 13 : Scheduler.add() 

Uno scheduler incapsula al suo interno tre liste di Behaviour per distinguerne ed 

amministrarne lo stato; vi è inoltre un contatore dei Behaviour terminati per la 

determinazione di particolari condizioni di terminazione dello scheduler stesso. 

Un Behaviour, dal punto di vista dello scheduler, può essere: 

1. Ready, quando, con riferimento a metodi proprietari di un Behaviour, 

isRunnable()==true, done()==false e risulta quindi pronto per una possibile 

esecuzione. 

2. Running, quando un ready viene schedulato e riservato da un ThreadDispatcher 

per l'esecuzione. Il Behaviour rimane in questo stato da quando viene "prenotato 

per lo scheduling" fino al suo ritorno da una sessione d'esecuzione (che può 

implicare una completa esecuzione su un thread, la sua interruzione durante 

l'esecuzione, o l'arrivo di particolari richieste ancora prima che il Behaviour sia 

effettivamente passato al ThreadDispatcher). 

3. Blocked, quando isRunnable()==false. 

4. Terminated, quando done()==true.


Si ricorda che lo stato di un Behaviour è esaminato o prima della sua esecuzione, o 

immediatamente dopo il suo ritorno da una sessione d'esecuzione, ma non durante: 

una chiamata a Behaviour.block() all'interno di action() non ha effetto immediato, ma 

viene eseguita appena si ha un ritorno del controllo. 

L'inserimento di un nuovo Behaviour in uno scheduler implica una serie di operazioni 

d'amministrazione e regolazione di parametri del Behaviour stesso che è nascosta al 

progettista, quali passaggio di riferimenti allo scheduler amministrante e, per i 

CompositeBehaviour, passaggio di riferimenti al sistema run-time, ThreadDispatcher 

e gestione della gerarchia di Behaviour. 

5.3.3.1 Behaviour duplicati 

Uno scheduler-base consente che gli siano affidati duplicati di Behaviour che già 

contiene nelle sue liste: se istanzio b1 e lo aggiungo più volte allo scheduler, questo 

mantiene separati i differenti riferimenti all'interno delle sue strutture, come se si 

trattasse di istanze diverse. 

Questa possibilità è stata lasciata per scopi particolari del SequentialScheduler: 

inserendo più riferimenti allo stesso Behaviour in tale Scheduler, e facendo in modo 

che il suo metodo onEnd() chiami reset(), si possono creare ripetizioni controllate 

dello stesso comportamento. 

I riferimenti duplicati per uno stesso Behaviour devono essere amministrati 

adeguatamente: dal momento che si riferiscono allo stesso oggetto, devono tutti 

seguirne l'evoluzione, inoltre lo scheduler deve evitare di schedulare un riferimento 

duplicato mentre ve n'è già un altro in esecuzione. 

Ipotizzando una situazione iniziale in cui tutti i riferimenti siano nella lista dei ready, lo 

scheduling di uno di questi comporta il suo passaggio tra i running (ed il vincolo per 

gli altri a non poter essere eseguiti); se al ritorno dall'esecuzione il Behaviour diventa 

blocked, tutti i suoi duplicati vengono spostati di conseguenza; quando un blocked 

duplicato viene riattivato, tutte le copie vengono trasferite nuovamente tra i ready; se 

al suo ritorno da un'esecuzione il behaviour ha terminato (e non esegue nel corpo di 

onEnd() chiamate che ne ripristino lo stato a runnable) e deve lasciare lo scheduler, 

tutti i duplicati devono fare lo stesso.


Gli stati possibili per la collocazione dei duplicati all'interno delle liste risultano quindi: 

?? Tutti i duplicati sono tra i ready 

?? Al più un duplicato è tra i running ed i restanti sono tra i ready 

?? Tutti i duplicati sono tra i blocked 

Per quanto riguarda la rimozione di Behaviour da uno scheduler, vista la presenza di 

duplicati, esistono due metodi distinti: remove(), che elimina un solo riferimento del 

Behaviour che gli è passato come parametro, e removeAll() che li elimina tutti 

(scheduler specifici, come SequentialScheduler ne affiancano ulteriori) [Riquadro 14]. 

public synchronized boolean removeAll(Behaviour b) 

{ 

boolean result=contains(b); 

if(result) 

{ 

if(runningBehaviours.contains(b)) 

{ 

if(!removedWhileRunningBehaviours.contains(b)) 

removedWhileRunningBehaviours.add(b); 

while(readyBehaviours.remove(b)); 

} 

else 

{ 

if(blockedBehaviours.remove(b)) 

{ 

while(blockedBehaviours.remove(b)); 

removePendingTimer(b); 

} 

else 

while(readyBehaviours.remove(b)); 

pullOut(b); 

} 

} 


} 

Riquadro 14 : Scheduler.removeAll() 

5.3.4 Blocco e risveglio di Behaviour 

Quando all'interno di una action() un Behaviour invoca il metodo block(), al suo 

ritorno dal quanto d'esecuzione, è lo scheduler che si occupa di spostare il suo 

riferimento nella lista dei blocked ed amministrarne il risveglio.


Se si è trattato di una sospensione temporizzata, tramite chiamata di block(millis), dal 

corpo del metodo stesso, viene invocato restartLater() dello scheduler che, 

interagendo con il TimerDispatcher del sistema run-time dell'Agent, predispone un 

timer e tiene traccia del fatto. La scadenza del timer innescato provocherà poi 

l'esecuzione del metodo doTimeout() che si occuperà del risveglio. Se il Behaviour 

viene riattivato per altre cause, un'invocazione di notifyRestarted() provvederà al 

necessario passaggio di lista ed alla rimozione del timer pendente. 

5.3.5 Scheduling: notifiche, ispezioni, richieste e terminazione 

Il meccanismo adottato per lo scheduling consiste in due metodi principali: 

hasNothingToSchedule() e schedule(). Il primo effettua un controllo e restituisce true 

se lo scheduler non ha Behaviour da eseguire (per essere più precisi, restituisce true 

solo se un'analoga chiamata a schedule() ritorna null), il secondo ritorna un 

riferimento al Behaviour da eseguire o null se non vi sono le condizioni per 

l'esecuzione. 

I vincoli per la restituzione di un riferimento valido ad un Behaviour sono diversi. 

Scheduler restituisce null se: 

?? La lista dei Behaviour ready è vuota 

?? La lista dei ready non è vuota, ma vincoli di sequenzialità impediscono che un 

Behaviour vada in esecuzione prima che il precedente sia ritornato( 

SequentialScheduler) 

?? La lista non è vuota, ma vi sono solo riferimenti duplicati ad un Behaviour già in 

esecuzione 

?? Lo scheduler sta effettuando un'operazione di reset [par. 5.3.7 Cambiamenti di 

stato imposti ai Behaviour dall'esterno] e nuovi Behaviour non possono essere 

eseguiti prima che lo stato interno ritorni consistente 

?? Lo scheduler ha raggiunto la condizione di terminazione (che dipende dalla 

sottoclasse concreta) 

Il metodo hasNothingToSchedule() non implementa un semplice controllo, ma 

effettua anche una sorta di "prenotazione" del Behaviour. Una chiamata al metodo


comporta, infatti, l'invocazione di schedule() e la memorizzazione, in una variabile 

interna, del prossimo Behaviour da schedulare che sarà passato all'invocante 

(solitamente il ThreadDispatcher) al successivo ricorso a schedule() [Riquadro 15] 


public synchronized boolean hasNothingToSchedule() 

{ 

if(nextToSchedule==null) 

nextToSchedule=schedule(); 

return (nextToSchedule==null); 

} 

Riquadro 15 : Scheduler.hasNothingToSchedule() 

Questo sistema permette di incapsulare tutte le politiche relative alla disponibilità di 

Behaviour per l'esecuzione all'interno del metodo schedule() evitando di duplicare 

controlli in hasNothingToSchedule(). In realtà schedule si occupa solo della gestione 

del Behaviour prescelto per l'esecuzione, ma la scelta è effettuata dal metodo 

protected choose() che ogni sottoclasse concreta deve implementare.


Una volta che choose() ha scelto il Behaviour, schedule() provvede a spostarlo tra i 

running e ad effettuare eventuali operazioni di inizializzazione specificate nel suo 

metodo onStart() (previa ispezione di yetStarted() che ritorna true se il Behaviour non 

ha ancora eseguito la sua prima action()) [Riquadro 16]. 

public synchronized Behaviour schedule() 

{ 

Behaviour b=null; 

if(!hasTerminated()) 

{ 

if(nextToSchedule!=null) 

{ 

b=nextToSchedule; 

nextToSchedule=null; 

} 

else 

{ 

if(!resetting) 

if((b=choose())!=null) 

{ 

readyBehaviours.remove(b); 

runningBehaviours.add(b); 

if(!b.yetStarted()) b.onStart(); 

} 

} 

} 

return b; 

} 

Riquadro 16 : Scheduler.schedule() 

5.3.5.1 Ispezioni non modificative 

Quando il metodo schedule() viene chiamato (direttamente od indirettamente tramite 

hasNothingToSchedule()), e con lui eventualmente choose(), queste chiamate 

possono comportare modifiche allo stato interno dello scheduler: il puntatore al 

prossimo Behaviour da schedulare può venire aggiornato e lo scheduler crede che il 

Behaviour restituito dalla chiamata sia in procinto di essere eseguito. 

Queste modifiche possono essere indesiderate se si vuole solamente controllare la 

"disponibilità" di Behaviour; nasce quindi la necessità di introdurre metodi interni che 

effettuino tale verifica senza apportare modifiche ai puntatori delle liste. Questi


metodi, sviluppati per scopi interni [par. 5.3.5.2 Richieste di scheduling], dovrebbero 

essere nascosti all'utilizzatore, ma, avendo separato le politiche decisionali all'interno 

di choose(), di possibile competenza del programmatore, e potendo essere 

anch'esso modificativo, si è reso necessario introdurre il metodo astratto check() con 

gli stessi scopi di choose(), ma non modificativo, che deve essere implementato dalle 

sottoclassi. 

5.3.5.2 Richieste di scheduling 

Uno scheduler, per l'esecuzione dei Behaviour, è strettamente dipendente da un 

ThreadDispatcher. È questo oggetto che svolge un ruolo attivo nella comunicazione, 

interrogando lo scheduler sulla disponibilità di Behaviour, utilizzando 

hasNothingToSchedule()) ed eventualmente richiedendoli attraverso schedule(). 

Il metodo hasNothingToSchedule(), come già detto, effettua una prenotazione del 

Behaviour, che agli occhi dello scheduler appare già running anche se sarà 

consegnato al ThreadDispatcher solo dopo una chiamata a schedule(). 

Questo protocollo è stato adottato per evitare che lo scheduler cambiasse stato tra 

un'interrogazione e la successiva richiesta. Se hasNothingToSchedule() non 

effettuasse la prenotazione, spostando il Behaviour tra i running, un remove() che si 

inserisse tra la sua chiamata e quella a schedule() potrebbe eliminare il Behaviour 

ready e lasciare il ThreadDispatcher, precedentemente convinto del contrario, senza 

compito. 

Il meccanismo delle richieste è complicato anche dal fatto che un ThreadDispatcher 

può gestire più di uno scheduler e quindi non è legato ad uno in particolare. Per 

questo motivo, non è il ThreadDispatcher che interroga direttamente il suo personale 

scheduler, ma ogni scheduler, legato ad un solo ThreadDispatcher, gli segnala 

quando dovrebbe essere ispezionato. 

Il protocollo è il seguente: 

1. Ogni scheduler, dopo che un'operazione potrebbe averne modificato lo stato, 

controlla la propria disponibilità di Behaviour (usando i metodi per le ispezioni non 

modificative [par. 5.3.5.1 Ispezioni non modificative])


2. Nel caso vi siano Behaviour pronti per essere schedulati, e non si sia già 

segnalata la cosa, si provvede ad avvisare il ThreadDispatcher [par. 5.3.5.2 

Richieste di scheduling] 

3. Il ThreadDispatcher, processata la richiesta, effettua il suddetto ciclo di ispezione 

ed acquisizione del Behaviour. 

Questo protocollo evita che il ThreadDispatcher debba conoscere esplicitamente, e 

mantenere una lista, degli scheduler che si appoggiano ad esso, e debba effettuare 

cicli attivi di interrogazioni su di essi (polling). 

Si vuole precisare, però, che la richiesta d'interrogazione effettuata dallo scheduler, 

non implica che, al momento in cui questa sarà effettuata, lo scheduler abbia ancora 

Behaviour disponibili: nel tempo intercorrente tra segnalazione ed ispezione lo 

scheduler è libero di cambiare stato ed è quindi compito del ThreadDispatcher filtrare 

queste "richieste a vuoto" [par. 5.2.6 RequestsManager]. 

Quando un ThreadDispatcher processa una richiesta di uno scheduler, deve inoltre 

segnalare a questo di averlo fatto, per dare la possibilità che nuove auto-ispezioni 

possano generare le opportune notifiche [punto 2]: questo avviene usando il metodo 

notifySchedulingRequestProcessed(). 

5.3.5.3 Terminazione del compito di uno scheduler 

Uno scheduler può avere assegnata una condizione di terminazione che varia a 

seconda del tipo specifico di sottoclasse implementata: un SequentialScheduler, ad 

esempio, termina quando ha finito di schedulare tutta la lista dei suoi Behaviour, un 

top-Scheduler dovrebbe terminare solo insieme all'Agent che lo possiede, etc.. 

In Scheduler vi è un metodo astratto demandato a tale segnalazione che deve 

essere implementato dalle sottoclassi: hasTerminated(). 

5.3.6 Amministrazione dei cambiamenti di stato dei Behaviour 

Dopo che un Behaviour è stato schedulato, viene eseguito da un thread del pool 

amministrato dal ThreadDispatcher, e durante l'esecuzione della sua action() può 

invocare metodi che ne cambiano lo stato (come block()), inoltre, la conclusione di 

una action() può causare l'innesco di condizioni di terminazione del Behaviour.


Queste modifiche al Behaviour si rispecchiano nei risultati dei metodi per la sua 

ispezione, quali isRunnable(), done(), etc., e devono essere esaminate al ritorno 

dalla sessione d'esecuzione. 

Quando un Behaviour termina correttamente la sessione, un meccanismo di notifiche 

attraversa la catena di responsabilità degli oggetti coinvolti (da EmbeddedThread a 

ThreadDispatcher fino a Scheduler) ed il metodo notifyExecuted() viene infine 

invocato su Scheduler. 

Questo metodo si occupa d'ispezionare lo stato del Behaviour e gestire una corretta 

terminazione della sessione d'esecuzione: 

?? Se done()==true esegue il metodo onEnd() del Behaviour ed eventuale rimozione 

dalle liste. 

?? Se isRunnable()==false sposta il Behaviour tra i blocked 

?? Se invece isRunnable()==true reinserisce il riferimento tra i ready 

Oltre a questi comportamenti di massima, il metodo notifyExecuted() gestisce una 

serie di variabili interne per rispecchiare l'esito dell'esecuzione del Behaviour. Queste 

variabili, che sono currentExecuted, currentDone, lastExitValue e 

terminatedBehavioursCounter, servono alle implementazioni concrete della classe 

per amministrare vincoli di sincronizzazione, condizioni di terminazione e per 

indirizzare scelte interne relative alla sequenza di scheduling [Riquadro 17].


public synchronized void notifyExecuted(Behaviour b) 

{ 

if(runningBehaviours.remove(b)) 

{ 

... 

{ 

if(b.isRunnable()) 

{ 

if(b.done()) 

{ 

currentDone=true; 

lastExitValue=b.onEnd(); 

terminatedBehavioursCounter++; 

if(b.done()) 

while(readyBehaviours.remove(b)) 


pullOut(b); 

} 

else 

{ 

currentExecuted=true; 

addToReadyBehaviours(b); 

} 

} 

else 

{ 

if(restarted) 

{ 

currentExecuted=true; 

b.restart(); 

} 

else 

{ 

blockedBehaviours.add(b); 

while(readyBehaviours.remove(b)) 

blockedBehaviours.add(b); 

if(blockCondition()) owner.blockAndNotifyUp(); 

} 

} 

} 

notify(); 

checkAndRequest(); 

} 

} 

Riquadro 17 : Scheduler.notifyExecuted() amministrazione cambiamenti interni a Behaviour 

Altro compito svolto dal metodo è il controllo di situazioni che comportano il blocco di 

un CompositeBehaviour: quando uno scheduler è demandato all'amministrazione dei 

sub-behaviour affidati ad un CompositeBehaviour, il blocco di un sub-behaviour può


causare l'arresto del Behaviour contenitore (perché ad esempio tutti i Behaviour 

affidatigli risultano blocked), e questo deve essere segnalato. 

Il metodo si occupa anche di amministrare quei cambiamenti che vengono richiesti 

dall'esterno mentre un Behaviour è in esecuzione, quali remove(), reset() e restart(), 

e quindi non possono essere effettuati immediatamente, ma devono attendere il 

ritorno della action() [par. 5.3.7 Cambiamenti di stato imposti ai Behaviour 

dall'esterno] [Riquadro 18]. 

public synchronized void notifyExecuted(Behaviour b) 

{ 

if(runningBehaviours.remove(b)) 

{ 

currentDone=false; 

currentExecuted=false; 

boolean removed=removedWhileRunningBehaviours.remove(b); 

boolean resetted=resettedWhileRunningBehaviours.remove(b); 

boolean restarted=restartedWhileRunningBehaviours.remove(b); 

if(removed) 

{ 

if(b.done()) 

{ 

currentDone=true; 

lastExitValue=b.onEnd(); 


} 

else if(b.isRunnable()) currentExecuted=true; 

else removePendingTimer(b); 

pullOut(b); 

} 

else if(resetted) 

{ 

if(b.done()) b.onEnd(); 

b.reset(); 

addToReadyBehaviours(b); 

} 

... 

} 

} 

Riquadro 18 : Scheduler.notifyExecuted() amministrazione cambiamenti a Behaviour in fase 

d'esecuzione 

Questi cambiamenti sono amministrati con una politica a priorità, nel caso si 

verificassero più richieste contemporaneamente durante l'esecuzione del Behaviour.


La priorità è data nell'ordine, cominciando dall'operazione più "forte", a remove(), 

seguito da reset() e restart(): questo vuol dire che, ad esempio, se ad un Behaviour 

running arriva sia la richiesta di restart(), sia un remove(), il Behaviour viene 

comunque eliminato dallo scheduler. 

Oltre ad una terminazione normale della sessione d'esecuzione, lo scheduler deve 

far fronte correttamente anche a quelle situazioni in cui il Behaviour subisce 

un'interruzione. Per amministrare tale evenienza, si ricorre ad un altro tipo di notifica 

che funziona similmente a notifyExecuted(), ma ha necessariamente comportamenti 

differenti: il metodo è notifyInterrupted(). 

5.3.7 Cambiamenti di stato imposti ai Behaviour dall'esterno 

Oltre alle modifiche dello stato di un Behaviour che possono avvenire durante 

l'esecuzione del metodo action() dello stesso, vi sono una serie di cambiamenti che 

possono essere innescati da eventi esterni. 

Mentre non si hanno problemi quando questi riguardano Behaviour che al momento 

della chiamata non sono in esecuzione, ma mantengono solamente il loro riferimento 

all'interno delle liste dello scheduler, diversa è la situazione quando tali cambiamenti 

devono essere notificati a Behaviour che stanno eseguendo la loro action(). 

Come avviene con i metodi notifyExecuted() e notifyInterrupted(), le modifiche 

possono avvenire solamente al ritorno dalla sessione d'esecuzione. Per questo 

motivo, all'interno dello scheduler, esistono alcune liste con lo scopo di tenere traccia 

dei cambiamenti che sono stati richiesti esternamente su Behaviour running, in modo 

da poterli eseguire quanto prima: quando un Behaviour termina il proprio quanto 

d'azione e viene chiamato l'opportuno metodo di notifica, queste liste sono esaminate 

ed i cambiamenti richiesti vengono attuati. 

Gli eventi considerati sono: 

1. Rimozione di un Behaviour 

2. Riattivazione di un Behaviour 

3. Reset di un Behaviour 

Queste situazioni sono amministrate al di fuori del Behaviour in quanto possono 

essere richieste, in qualche modo, direttamente allo scheduler. Il caso del remove() è


banale: l'agente che vuole eliminare un proprio comportamento deve passare 

attraverso il proprio scheduler per ottenerlo (come per l'inserimento ad opera di 

add()). Il metodo remove(), quando si accorge che il Behaviour da eliminare è 

attualmente in esecuzione, invece di interromperlo bruscamente, inserisce la 

richiesta in una lista (se non l'ha già fatto) e ritorna demandando a notifyExecuted() 

l'attuazione del comando. 

Le situazioni rimanenti accadono in casi particolari. 

JADE richiede che, quando arriva un nuovo messaggio, l'Agent provveda al risveglio 

di tutti i suoi Behaviour blocked, in modo che questi possano eventualmente 

controllare se il messaggio è di loro pertinenza o meno, ed in questo caso bloccarsi 

nuovamente. Questo tipo di restart è effettuato passando attraverso la gerarchia 

degli scheduler (che si snoda passando per i CompositeBehaviour) e con 

l'invocazione, su ognuno di questi, del metodo restartAll(). La segnalazione, che 

potrebbe in apparenza essere inoltrata solo ai Behaviour blocked, riguarda in realtà 

anche i running: se un Behaviour running chiama il metodo block() durante l'action(), 

il suo stato viene cambiato in blocked solo al ritorno da questa ed un'eventuale 

restartAll() che avvenisse in tale condizione andrebbe perso, lasciando il behaviour 

bloccato anche se un messaggio che potrebbe riguardarlo è giunto all'agente 


public synchronized void restartAll() 

{ 

Collection subSchedulers=getSubSchedulers(); 

Iterator i=subSchedulers.iterator(); 

while(i.hasNext()) 

{ 

Scheduler s=(Scheduler)i.next(); 

s.restartAll(); 

} 

i=blockedBehaviours.iterator(); 


{ 

Behaviour b=(Behaviour)i.next(); 

b.restart(); 

} 

restartedWhileRunningBehaviours=new LinkedList(runningBehaviours); 

} 

Riquadro 19 : Scheduler.restartAll()


I problemi con il reset si verificano invece quando il metodo viene chiamato su un 

CompositeBehaviour. In tale situazione il Behaviour contenitore deve eseguire 

reset() su ogni sub-behaviour. Mentre per i casi precedenti l'operazione poteva però 

essere asincrona, un reset() su un CompositeBehaviour non può dirsi effettuato 

finché non inoltrato su ogni Behaviour contenuto ed il mancato rispetto di tale vincolo 

può creare problemi d'inconsistenza. Se, ad esempio, un SequentialBehaviour riceve 

un reset(), questo deve riportare la sua lista nello stato iniziale e ricominciare con 

l'esecuzione del primo sub-behaviour; se il primo sub-behaviour era, però, già in 

esecuzione e non ha ricevuto il reset, tale Behaviour non ricomincia dallo stato 

iniziale, ma da uno stato già modificato, inficiando il comando impartito al 

CompositeBehaviour. 

Per evitare queste situazioni il comando di reset di uno scheduler ha diversi 

accorgimenti: 

1. È dotato di una deadline, ovvero di un termine massimo entro cui deve essere 

portato a termine 

2. Modifica lo stato dello scheduler in modo che durante la sua esecuzione non 

possano essere effettuate richieste di scheduling (schedule() ritorna null)


La deadline è perentoria: se al suo scadere i Behaviour che erano running non sono 

tutti ritornati (eseguendo quindi il reset()), lo scheduler ne forza il ritorno 

interrompendoli [Riquadro 20]. 

public synchronized void reset(long expiration) 

{ 

Deadline.checkExpiration(expiration); 

resetting=true; 

Behaviour b; 

List readyAndBlocked=new LinkedList(readyBehaviours); 

readyAndBlocked.addAll(blockedBehaviours); 

Iterator i=readyAndBlocked.iterator(); 


{ 

b=(Behaviour)i.next(); 

b.reset(); 

} 

terminatedBehavioursCounter=0; 

resettedWhileRunningBehaviours=new LinkedList(runningBehaviours); 

stopRunningBehaviours(expiration); 

lastExitValue=0; 

currentDone=false; 

currentExecuted=false; 

resetting=false; 

checkAndRequest(); 

} 

Riquadro 20 : Scheduler.reset() 

Questo tipo di forzatura causa diverse piccole modifiche di sincronizzazione al 

sistema, per tenere conto di situazioni particolari, ma il dettaglio raggiunto esula da 

questa trattazione e si consiglia la visione del codice per spiegazioni a riguardo. 

5.3.8 Sottoclassi Concrete 

L'intera amministrazione dei Behaviour è affidata ai metodi della classe base astratta. 

Le sue specificazioni concrete si occupano dell'implementazione dei metodi 

concernenti la scelta dell'ordine di schedulazione dei Behaviour loro affidati. I metodi 

in questione sono choose(), check() ed hasTerminated().Oltre a questi, che devono 

essere implementati obbligatoriamente, alcune sottoclassi, estendono, 

sovrascrivendoli richiamando il metodo della superclasse ed aggiungendo codice

Implementazione di riferimento - Gestione delle interruzioni 100 

specifico, alcuni metodi già implementati in Schedule ed aggiungendone di nuovi per 

scopi specifici. Le politiche dei sub-scheduler sono le stesse delle rispettive 

sottoclassi di CompositeBehaviour e le implementazioni sono generate sulla falsa 

riga di questi. 

Si ricorda che il metodo check() è la versione non modificativa di choose(), che si 

occupa della selezione del Behaviour, mentre hasTerminated() racchiude la 

condizione di terminazione dello scheduler (ed è quindi equivalente ad 

un'interrogazione di done() sul CompositeBehaviour() corrispondente). 

Le sincronizzazioni presenti negli scheduler Sequential e FSM si basano sui valori 

delle variabili di stato currentDone e currentExecuted modificate al ritorno delle 

sessioni d'esecuzione dal metodo Scheduler.notifyExecuted(). 

5.4 Gestione delle interruzioni 

Oltre a situazioni normali, nelle quali il ciclo d'esecuzione di un Behaviour procede 

senza problemi passando dallo Scheduler, al ThreadDispatcher, 

all'EmbeddedThread, per poi ripercorrere all'indietro la catena, notificando la corretta 

terminazione della action() ed occupandosi del mantenimento del requisito di 

coerenza dei moduli coinvolti, vi sono situazioni nelle quali un thread può subire, 

volontariamente o no, un'interruzione, evento che può accadere anche mentre è in 

corso l'esecuzione del metodo action() di un Behaviour. 

Questa situazione eccezionale deve comunque essere gestita dal sistema in modo 

da non causare errori irrecuperabili che possano compromettere l'esecuzione di altri 

Behaviour o dell'intero Agent. 

5.4.1 Catena ascendente 

Come avviene per le notifiche di corretta terminazione, il sistema prevede una catena 

di notifiche anche nell'eventualità di un'interruzione di thread. Il meccanismo parte da 

EmbeddedThread e si propaga passando dal ThreadDispatcher per arrivare allo 

Scheduler competente.


Nell'eventualità prospettata, EmbeddedThread, che incapsula il thread d'esecuzione, 

chiama notifyInterrupted() sul ThreadDispatcher che lo amministra in modo che 

possa aggiornare i riferimenti contenuti nelle sue liste. Se l'interruzione avviene su un 

thread ready, basta eliminare il suo riferimento dalla lista dei readyBehaviours, ma 

quando il thread è running le cose si complicano. 

Dato che l'interruzione può avvenire sia mentre l'action() viene eseguita, sia mentre il 

thread è "sospeso" in attesa d'istruzioni, il ThreadDispatcher deve discriminare tra i 

due casi. Quando un EmbeddedThread sospeso viene interrotto, questo ha già 

effettuato una richiesta per avere un nuovo Behaviour (chiamando 

requestBehaviour()) ed il ThreadDispatcher l'ha memorizzata: basta esaminare la 

coda delle richieste per scoprire se l'action() è stata interrotta o no [Riquadro 21]. 

public synchronized void notifyInterrupted(EmbeddedThread et) 

{ 

if(readyThreads.contains(et)) readyThreads.remove(et); 

else if(runningThreads.remove(et)) 

{ 

if(requests.contains(et)) 

{ 

requests.remove(et); 

notify(); 

} 

else 

{ 

Behaviour b=et.getBehaviour(); 

Scheduler s=(Scheduler) associationBS.remove(b); 

notify(); 

s.notifyInterrupted(b); 

} 

} 

} 

Riquadro 21 : ThreadDispatcher.notifyInterrupted() 

Nel caso l'esecuzione del Behaviour sia stata interrotta, il ThreadDispatcher 

provvede a passare la notifica allo scheduler interessato: da un mapping interno tra 

Behaviour e Scheduler, creato in fase di dispatching, viene recuperato lo scheduler 

proprietario del Behaviour e su questo s'invoca Scheduler.notifyInterrupted() che


provvede a gestire la situazione [par. 5.3.6 Amministrazione dei cambiamenti di stato 

dei Behaviour]. 

5.4.2 Catena discendente 

L'amministrazione di queste notifiche è particolarmente delicata per il sistema, in 

quanto bidirezionale: oltre alla catena ascendente sopra descritta, nella quale 

l'interruzione è considerata un evento indesiderato causato dall'esterno, vi è 

parallelamente una catena discendente, nella quale sono gli stessi moduli del 

sistema a causare volontariamente l'interruzione dei Behaviour. Questa catena, nella 

quale ogni modulo a monte sfrutta le competenze di quello a valle, si verifica a 

seguito di operazioni di terminazione delle attività, come ad esempio reset() e 

stopRunningBehaviour() di Scheduler [par. 5.3.7 Cambiamenti di stato imposti ai 

Behaviour dall'esterno], o stop() e stopRunningThreads() di ThreadDispatcher [par. 

5.2.3 Dispatching e gestione dei thread]. 

Questi metodi possono ritornare solo una volta che hanno avuto la certezza che le 

interruzioni siano andate a buon fine: devono attendere l'arrivo delle notifiche. Così 

facendo, richieste e notifiche possono annidarsi. Questo comporta la creazione di un 

meccanismo di sincronizzazione sviluppato a livello di ogni modulo ma che 

garantisca anche la correttezza di tutta la catena: non si può sapere anticipatamente 

da quale modulo parta la richiesta d'interruzione, se da Scheduler, da 

ThreadDispatcher o per cause esterne, ma il meccanismo deve funzionare 

ugualmente evitando sia problemi di deadlock, sia mantenendo la coerenza di ogni 

modulo [Riquadro 22].


private synchronized int interruptRunningThreads() 

{ 

int notInterrupted=0; 

EmbeddedThread et; 

Iterator i=runningThreads.iterator(); 


{ 

et=(EmbeddedThread)i.next(); 

if(requests.contains(et)) 

{ 

requests.remove(et); 

runningThreads.remove(et); 

readyThreads.add(et); 

} 

else if(!et.interrupt()) notInterrupted++; 

} 

try 

{ 

while(runningThreads.size()>notInterrupted) wait(); 

} 

catch(InterruptedException ie) {} 

return notInterrupted; 

} 

Riquadro 22 : ThreadDispatcher.interruptRunningThreads() 

Se Scheduler.stopRunningBehaviour() si affida per la sua esecuzione a 

ThreadDispatcher.stopRunningThreads(), quando quest'ultimo ritorna, lo stato di 

ThreadDispatcher deve essere coerente (devono essere già arrivate tutte le notifiche 

d'interruzione) e le eventuali chiamate a Scheduler.notifyInterrupted() devono già 

essere state effettuate. 

All'interno dei metodi che richiedono l'interruzione [Riquadro 22] si può, infatti, notare 

la presenza di chiamate a wait() sul monitor dell'oggetto; quando poi un metodo di 

notifica d'interruzione viene invocato, nel corpo del codice, dopo che le operazioni 

per rendere coerente lo stato sono state effettuate, si procede alla segnalazione con 

notify() [Riquadro 21], e, solo dopo, all'inoltro della notifica al modulo a monte 

[Diagramma 36].


a : Agent 

stopRunningBehaviour(long) 

return from call 

s : Scheduler td : Thread 

Dispatcher 

stopRunningThreads(long) 

wait() on monitor 

notifyInterrupted(b) 

remove b from running 

notify() on monitor 

interrupt( ) 

wait() on monitor 

notifyInterrupted(et) 

remove et from running 

b:=getBehaviour( ) 

s:=get b's scheduler 

notify() to monitor 

Diagramma 36 : UML Sequence Diagram per le catene di notifica delle interruzioni 

et : 

Embedded


5.4.3 Metodi non interrompibili 

Quando si effettuano chiamate a metodi che promettono di interrompere ogni attività, 

bisogna considerare anche la possibilità che vi siano metodi non interrompibili 

[Riquadro 23] e quindi evitare che chiamate a stopRunningThreads() e simili, 

attendendo una notifica che non avverrà mai, possano causare un blocco del 

sistema. 

class UninterruptableBehaviour extends Behaviour 

{ 

public void action() 

{ 

for(;;) 

{ 

try 

{ 

for(;;) 

{ 

System.out.print('!'); 

Thread.sleep(250); 

} 

} 


{} 

} 

} 

} 

Riquadro 23 : Esempio di Behaviour non interrompibile


Per evitare tale inconveniente, il metodo interrupt() di EmbeddedThread è stato 

fornito di una deadline: se l'interruzione avviene entro tale termine, il metodo ritorna 

true, altrimenti fallisce, ma ritorna ugualmente restituendo false [Riquadro 24]. 

public boolean interrupt() 

{ 


{ 

if(threadState!=CREATED && threadState!=TERMINATED && 

threadState!=INTERRUPTED) 

{ 

threadState=ABOUT_TO_INTERRUPT; 

theThread.interrupt(); 

try 

{ 

stateLock.wait(Deadline.DEFAULT); 

} 


} 

return (threadState==INTERRUPTED); 

} 

} 

Riquadro 24 : EmbeddedThread.interrupt() 

Questo sistema di notifica della riuscita/fallimento dell'interruzione è sfruttato dai 

metodi a monte per evitare attese infinite: un contatore dei thread non interrompibili 

indica quante notifiche si devono effettivamente attendere.


5.4.4 Problemi con InterruptedException 

ThreadDeath 

Diagramma 37 : UML Class Diagram per la gerarchia delle Eccezioni di Java 

Java, come altri linguaggi di programmazione orientati agli oggetti, fornisce lo 

strumento delle eccezioni. Si tratta di un costrutto che permette di gestire 

l'insorgenza di condizioni particolari ed anomale di esecuzione, che possono 

verificarsi a run-time, in modo Object-Oriented: quando una situazione di errore viene 

rilevata è possibile interrompere il normale flusso di controllo del codice e "lanciare" 

un oggetto che lo segnali; il flusso riprende nel punto di codice in cui oggetto in 

questione viene "catturato" e tale blocco di programma si occuperà del corretto 

recupero del problema. 

Throwable 

Error Exception 

RuntimeException 

InterruptedException ArithmeticException 

La gerarchia delle eccezioni di Java prevede (oltre la classe base Throwable):


?? La classe Error: oggetti lanciati in condizioni ordinarie dallo stesso sistema 

run-time di Java che corrispondono a situazioni "catastrofiche" riguardanti il 

sistema stesso e che per questo non dovrebbero solitamente essere catturate 

(Es. OutOfMemoryError, ThreadDeath). 

?? La classe Exception: oggetti usati per segnalare condizioni particolari che 

dovrebbero essere controllate e gestite dall'applicazione. 

?? La sottoclasse di Exception RuntimeException: oggetti per situazioni ordinarie 

lanciate dallo stesso ambiente d'esecuzione (Es. ArithmeticException, 

NullPointerException). 

Mentre le eccezioni di tipo Error o RuntimeException possono essere lanciate 

all'interno di un metodo senza che questo debba dichiarare di farlo, per quanto 

riguarda la classe Exception e sottoclassi, queste devono essere obbligatoriamente 

catturate all'interno del metodo che le genera o, nel caso ciò non avvenga, ne deve 

essere data notifica nella dichiarazione del metodo stesso pena l'impossibilità di 

compilazione: tali eccezioni vengono dette "controllate".


InterruptedException fa parte della categoria delle eccezioni controllate: se viene 

lanciata all'interno di un metodo e non catturata dal metodo stesso, deve essere 

dichiarata [Riquadro 25]. 

... 

//un metodo che lancia una InterruptedException o esegue un 

//metodo che dichiara di farlo, e non la cattura internamente 

//deve dichiararla nella clausula throws 

public void throwsInterrupted() throws InterruptedException 

{ 

doesntThrowInterruptedButDeclares(); 

throw new InterruptedException(); 

} 

//un metodo che dichiara di lanciare una InterruptedException 

//non è obbligato a lanciarla veramente 

public void doesntThrowInterruptedButDeclares() 

throws InterruptedException 

{} 

... 

//Un metodo che al suo interno cattura una InterruptedException 

//deve avere nel corpo del try una chiamata che dichiara di 

//lanciarla 

public void catchInterrupted() 

{ 

try 

{ 

//se commento il blocco sottostante non posso compilare 

{ 

throwsInterrupted(); 

doesntThrowInterruptedButDeclares(); 

} 

doesntThrowInterrupted(); 

} 


} 

... 

Riquadro 25 : TestInterruptedException: prove per InterruptedException 

Il problema nasce per la particolare dichiarazione del metodo action() di Behaviour 

che non dichiara di poter lanciare tale eccezione. In condizioni normali, infatti, una 

action() è considerata non interrompibile e quindi, una volta entrati nel suo corpo 

d'esecuzione, si dovrebbe aspettare semplicemente che termini: è compito del 

programmatore fare in modo che all'interno della chiamata non si possano verificare


situazioni quali lunghi blocchi in attesa di eventi esterni, cicli infiniti o situazioni di 

deadlock che congelerebbero l'intero sistema. 

In alcuni casi è però necessario tenere conto di un'eventuale interruzione 

dall'esterno. Si supponga ad esempio che l'action() debba interrogare uno stream di 

dati: dovrà tentare una read() e questa, essendo bloccante, potrebbe causare 

situazioni di stallo tipiche del "blocco critico" se mal gestita; si deve pertanto 

considerare la possibilità di dover interrompere l'attesa e di conseguenza la action(). 

In presenza di eventi "eccezionali" come quello descritto, una buona tecnica di 

programmazione dovrebbe prevedere: 

1. Cattura dell'eccezione lanciata. 

2. Recupero dello stato interno a quello coerente più vicino temporalmente. 

3. Nuova segnalazione, alle classi che gestiscono l'oggetto, dell'eccezione avvenuta 

in modo che possano recuperare anch'essi la loro coerenza. 

L'ultimo passo richiede che action() dichiari nella sua clausola throws di poter 

lanciare InterruptedException, ma questo non avviene. Se manca il passo 3 può 

verificarsi che lo stato del Behaviour venga recuperato, ma rimanga invalidato quello 

del sistema che lo comprende (EmbeddedThread, ThreadDispatcher e Scheduler).


La classe EmbeddedThread, infatti, cattura e gestisce l'eccezione di interruzione del 

thread ed a sua volta notifica l'evento al ThreadDispatcher (per l'eliminazione dalle 

liste in esso contenute del thread interrotto). Questo, ripristinata la propria coerenza, 

provvede a rilanciare la notifica allo Scheduler competente perché possa 

amministrare la terminazione del Behaviour [Riquadro 26]. 

... 


{ 


{ 

threadState=INTERRUPTED; 

stateLock.notify(); 

} 

theThreadDispatcher.notifyInterrupted(this); 

} 

... 

Riquadro 26 : EmbeddedThread: inizio della catena di notifiche dell'interruzione del thread in 

run(). 

Problema duale, legato al fatto che InterruptedException sia controllata, è che un 

metodo che cattura un'eccezione controllata deve avere, all'interno del "blocco try": 

?? Un'esplicita clausola throw che lanci tale eccezione o 

?? Almeno un metodo che dichiari di lanciarla [Riquadro 25].

Implementazione di riferimento - Classi di utilità 112 

Per risolvere momentaneamente questo specifico problema, si è introdotto, dove 

necessario, un wrapper per la chiamata ad action() in modo che il metodo dichiari di 

lanciare InterruptedException [Riquadro 27]. 

... 

try 

{ 

theBehaviour=theScheduler.schedule(); 

actionWrapper(theBehaviour); 

theScheduler.notifyExecuted(theBehaviour); 

} 


{ 

theScheduler.notifyInterrupted(theBehaviour); 

} 

... 

private void actionWrapper(Behaviour b) throws InterruptedException 

{ 

b.action(); 

} 

... 

Riquadro 27 : ThreadDispatcher: superamento dei problemi con InterruptedException all'interno 

di dispatch(). 

Soluzione più elegante, per salvare sia la dichiarazione di action(), sia la creazione 

della catena di notifiche, sarebbe quella di creare una sottoclasse di Error 

specificatamente con lo scopo di segnalare interruzioni della action() stessa: Error e 

classi derivate non hanno l'obbligo di essere dichiarate e possono comunque essere 

catturate. Questo genere di miglioria comporterebbe alcune piccole modifiche nei soli 

punti d'ingresso delle catene di notifica, laddove invece di catturare 

InterruptedException lanciata da action() si gestirebbe il nuovo errore. 

5.5 Classi di utilità 

Alcuni costrutti, adoperati in maniera non proprietaria da più di una classe, sono stati 

separati e resi disponibili per l'utilità comune dei diversi attori. Si tratta di classi che


non corrispondono ad entità interagenti del sistema, ma forniscono strumenti da 

queste ampiamente adoperati. 

5.5.1 AssociationTimerObject 

Diagramma 38 : UML Class Diagram di AssociationTimerObject 

La classe AssociationTimerObject nasce dall'esigenza, all'interno di quelle classi che 

devono eseguire azioni temporizzate implementando l'interfaccia TimerListener 

(Scheduler e ThreadDispatcher::ReadyThreadsManager), di mantenere una 

mappatura tra i Timer degli eventi innescati ed i riferimenti agli oggetti su cui 

compiere tali azioni. 

AssociationTimerObject 

+ addPair(o : Object, t : Timer) 

+ getPeer(o : Object) : Object 

+ getNextToExpire() : Object 

+ removeMapping(o : Object) : Object 

+ size() : int 

+ contains(o : Object) : boolean 

+ getTimersIterator() : Iterator


Il meccanismo alla base di tali temporizzazioni può così riassumersi [Riquadro 28]: 

1. Creazione di un Timer e suo innesco tramite il TimerDispatcher 

2. Creazione dell'associazione tra Timer ed istanza soggetta all'operazione 

temporizzata 

3. Alla scadenza del Timer, esecuzione di doTimeout() (a cui viene passato il Timer 

invocante) 

4. Recupero dell'oggetto tramite il riferimento al suo Timer 

5. Esecuzione dell'operazione. 

... 

private AssociationTimerObject pendingTimers= 

new AssociationTimerObject(); 

... 

public synchronized void restartLater(Behaviour b, long millis) 

{ 

if(b==null) throw new IllegalArgumentException(); 

if(millis


memorizzazione dei Timer: oltre a recuperare una mappatura conoscendo il 

"compagno" dell'oggetto da cercare, è possibile ottenere direttamente l'oggetto con il 

Timer più prossimo a scadere (chiamando il metodo getNextToExpire()). 

I limiti imposti alla classe sono: 

1. Non è consentito l'inserimento di oggetti "null" 

2. Non è possibile associare un oggetto di tipo Timer ad un Timer 

3. Non sono ammessi elementi duplicati: può esistere una sola mappatura tra un 

Timer ed un Object (e viceversa) 

Per quanto riguarda le operazioni di recupero, il metodo getPeer() accetta come 

argomento un oggetto generico provvedendo a discernere i casi in cui questo sia 

istanza di Timer dagli altri ed operando appropriatamente il recupero del compagno. 

Nel caso in cui al metodo sia passato un oggetto di tipo Timer, il confronto con le 

chiavi contenute all'interno viene effettuato sfruttando equals() e compareTo(): due 

istanze diverse di Timer con identico contenuto recuperano lo stesso oggetto 


public Object getPeer(Object o) 

{ 

Object theObject=null; 

if(o!=null) 

if(o instanceof Timer) 

{ 

Timer theTimer=(Timer)o,t=null; 

Set timersSet=timerToObject.keySet(); 

Iterator i=timersSet.iterator(); 


{ 

t=(Timer)i.next(); 

if(t.equals(theTimer)) break; 

} 

if(t.equals(theTimer)) 

theObject=timerToObject.get(t); 

} 

else 

theObject=objectToTimer.get(o); 

return theObject; 

} 

Riquadro 29 : AssociationTimerObject.getPeer()


5.5.2 Deadline 

Diagramma 39 : UML Class Diagram di Deadline 

La classe Deadline è una piccola classe d'utilità il cui scopo è quello di 

standardizzare ed importare una serie di costanti da utilizzare in associazione ai 

metodi temporizzati. Definisce inoltre un metodo statico checkExpiration() con lo 

scopo di controllare che i valori passati come parametri abbiano un significato fisico e 

siano compresi nel range di validità del parametro. I nomi di metodi e variabili sono 

autoesplicativi: i valori del parametro vanno da NOW, che implica una deadline a 

scadenza immediata, a NEVER per indicare una scadenza teoricamente posta 

all'infinito. 

Il comportamento delle chiamate temporizzate varia a seconda del metodo stesso, 

ma in generale può così riassumersi: il metodo cerca di portare a termine 

l'operazione entro la deadline temporale; se così è ritorna, altrimenti può: 

1. Forzare l'operazione e la terminazione della chiamata e ritornare (come in stop() 

di ThreadDispatcher) [par. 5.2.3 Dispatching e gestione dei thread] 

2. Riportare un fallimento (come in suspend() di EmbeddedThread) [par. 5.1.4 

Transizioni temporizzate] 

Deadline 

+$ NOW : long = 0 

+$ NEVER : long = -1 

+$ DEFAULT : long = 5000 

+ Deadline(millis : long = DEFAULT) 

+ setExpiration(millis : long) 

+ getExpiration() : long 

+ checkExpiration(expiration : long) 

La classe può anche essere istanziata nei casi in cui servisse una deadline variabile 

e settabile per una data istanza [par. 5.2.5 ReadyThreadsManager].

Implementazione di riferimento - Modifiche all'ambiente 117 

5.6 Modifiche all'ambiente 

Le classi descritte finora sono state create dal nulla e non facevano 

precedentemente parte del framework. L'integrazione dei nuovi moduli con il core di 

JADE ha però richiesto diverse modifiche per quelle classi direttamente interessate 

con l'amministrazione dei Behaviour. Le modifiche necessarie, non tutte 

effettivamente realizzate, sono descritte in questo paragrafo e sono state fornite 

come estensioni delle classi chiamate in causa in modo da evitare modifiche dirette 

all'ambiente. Una volta che il modello sarà sufficientemente testato e si saranno 

risolti problemi di compatibilità con le applicazioni sviluppate precedentemente, si 

potrà procedere con l'effettiva integrazione. 

5.6.1 Behaviour 

Il passaggio di responsabilità avvenuto tra Agent e le nuove classi implementate, 

unitamente all'adozione del modello multi-threaded, hanno comportato alcune 

modifiche alla classe Behaviour che vengono qui illustrate. 

Essendo ora lo Scheduler ad occuparsi della gestione dei block() e restart(), ogni 

Behaviour, come prima aveva bisogno di un riferimento all'Agent proprietario, ora 

necessita di un riferimento allo Scheduler che lo amministra per potervi invocare 

restartLater() e notifyRestarted(): si è introdotto il metodo setScheduler() e si sono 

modificati block(millis) e restart(). 

Anche la gestione di onStart() ha subito un passaggio di managing: mentre prima era 

il Behaviour stesso ad occuparsene tramite chiamate ad actionWrapper() invece che 

action(), adesso anche questa gestione è passata allo scheduler. Il metodo 

actionWrapper() può ora essere eliminato, mentre ne è stato aggiunto uno nuovo per 

l'ispezione dello startFlag, passo necessario per conoscere se il Behaviour è alla sua 

prima esecuzione: tale metodo è yetStarted(). Anche onStart() ha subito una piccola 

modifica, in quanto ora è lui stesso che, dopo la sua esecuzione, cambia startFlag da 

true a false: estensioni di onStart() in sottoclassi dovrebbero quindi ricordarsi di 

chiamare super.onStart().


Più delicati sono i problemi di sincronizzazione degli accessi dovuti al nuovo modello 

multi-threaded: avendo a disposizione più linee d'esecuzione bisogna controllare che 

le chiamate ai metodi di Behaviour ed Agent (che possono essere invocati anche 

all'interno delle action()) siano eseguite sequenzialmente. La questione, non risolta 

nell'ambito del presente lavoro, risulta problematica in quanto non è possibile 

modificare semplicemente le definizioni dei metodi di Behaviour, poiché questa 

azione comporterebbe la modifica di parte del codice finora sviluppato da tutti gli 

utenti di JADE: è quindi necessario trovare altri sistemi (ad esempio lock interni ai 

metodi). 

5.6.2 CompositeBehaviour 

Diagramma 40 : UML Class Diagram di CompositeBehaviour e componenti 

La sottoclasse di Behaviour, CompositeBehaviour, avendo il modello implementato 

separato quelle funzioni di scheduling che erano in essa incorporate, risulta 

particolarmente modificata. 

1 

CompositeBehaviour 

1 

Scheduler ThreadDispatcher 

Il nuovo modello riduce le sue responsabilità a semplice contenitore di sub- 

behaviour, affidando allo scheduler, che deve incapsulare, la totale gestione di 

questi. Il CompositeBehaviour può, inoltre, essere dotato di un ThreadDispatcher 

1 

0..1


personale per implementare la struttura gerarchica di cui nella descrizione del 

modello [cap. 4 Modello di Concorrenza proposto]. 

Metodi come scheduleFirst(), scheduleNext(), checkTermination() e getCurrent() 

risultano ora superflui: i primi perché divenuti di competenza dello Scheduler, 

getCurrent() poiché un modello, in generale, multi-threaded non può sostenere il 

concetto di "riferimento al Behaviour attualmente in esecuzione", in quanto ve ne 

possono essere simultaneamente più di uno. Altri metodi, come done(), reset() e 

restartAllSubBehaviours() richiamano gli equivalenti presenti in Scheduler. 

Il metodo action(), che gestiva praticamente lo scheduling dei sub-behaviour, ora non 

fa altro che invocare dispatch() sul riferimento che ha al ThreadDispatcher: nel caso 

che il CompositeBehaviour non abbia un ThreadDispatcher proprio, dispatch() viene 

invocato su quello del "padre". 

Sono stati aggiunti, infine, nuovi metodi, alcuni dei quali nascosti all'utente, per 

operazioni quali la notifica dei blocchi (o risvegli) a causa di modifiche nel set di sub- 

behaviour [par. 5.3.6 Amministrazione dei cambiamenti di stato dei Behaviour] e 

l'amministrazione del ThreadDispatcher personale. 

Per fornire un CompositeBehaviour di un ThreadDispatcher, ed evitare che l'utente 

debba manipolare riferimenti a ThreadDispatcher esterni alla classe, si è creato il 

metodo provideWithAThreadDispatcher() che effettua la creazione ed inizializzazione 

del ThreadDispatcher direttamente all'interno di CompositeBehaviour: questo 

meccanismo garantisce così maggiore sicurezza e controllo sul rispetto dei vincoli 

del modello. Per le stesse ragioni, sono stati creati i metodi 

hasItsOwnThreadDispatcher(), che ritorna true nel caso un CompositeBehaviour 

abbia un ThreadDispatcher di proprietà, getTheThreadDispatcher() e 

removeTheThreadDispatcher(). Accanto a questi metodi pubblici, sono stati forniti 

(non solo all'interno di CompositeBehaviour) metodi per la navigazione della 

gerarchia di Behaviour e relativi Scheduler e ThreadDispatcher ad uso interno 

(propagazione di comandi, interrogazione sullo stato di attività dei thread di un Agent, 

etc.).


5.6.3 Agent 

Diagramma 41 : UML Class Diagram di Agent e componenti 

Il nuovo modello comporta diverse modifiche anche per la classe Agent. Queste 

sono qui solamente descritte e necessitano ancora della realizzazione. 

Agent, innanzi tutto, deve contenere uno Scheduler ed un ThreadDispatcher 

top-level. Costruttori appositi forniti con dette classi consentono un'inizializzazione 

mirata per le istanze a livello dell'Agent, passando direttamente riferimenti 

all'ambiente run-time (in particolare al TimerDispatcher) ed all'Agent contenitore. 

Dovendo, sia il top-Scheduler, sia il top-ThreadDispatcher, possedere riferimenti 

reciproci, la sequenza di creazione deve essere la seguente: prima viene creato lo 

Scheduler, passando il riferimento al TimerDispatcher, poi il ThreadDispatcher, che 

ottiene puntatori per TimerDispatcher, Agent e lo Scheduler appena creato. 

All'interno del costruttore del ThreadDispatcher si provvede, poi, ad assegnare un 

suo riferimento al top-Scheduler, chiudendo la catena. 

1 

Ora che Agent possiede riferimenti a scheduler e dispatcher, può servirsene per 

l'amministrazione dei Behaviour. 

1 

Agent 

Scheduler ThreadDispatcher 

Metodi come restartLater(), notifyRestarted() e doTimeout() diventano inutili, in 

quanto tali operazioni riguardano ora lo scheduler; così come la classe incapsulata 

AssociationTB, sostituita da AssociationTimerObject, e la sua istanza pendingTimers, 

1 

1

Implementazione di riferimento - Testing dell'implementazione 121 

anch'essa di competenza del modulo di scheduling; i metodi addBehaviour() e 

removeBehaviour() vanno invece riscritti utilizzando i corrispettivi del top-Scheduler. 

Quando Agent si trova nel suo stato ACTIVE, invece di effettuare lo scheduling ed 

amministrare direttamente i Behaviour (con i controlli per i risvegli, esecuzioni di 

onEnd(), etc.), provvede semplicemente ad invocare dispatch() sul suo 

ThreadDispatcher, ed il sistema si occuperà del resto: portare in esecuzione un 

Behaviour su un thread. 

Anche i metodi che si occupano di gestire il life-cycle dell'Agent hanno bisogno di 

modifiche. Come prima cosa devono essere sincronizzati a causa del possibile 

accesso simultaneo da parte di Behaviour in esecuzione su thread diversi. Quei 

metodi che forniscono il supporto per la mobilità, che interrompendo il thread 

dell'agente ne fermavano ogni attività, devono considerare il fatto che in un sistema 

multi-threaded questo non è più vero, e devono ricorrere agli appositi metodi forniti 

dal ThreadDispatcher [par. 5.2.3 Dispatching e gestione dei thread] (questo vale 

anche per doDelete()). 

Una precisazione va infine fatta sul tipo di scheduler da utilizzare come top-level: 

questo deve terminare solo insieme all'agente (un top-scheduler, anche se non ha 

Behaviour ready, deve avere un metodo hasTerminated() che ritorna sempre false). 

Per questo particolare scopo si è pensato alla classe ParallelScheduler con un 

apposito valore per il parametro "endCondition" pari a NEVER. 

5.7 Testing dell'implementazione 

Parallelamente allo sviluppo dell'implementazione si è provveduto anche al suo 

testing per verificarne la correttezza nelle situazioni d'uso più comuni. Questa fase ha 

portato alla creazione di una piccola "suite" di verifica, che completa il lavoro. Questo 

paragrafo si occupa di descrivere brevemente tale suite nella sua architettura. 

Tutti i sorgenti fanno parte del package Testing, e sono contenuti nell'apposita 

directory. Il modulo per l'esecuzione è la classe MainTest: all'interno del suo metodo 

main() sono effettuate le chiamate ai metodi statici test() delle diverse classi di

Implementazione di riferimento - Testing dell'implementazione 122 

testing. Agendo sul suo codice si possono commentare i test che non ci interessano, 

selezionandone solo alcuni. 

Le classi di testing sono chiamate anteponendo "Test" al nome della classe da 

testare od al tipo di operazioni verificate ("TestEmbeddedThread", "TestRaces"). 

Quando si esegue un test su una classe incapsulata dentro un'altra il nome della 

classe contenitrice precede quello della sottoclasse ("TestEmbeddedThreadMutex"). 

Le classi da testare sono state leggermente modificate per consentire le simulazioni 

necessarie e l'interfacciamento con l'ambiente simulato. 

Per avere un ambiente fittizio attorno alle classi da testare senza modificarne troppo 

il codice ed il tipo di interazioni, si sono create delle interfacce con lo stesso nome e 

metodi pubblici della classe da simulare ed implementazioni vuote che alla chiamata 

di un metodo visualizzassero semplicemente un messaggio sullo schermo. Ogni 

interfaccia e relativa implementazione vuota, chiamata con lo stesso nome seguito 

da "EmptyImpl", sono state inserite in un file con il nome della classe (es. 

"Scheduler.java" contiene l'interfaccia "Scheduler" e l'implementazione 

"SchedulerEmptyImpl"). 

Quando una classe fittizia doveva fare più che semplicemente visualizzare un 

messaggio, all'interno della classe di testing si è provveduto ad estendere 

l'implementazione vuota per gli scopi specifici: tali classi, per differenziarle l'una 

dall'altra, sono state chiamate usando le iniziali delle parole che compongono il nome 

della classe di testing (es. l'estensione di "SchedulerEmptyImpl" in 

"TestThreadDispatcherRequestsManager" ha nome "SchedulerTTDRMImpl"). 

Le reali implementazioni dei moduli sviluppati sono invece state chiamate 

aggiungendo "Impl" al nome reale; a questa regola vi sono alcune eccezioni per 

quelle classi che non devono apparire nell'ambiente simulato e che hanno quindi 

mantenuto il loro vero nome. 

Oltre alle classi facenti parte del modello, ve ne sono altre create appositamente per 

il testing: Stars che rappresenta un semplice Behaviour di prova e Timer che 

implementa una versione semplificata dell'omonima classe del package jade.core.

Conclusioni 123 

6 Conclusioni 

Il modello d'esecuzione Thread-per-Agent utilizzato da JADE, pur essendo efficiente, 

mostra i suoi limiti quando accoppiato con il modello comportamentale dei behaviour. 

In tale paradigma, nell'ambito delle abilità di composizione del modello, si 

enfatizzano strumenti che distinguono tra esecuzioni sequenziali di sub-behaviour ed 

aggregati gerarchicamente paralleli. In realtà tale concorrenza è solo virtuale in 

quanto implementata da un sistema single-threaded attraverso uno scheduling 

round-robin delle sotto-attività raggruppate. 

L'inserimento, all'interno d'ogni singolo Agent, di un vero sistema multi-threaded 

consente ad un ParallelBehaviour di essere realmente tale, e porta tutti i vantaggi ad 

esso legati: un Behaviour bloccato non ritarderà più necessariamente l'esecuzione di 

tutti gli altri, dando all'agente la possibilità di ottimizzare protocolli di comunicazione e 

reperimento di dati da fonti diverse. 

Il confronto tra architetture concorrenti già presenti in diversi prodotti, ha portato alla 

luce l'importanza di separare gli strumenti per consentire la concorrenza dai modelli 

visibili all'utente. Fondamentale è garantire internamente moduli altamente flessibili e 

parametrizzabili, per consentire maggiore elasticità nella scelta delle configurazioni a 

livello più alto. 

Nel presente lavoro si è puntato su questo concetto, creando oggetti che 

incapsulassero funzionalità ben separate dell'architettura, e che lasciassero aperte 

numerose possibilità di composizione a livello più alto. Oltre ad una classe pensata 

per isolare e gestire opportunamente i thread d'esecuzione (EmbeddedThread), si è 

provveduto ad isolare quella funzione di scheduling che ricorreva spesso nel 

modello, facendo anche tutt'uno con i CompositeBehaviour, fornendone un modello 

astratto di base che può essere specializzato secondo le esigenze (Parallel, 

Sequential, FSM, … ).

Conclusioni - Ulteriori Sviluppi 124 

Il modulo principale che gestisce le esecuzioni, non è più lo scheduler a livello 

agente, ma diventa il ThreadDispatcher, oggetto che fa incontrare Behaviour ed 

EmbeddedThread. Tale modulo amministra situazioni che vanno dal 

Single-Threaded, al Thread-per-Behaviour, passando per il Thread-Pool in maniera 

dinamica; consente di operare scelte sul life-cycle di un thread fissandone, anche a 

run-time, tempi massimi d'inattività (da zero ad infinito), condizionando quindi 

l'overhead legato ad operazioni di creazione/distruzione di thread; può gestire in 

maniera uniforme più di uno scheduler, ma anche essere istanziato più volte e 

formare, con i CompositeBehaviour e relativi Scheduler, una gerarchia modulare di 

Dispatcher, ognuno con il proprio thread-pool personale. 

6.1 Ulteriori Sviluppi 

La flessibilità ottenuta può, però, risultare di difficile gestione per categorie d'utenti 

non particolarmente interessate a preoccuparsi di dettagli tecnici. Il confronto tra 

DCOM e ORBacus ha insegnato l'importanza di fornire, accanto a strumenti 

customizzabili, la possibilità di poter scegliere tra pochi modelli, calibrati per 

determinate esigenze e di facile utilizzo, in modo che con una sola scelta si possa 

evitare di settare decine di parametri differenti. 

Un utile, e necessario, passo successivo potrebbe consistere nel fornire tali modelli 

di livello superiore, possibilmente dopo un'analisi delle esigenze più sentite dagli 

utilizzatori. 

Avendo, inoltre, separato le funzionalità essenziali dello scheduler, l'implementazione 

di specificazioni della classe base si è alquanto semplificata, ed esigenze di nuovi 

modelli (quali scheduling a priorità o basati su reti di Petri) potrebbero esserne 

agevolate. 

6.2 Ringraziamenti 

Volevo porgere un sentito ringraziamento al relatore professor Agostino Poggi ed al 

correlatore Giovanni Rimassa innanzi tutto per le loro qualità umane, in particolare la

Conclusioni - Ringraziamenti 125 

pazienza e comprensione dimostrata nei confronti di un lavoro che ha visto molti 

rallentamenti, per la possibilità che mi hanno dato, non solo in questa occasione, di 

svolgere lavori, a mio avviso, interessanti e per la capacità di stimolarmi ed 

accompagnarmi con competenza nello svolgimento di questi. 

Per gli stessi motivi devo ringraziare quei professori che, nel corso del mio curriculum 

scolastico, hanno dimostrato di essere presenti non solo in cattedra ed hanno unito 

capacità professionali, passione ed una grande disponibilità nei confronti degli 

studenti. Tra questi vorrei ricordare i professori (e le professoresse) Bocchi, 

Capelletti, Caselli, DeFranceschi e Diligenti. 

Grazie ai miei genitori, Giuseppe ed Adriana, per il loro vivo esempio ed incessante 

sostegno; a Ciccio (mio fratello Claudio) per la sopportazione (reciproca); ai parenti 

tutti per l'affetto che ci lega oltre le distanze; ad Anita per la gioia continua che mi 

infonde da ormai un anno; ai vecchi amici (e sono già passati 14 anni), Fina, Galva e 

Volpa, ed a Macca, perché finalmente possono festeggiare; agli amici conosciuti a 

Parma in questi anni, Stefano, Rosalino, Mirco e Federico, Linda & Co., Gianluigi e 

Paolo, per l'amicizia e le avventure che ci hanno legato.

Bibliografia 126 

7 Bibliografia 

Bibl. 1 Wooldridge M., Jennings N. R. - "Intelligent Agents: Theory and Practice" 

1994 

Bibl. 2 Croft D. W. - "Intelligent Software Agents: Definitions and Applications" 

Analytic Services Inc. (ANSER) 1997 

Bibl. 3 "FIPA 97 Specification" 

Foundation for Intelligent Physical Agents 1997 

Bibl. 4 Silberschatz A., Galvin P. - "Sistemi Operativi - quarta edizione" 

Addison-Wesley 1995 

Bibl. 5 Bellifemine F., Caire G., Rimassa G., Trucco T. - "JADE Programmer’s 

GUIDE" 

JADE 2.5 - TILab 2002 

http://sharon.cselt.it/projects/jade 

Bibl. 6 "Why Are Thread.stop, Thread.suspend, Thread.resume and 

Runtime.runFinalizersOnExit Deprecated?" 

Java 2 SDK, Standard Edition Documentation v.1.2.2 - Sun Microsystem 

Inc.1999 

file:///JDK/docs/guide/misc/threadPrimitiveDeprecation.html 

Bibl. 7 "What is Middleware" 

IONA Technologies 2001 

http://www.ooc.com/corba/what_is_middleware.html


Bibl. 8 "DCOM Technical Overview" 

Microsoft Corporation 1996 

http://msdn.microsoft.com/library/default.asp?url=/library/en- 

us/dndcom/html/msdn_dcomtec.asp 

Bibl. 9 "DCOM Architecture" 

Microsoft Corporation 1997 

http://msdn.microsoft.com/library/default.asp?url=/library/en- 

us/dndcom/html/msdn_dcomtec.asp 

Bibl. 10 "ORB Basics" 

Object Management Group Inc. 2001 

http://www.omg.org/gettingstarted/orb_basics.htm 

Bibl. 11 "CORBA FAQ" 


http://www.omg.org/gettingstarted/corbafaq.htm 

Bibl. 12 "Common Object Request Broker Architecture (CORBA), v.2.6" 


http://www.omg.org/technology/documents/formal/corba_2.htm 

Bibl. 13 "Common Object Request Broker Architecture (CORBA), v.2.6" 

capitolo 11: "Portable Object Adapter" - Object Management Group Inc. 

2001 

http://www.omg.org/cgi-bin/doc?formal/01-12-49 

Bibl. 14 "ORBacus for C++ and Java v. 4.0.3" 

capitolo 18: "Concurrency Models" - Object Oriented Concept Inc. 2000 

http://www.ooc.com


Bibl. 15 "JavaBeans FAQ: General Questions" 

Sun Microsystems Inc. 2002 

http://java.sun.com/products/javabeans/faq/faq.general.html 

Bibl. 16 "FAQ: Enterprise JavaBean" 

Sun Microsystems Inc. 2002 

http://java.sun.com/products/javabeans/faq/faq.enterprise.html 

Bibl. 17 "EJB Tutorial - An overview of EJB" 

http://www.ejbtut.com/Overview.jsp 

Bibl. 18 DeMichiel L. G. - "Enterprise JavaBeans Specification version 2.0, final 

release" 

ejb-2_0-fr2-spec.pdf - capitoli 4,7 e 24 - Sun Microsystems Inc. 2001 

http://java.sun.com/products/ejb/docs.html 

Bibl. 19 Gopalan Suresh Raj - "EJB Servers" 

1998 

http://www.execpc.com/~gopalan/java/ejb/ejbserv.html 

Bibl. 20 Scallan T. - "Assuring Reliability of Enterprise JavaBean Applications" 

Segue Software 1999 

http://www.omg.org/news/whitepapers/segueejb.pdf 

Bibl. 21 Gopalan Suresh Raj - "A Detailed Comparison of CORBA, DCOM and 

Java/RMI (with specific code examples)" 

1998 

http://www.execpc.com/~gopalan/misc/compare.html


Bibl. 22 DISA, JIEO, and JEXF - "Recommendations for Using DCE, DCOM, and 

CORBA Middleware" 

Mitre Corporation 1998 - Mitre Document ID: MITRE-DAS-C1 

http://diicoe.disa.mil/coe/atd/das_all.pdf 

Bibl. 23 Santiago Comella-Dorda - "Component Object Model (COM), DCOM, and 

Related Capabilities" 

Carnegie Mellon University 2001 

http://www.sei.cmu.edu/str/descriptions/com_body.html

Studio e Realizzazione di Architetture Concorrenti per Sistemi ad ...

Create successful ePaper yourself

Delete template?

Save as template?