Mi aiutate a capire i monitor?

[Bandit]

Ciao a tutti ragazzi
ho cercato di studiare dalle slides e da quello che ho potuto trovare da internet i monitor ma non è che ci ho capito molto.

Posso dirvi cosa ho capito e chiedervi delle integrazioni eventualmente?li divido in concetti in modo da essere il più chiaro possibile

1)Il monitor è un tipo di dato astratto contenente delle variabili (definite nel monitor e visibili solo in esso) utilizzabili solo da alcuni processi (che sono procedure anch'esse del monitor). Fin qui tutto ok, giusto?

2) Ora poi si parla che per garantire che un solo processo per volta, abbia accesso alla variabile locale (credo che si riferisca alle variabili provate del monitor, giusto?) si impone che le funzioni di accesso al monitor vengano eseguite in modo mutuamente esclusivo, e che tutti gli altri processi che invocano una variabile del monitor devono attendere se c'è già un altro processo attivo nel monitor.
Se fin qui è tutto giusto io vi chiedo: ma allora come si spiega la definizione? cioè ci sono processi esterni al monitor che accedono ad esso, e poi ci sono anche processi interni al monitor?

3) si parla di istanze del monitor, ma cosa si intende? le risorse private del monitor?

[Floris]

Da quel che ricordo, un monitor è un oggetto che incapsula variabili che devono essere accedute in modo controllato. Quindi un processo che voglia accedere la variabile "protetta" deve chiamare i metodi del monitor.
Sarà quindi il monitor a gestire l'accesso concorrente alla variabile prevedendo all'interno dei propri metodi di accesso alla variabile istruzioni di wait per porre in attesa i processi e signal per risvegliarli.
I semafori dovrebbero essere una degenerazione del concetto di monitor quando si ha mutua esclusione, cioè quando solo un processo in ogni istante può accedere alle variabili.

Nei moderni linguaggi di programmazione concorrenti solitamente i monitor sono implementati attraverso primitive del linguaggio (come in Java con synchronized o Ada con...non ricordo) per evitare errori di programmazione.

Il monitor è un tipo di dato astratto contenente delle variabili (definite nel monitor e visibili solo in esso) utilizzabili solo da alcuni processi (che sono procedure anch'esse del monitor). Fin qui tutto ok, giusto?

Nel monitor sono definite le variabili su cui deve garantire sincronizzazione più eventuali variabili accessorie per garantire tale sincronizzazione. I processi per accedere alle variabili "sincronizzate" dovranno utilizzare le procedure del monitor.

Originariamente inviato da Bandit

cioè ci sono processi esterni al monitor che accedono ad esso, e poi ci sono anche processi interni al monitor?

Processi interni al monitor sono quelli che in un dato momento hanno accesso alle variabili da esso protette o che sono in attesa di accesso.

Originariamente inviato da Bandit

si parla di istanze del monitor, ma cosa si intende? le risorse private del monitor?

Solitamente i monitor sono implementati tramite oggetti con un contatore che tiene traccia del numero di processi che in un dato istante stanno accedendo alle variabili.

Comunque guarda anche qua:
http://it.wikipedia.org/wiki/Monitor...onizzazione%29

[Bandit]

Ciao Floris
credo che la tua sintesi è davvero chiara, però è meglio che faccio qualche precisazione per maggiore mia chiarezza

Nel monitor sono definite le variabili su cui deve garantire sincronizzazione più eventuali variabili accessorie per garantire tale sincronizzazione. I processi per accedere alle variabili "sincronizzate" dovranno utilizzare le procedure del monitor.

Allora nel monitor ci sono delle variabili (dette variabili condizione) che servono per sincronizzare l'accesso alle variabili locali (variabili locali intendo le variabili che sono definite nel monitor, che sono accedibili solo dalle procedure interne al monito)


Per il momento mi sembra chiaro , però poi ci ragiono ed eventualmente ti scrivo

grazie mille

[starfred]

ciao, come ha scritto Floris, "eventuali variabili accessorie per garantire tale sincronizzazione". Non per forza devo avere delle variabili condizione.

[Floris]

eventuali variabili accessorie per garantire tale sincronizzazione

Esatto. Infatti in Java viene usato synchronized che è un costrutto per la mutua esclusione. Non serve, in questo caso, (semplice mutua esclusione) definire variabili di controllo per la sincronizzazione. Basta porre la variabile da controllare all'interno di un oggetto e poi etichettare tutti i metodi di accesso ad essa come synchronized.

Cose più sofisticate, sempre in Java, come ad esempio l'accesso simultaneo limitato ad una variabile (ad es. 3 thread per volta possono accedervi) le puoi fare incapsulando la variabile in un oggetto che sfrutta un contatore (variabile condizione). Da notare che le operazioni che agiscono su tale contatore, come ad esempio, quelle che controllano il suo valore per vedere quanti processi in un dato istante hanno accesso alla variabile controllata, devono essere racchiuse in blocchi synchronized cosicchè eventuali race conditions non pregiudichino la semantica che si vuole implementare.

[Bandit]

però se considero le variabili condizioni queste sono nel monitor giusto?

ora poi c'è un problema: trovo scritto che per garantire l'accesso in mutua esclusione alle funzioni del monitor , si associa ad ogni oggetto del monitor un semaforo mutex

e per la gestione delle politiche di sospensione e riattivazione di processi sulle variabili condizione, la soluzione è quella di Hoare ( se c'è un processo che richiede di entrare nel monitor, e c'è già un processo in attesa sulla variabile condizione, quest'ultimo sarà il processo che entrerà nel monitor) ,oltre poi all'introduzione di un semaforo urgent .
Questi due semafori non li ho capiti.

per il mutex (per garantire mutua esclusione)
ho trovato e capito che è inizializzato ad 1 e che per entrare nel monitor un processo deve eseguire una wait (mutex), invece per entrare una signal(mutex)

per l'urgent (sospensione e riattivazione processi) invece
è inizializzato a 0 ma non ci ho capito nulla

[starfred]

Originariamente inviato da Bandit

ora poi c'è un problema: trovo scritto che per garantire l'accesso in mutua esclusione alle funzioni del monitor , si associa ad ogni oggetto del monitor un semaforo mutex

Si e no, dipende dai linguaggi, per esempio con i metodi synchronized il mutex è implicito. Ma nessuno mi vieta di utilizzare un mutex unico per tutte le funzioni del monitor.

Originariamente inviato da Bandit

e per la gestione delle politiche di sospensione e riattivazione di processi sulle variabili condizione, la soluzione è quella di Hoare ( se c'è un processo che richiede di entrare nel monitor, e c'è già un processo in attesa sulla variabile condizione, quest'ultimo sarà il processo che entrerà nel monitor) ,oltre poi all'introduzione di un semaforo urgent .
Questi due semafori non li ho capiti.

No, attenzione, per prima cosa bisogna fare due precisazioni:

1) se un processo è in attesa su una variabile condizione, prima di esser risvegliato deve verificarsi l'evento per il quale l'attesa non è più valida (in java avviene attraverso la semantica della signal da parte di un altro thread)

2) Il fatto che il processo risvegliato debba entrare per primo dipende anch'esso dal tipo di linguaggio e dalla semantica, il caso a cui tu fai riferimento è la signal-and-urgent.

Originariamente inviato da Bandit

per il mutex (per garantire mutua esclusione)
ho trovato e capito che è inizializzato ad 1 e che per entrare nel monitor un processo deve eseguire una wait (mutex), invece per entrare una signal(mutex)

Generalmente await e signal vengono utilizzati su variabili condition, non sui mutex (in java generalmente si utilizzano mutex di tipo reentrantlock con metodi lock() e unlock() )
Forse tu volevi riferirti ai metoti wait, notify e notifyall?

P.s. Credo che ti stia addentrando in argomentazioni complesse, che senza l'aiuto di un buon libero non se ne esce facilmente...

[Bandit]

http://www.megaupload.com/?d=B6VF58MQ
questa è la slides che ho
e poi ho cercato di vedere su internet altri libri


per la cosa detta al 1)
che mi vuoi dire che il signal non necessariamente risveglia il programma che immediatamente sarà eseguito?

Per 2) allora faccio riferimento al caso signal-and-urgent


cmq se hai qualche link me lo potresti indicare?qualche slides

[Floris]

http://en.wikipedia.org/wiki/Monitor...hronization%29
Prova a guardare gli External Links.

[Bandit]

Originariamente inviato da Floris

http://en.wikipedia.org/wiki/Monitor...hronization%29
Prova a guardare gli External Links.

grazie
ma io vorrei capire solo quello delle slides, fino ai produttori e consumatori, ma senza le eventuali implementazioni specifiche etc etc

[starfred]

ciao, come ti ho detto prima esistono diverse semantiche della signal, quello a cui tu fai riferimento (signal-and-urgent) è un caso particolare di signal-and-wait. Nel caso della signal-and-urgent e signal-and-wait è corretto affermare che il processo risvegliato è quello che immediatamente sarà eseguito.
Attenzione però, nella urgent il segnalato (una volta uscito dal monitor) ritorna subito il controllo al processo segnalante che si era sospeso, mentre invece nella signal-and-wait questo non è vero.

Comunque, son argomentazioni difficili da capire così, senza una spiegazione esaustiva e vari esempi. Il mio consiglio è, per ora, dimenticarti delle variabili condition ed invece cercare di approfondire il concetto di monitor, entry queue del monitor, synchronized ed i metodi wait() notify() e notifyall().

Ps. Ho visto le slides e credo che siano veramente fatte male (giuste ma fatte male). Per prima cosa utilizzano il C / C++ per descrivere i costrutti dei monitor cosa che con il Java risulta molto più semplice, poi (e questo secondo me crea moltissima confusione) all'inizio utilizzano la wait() sia per indicare un lock di un semaforo sia per indicare la wait su una condition; e per ultima cosa vanno subito a implementare una signal-and-urgent senza accenare alle altre varie politiche di signal. Non viene accennato minimamente il metodi notify e notifyAll... insomma, a mio parere, sono pessime.