[sistemi operativi]:help con i monitor
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?
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?
Risposte
C'è qualcosa che non mi torna... non mi risulta si acceda ad un monitor in maniera mutuamente esclusiva, è il monitor stesso che garantisce la mutua esclusione. Dove hai trovato queste indicazioni? Perché forse è solo un problema di terminologia.
ciao Rggb
grazie della risposta intanto
ho trovato qualcosa sui libri della materia grazie a google libri, poi avevo da qualche parte nel mio pc delle slides di un corso ma non sono cmq riuscito a capire per potermi fare un discorso di per se logico.
se hai qualche materiale in merito semplicemente spiegato o lo potessi fare tu, ti sarei veramente grato
grazie della risposta intanto
ho trovato qualcosa sui libri della materia grazie a google libri, poi avevo da qualche parte nel mio pc delle slides di un corso ma non sono cmq riuscito a capire per potermi fare un discorso di per se logico.
se hai qualche materiale in merito semplicemente spiegato o lo potessi fare tu, ti sarei veramente grato
Sicuramente è un problema di terminologia, magari non si riesce bene a capire, ma in alcuni punti parla dei processi del monitor (realizzati dalle procedure dello stesso), in altri parla dei processi ESTERNI ad esso.
Ho un po' di materiale, dopo vedo se trovo qualcosa di basilare.
Ho un po' di materiale, dopo vedo se trovo qualcosa di basilare.
Il Monitor e' di fatto un ADT (Abstract Data Type), che, con le sue procedure, mette a disposizione un ambiente che garantisce la gestione della mutua esclusione in scenari dove piu' processi (o threads) tentano di accedere a variabili condivise in un modello ad ambiente Globale.
Le variabili del monitor sono come la zona PRIVATE di una classe, quindi completamente invisibili ai processi che utilizzano il servizio.
Le procedure (tipicamente: Init_Monitor, Enter_Monitor, Wait_Condition, Signal_Condition, Leave_Monitor, Remove_Monitor) sono funzioni messe a disposizione dalla struttura per i processi, che quindi non vedranno le variabili del monitor, ma ne potranno comunque usurfruire dei servizi.
Non esiste un vincolo sul numero di processi che possono interagire contemporaneamente col monitor(che quindi dall'esterno chiedono servizi alla struttura), ma esiste il vincolo che SOLO UN SOLO PROCESSO puo' essere attivo al suo interno. Sia che un processo sia attivato dalla Entry_Queue (la coda sul mutex d'ingresso), sia riattivato da una qualsiasi delle Condition_Queue (coda di processi in attesa su una variabile condition).
Tale processo, unico attivo nell'istanza del monitor, puo' avere accesso ESCLUSIVO alla variabile, ed essere sicuro che non vi siano problemi legati alla concorrenza.
Per facilitare la visione in generale del Monitor, lo si puo' immaginare come una sorta di Ufficio postale, dove pero' un solo cliente alla volta puo' essere servito.
Il numero che si prende all'ingresso e' la posizione nell'Entry_Que.
Una volta che arriva il proprio "numero",Si risolve la Wait sul mutex, e ci si reca allo sportello del servizio che si necessita, controllando che vi siano i requisiti per potervi accedere (tipicamente una IF(..) per i monitor Signal_Wait, Signal_Return e Hoare, oppre un WHILE(..) per i monitor di tipo Signal_Continue).
Se tali condizioni NON sono soddisfatte ci si mette in coda per lo sportello (Cond_Wait) e si aspetta che le condizioni diventino vere, altrimenti si procede senza accodarsi.
Conclusa la nostra richiesta e quindi il nostro lavoro sulla variabile in mutua esclusione, si effettuano delle Signal per risolvere Wait di eventuali altri clienti in coda (che quindi proseguiranno nella loro esecuzione), oppure in attesa del proprio numero d'ingresso. Al termine, si Esce dall'uficio con una Signal sul mutex.
I monitor possono sembrare piuttosto ostici ad un primo approccio, ma spratichendosi e studiandone il codice, si riesce presto a comprenderne i meccanismi
Le variabili del monitor sono come la zona PRIVATE di una classe, quindi completamente invisibili ai processi che utilizzano il servizio.
Le procedure (tipicamente: Init_Monitor, Enter_Monitor, Wait_Condition, Signal_Condition, Leave_Monitor, Remove_Monitor) sono funzioni messe a disposizione dalla struttura per i processi, che quindi non vedranno le variabili del monitor, ma ne potranno comunque usurfruire dei servizi.
Non esiste un vincolo sul numero di processi che possono interagire contemporaneamente col monitor(che quindi dall'esterno chiedono servizi alla struttura), ma esiste il vincolo che SOLO UN SOLO PROCESSO puo' essere attivo al suo interno. Sia che un processo sia attivato dalla Entry_Queue (la coda sul mutex d'ingresso), sia riattivato da una qualsiasi delle Condition_Queue (coda di processi in attesa su una variabile condition).
Tale processo, unico attivo nell'istanza del monitor, puo' avere accesso ESCLUSIVO alla variabile, ed essere sicuro che non vi siano problemi legati alla concorrenza.
Per facilitare la visione in generale del Monitor, lo si puo' immaginare come una sorta di Ufficio postale, dove pero' un solo cliente alla volta puo' essere servito.
Il numero che si prende all'ingresso e' la posizione nell'Entry_Que.
Una volta che arriva il proprio "numero",Si risolve la Wait sul mutex, e ci si reca allo sportello del servizio che si necessita, controllando che vi siano i requisiti per potervi accedere (tipicamente una IF(..) per i monitor Signal_Wait, Signal_Return e Hoare, oppre un WHILE(..) per i monitor di tipo Signal_Continue).
Se tali condizioni NON sono soddisfatte ci si mette in coda per lo sportello (Cond_Wait) e si aspetta che le condizioni diventino vere, altrimenti si procede senza accodarsi.
Conclusa la nostra richiesta e quindi il nostro lavoro sulla variabile in mutua esclusione, si effettuano delle Signal per risolvere Wait di eventuali altri clienti in coda (che quindi proseguiranno nella loro esecuzione), oppure in attesa del proprio numero d'ingresso. Al termine, si Esce dall'uficio con una Signal sul mutex.
I monitor possono sembrare piuttosto ostici ad un primo approccio, ma spratichendosi e studiandone il codice, si riesce presto a comprenderne i meccanismi
grazie PandaZero
in questi giorni ho cercato tanto ed ho trovato un link
anche se propriamente come utlizzare un monitor nel problema del produttore consumatore non è che l'ho capito proprio bene: a parte il fatto che ovviamente un processo che invoca un monitor e lo può utilizzare è solo uno per volta e quindi il problema della corsa critica verso un'area di memoria dove possono scrivere e leggere due programmi non c'è più
in questi giorni ho cercato tanto ed ho trovato un link
dove c'è una risorsa abbastanza semplice da capire e credo che mi vedrò quello
anche se propriamente come utlizzare un monitor nel problema del produttore consumatore non è che l'ho capito proprio bene: a parte il fatto che ovviamente un processo che invoca un monitor e lo può utilizzare è solo uno per volta e quindi il problema della corsa critica verso un'area di memoria dove possono scrivere e leggere due programmi non c'è più
Non e' corretto dire che un processo puo' utilizzare un monitor soltanto una volta.
Come e' noto nella tipologia Signal and Wait (ma anche nalla Signal and Continue), il processo puo' percorrere piu' volte l'istanza del monitor seppure l'operazione in se' non sia ancora completa. Se studi il caso del Lettore e Scrittore, capirai meglio che cosa si intende, siccome li' e' fortemente enfatizzata la necessita' di ripercorrere il monitor piu' volte.
Per quanto riguarda il problema del Produttore e Consumatore, Devi partire dai due vincoli di modello base:
1) Un Produttore puo' produrre solo in un'area dove non sia presente un dato gia' immesso.
2) Un Consumatore puo' consumare una rirosa solo da un'area dove sia presente un dato immesso.
in sostanza, se definisco la variabile "pieno" come flag per monitorare lo stato della mia risorsa, posso procedere con il seguente Pseudo Codice:
int pieno=0;
/* ---PRODUTTORE--- */
Enter_Monitor
if(pieno==1) Wait_Condition(produttori) //istruzione di controllo: un produttore non esegue se la risorsa e' piena
/// Sezione Critica ///
pieno=1 //al fine della produzione, cambia lo stato della risorsa
Signal_Condition(consumatori) //attiva un consumatore dalla coda consumatori
Leave_Monitor
/* ---CONSUMATORE---*/
Enter_Monitor
if(pieno==0) Wait_Condition(consumatori)
/// Sezione Critica ///
pieno=0
Signal_Condition(produttori)
Leave_Monitor
Dove: produttori e consumatori sono indicatori di due variabili condition sul quale gestire le rispettive code.
NB: le istruzioni di controllo sono relative a tutte le tipologie di monitor esclusa la Signal and Continue, siccome per la sua caratteristica necessita di un check attivo del flag: basta sostituire quindi l'if con un while.
Come e' noto nella tipologia Signal and Wait (ma anche nalla Signal and Continue), il processo puo' percorrere piu' volte l'istanza del monitor seppure l'operazione in se' non sia ancora completa. Se studi il caso del Lettore e Scrittore, capirai meglio che cosa si intende, siccome li' e' fortemente enfatizzata la necessita' di ripercorrere il monitor piu' volte.
Per quanto riguarda il problema del Produttore e Consumatore, Devi partire dai due vincoli di modello base:
1) Un Produttore puo' produrre solo in un'area dove non sia presente un dato gia' immesso.
2) Un Consumatore puo' consumare una rirosa solo da un'area dove sia presente un dato immesso.
in sostanza, se definisco la variabile "pieno" come flag per monitorare lo stato della mia risorsa, posso procedere con il seguente Pseudo Codice:
int pieno=0;
/* ---PRODUTTORE--- */
Enter_Monitor
if(pieno==1) Wait_Condition(produttori) //istruzione di controllo: un produttore non esegue se la risorsa e' piena
/// Sezione Critica ///
pieno=1 //al fine della produzione, cambia lo stato della risorsa
Signal_Condition(consumatori) //attiva un consumatore dalla coda consumatori
Leave_Monitor
/* ---CONSUMATORE---*/
Enter_Monitor
if(pieno==0) Wait_Condition(consumatori)
/// Sezione Critica ///
pieno=0
Signal_Condition(produttori)
Leave_Monitor
Dove: produttori e consumatori sono indicatori di due variabili condition sul quale gestire le rispettive code.
NB: le istruzioni di controllo sono relative a tutte le tipologie di monitor esclusa la Signal and Continue, siccome per la sua caratteristica necessita di un check attivo del flag: basta sostituire quindi l'if con un while.
Ciao Panda grazie mille
credo che ora col tuo esempio sia riuscito a capire, però domani ci ritorno a mente più fresca e vedo se mi vengono ulteriori domande, ma soprattutto se riesco a darmi la risposta da solo.
Grazie mille per la collaborazione
credo che ora col tuo esempio sia riuscito a capire, però domani ci ritorno a mente più fresca e vedo se mi vengono ulteriori domande, ma soprattutto se riesco a darmi la risposta da solo.
Grazie mille per la collaborazione
Per materiale sulla concorrenza consiglio senza dubbio questo libro:
Principi di programmazione concorrente di Ancilotti Paolo e Boari Maurelio - UTET/1997
c'è tutto su questo genere di problemi e una loro risoluzione (1WnR,nW1R,nWnR,...), con varie strutture dati (semafori, mutex, guardie, monitor, ...), vecchiotto (la prima versione è del 1989, questa è solo una ristampa) ma è ancora molto attuale
Principi di programmazione concorrente di Ancilotti Paolo e Boari Maurelio - UTET/1997
c'è tutto su questo genere di problemi e una loro risoluzione (1WnR,nW1R,nWnR,...), con varie strutture dati (semafori, mutex, guardie, monitor, ...), vecchiotto (la prima versione è del 1989, questa è solo una ristampa) ma è ancora molto attuale
Credo di aver capito abbastanza sui monitor ed anche la spiegazione sul consumatore e sul produttore è stata efficace grazie mille ancora.
Vorrei una precisazione sul semaforo urgent. Io vi dico quello che ho capito
Per far si, che un processo che riattivi un altro processo, si sospenda , si associa ad ogni monitor un secondo semaforo (oltre a quello mutex) detto urgent , inizializzato a 0, sul quale un processo sbloccante si arresta tramite una wait(urgent).
Prima di abbandonare il monitor è necessario verificare che nessun processo sia in cosa a tale semaforo (urgent).
Per tenere conto dei processi presenti si utilizza un urgentcount, cioè un contatore. Se il suo valore è maggiore di zero si esegue una signal(urgent).
------------------------------------------------
Ora vi chiedo:questa signal(urgent), dove riattiva il processo? nel monitor?
altra domanda: Il semaforo mutex serve per garantire la mutua esclusione tra le procedure interne al monitor richieste dai processi esterni al monitor, giusto?
Vorrei una precisazione sul semaforo urgent. Io vi dico quello che ho capito
Per far si, che un processo che riattivi un altro processo, si sospenda , si associa ad ogni monitor un secondo semaforo (oltre a quello mutex) detto urgent , inizializzato a 0, sul quale un processo sbloccante si arresta tramite una wait(urgent).
Prima di abbandonare il monitor è necessario verificare che nessun processo sia in cosa a tale semaforo (urgent).
Per tenere conto dei processi presenti si utilizza un urgentcount, cioè un contatore. Se il suo valore è maggiore di zero si esegue una signal(urgent).
------------------------------------------------
Ora vi chiedo:questa signal(urgent), dove riattiva il processo? nel monitor?
altra domanda: Il semaforo mutex serve per garantire la mutua esclusione tra le procedure interne al monitor richieste dai processi esterni al monitor, giusto?
1) Esatto. In pratica la urgent queue e' quella coda ad ALTA PRIORITA' nel monitor di HOARE (di tipo Signal and wait), e per questo ha la precedenza su altre tipologie di attivazione (sul mutex, o su una condition).
Se si introduce il concetto di priorita' univoca nel monitor, non e' difficile ricavare un codice esemplificativo:
Per tutte le tipologie di monitor, di norma le funzioni di Init_Monitor, Enter_Monitor, Leave_Monitor e Remove_Monitor sono simili se non uguali. Quindi resta alle due funzioni Wait_Condition e Signal_Condition rappresentare gli elementi distintivi tra tutte le tipologie di monitor.
In particolare, quelle di un monitor di HOARE, si implementano come segue:
void Wait_Condition(Monitor* M, int cond){
M->cond_count[cond]++;
if (*(M->urgent_count)>0) Signal_Sem (M->urgent_id,0); //Se vi sono processi in attesa su urgent, li riattiva immediatamente
else Signal_Sem (M->mutex,0); //altrimenti procede come da norma
Wait_Sem (M->cond_id,cond);
M->cond_count[cond]--;
}
void Signal_Condition(Monitor* M, int cond){
*(M->urgent_count)++;
if (M->cond_count[cond]>0){
Signal_Sem (M->cond_id,cond);
Wait_Sem (M->urgent_id,cond); //sospesosi, il processo va in attesa su urgent
}
*(M->urgent_count)--; //questo contatore resta inalterato se non vi sono processi in coda sulla condition cond
}
NB: Monitor e' un record (o classe se ti piace il c++), che al suo interno possiede tutte e 7 variabili minime caratteristiche del monitor Hoare. cond, nelle firme delle funzioni, e' il numero della condition sulla quale si vuol operare.
Il mio consiglio, comunque, e' sempre quello di studiare il codice. Non c'e' modo migliore di comprendere le logiche di queste strutture!
2) E' il monitor nel suo intero contesto che gestisce la mutua esclusione di una risorsa tra piu' processi. Il mutex della Entry Queue e' solo la coda dove processi "esterni" attendono in fila il loro turno di accesso al monitor. Esso garantisce, nel caso in cui fosse l'unico, che solo un processo alla volta possa da li' accedere al monitor.
Se si introduce il concetto di priorita' univoca nel monitor, non e' difficile ricavare un codice esemplificativo:
Per tutte le tipologie di monitor, di norma le funzioni di Init_Monitor, Enter_Monitor, Leave_Monitor e Remove_Monitor sono simili se non uguali. Quindi resta alle due funzioni Wait_Condition e Signal_Condition rappresentare gli elementi distintivi tra tutte le tipologie di monitor.
In particolare, quelle di un monitor di HOARE, si implementano come segue:
void Wait_Condition(Monitor* M, int cond){
M->cond_count[cond]++;
if (*(M->urgent_count)>0) Signal_Sem (M->urgent_id,0); //Se vi sono processi in attesa su urgent, li riattiva immediatamente
else Signal_Sem (M->mutex,0); //altrimenti procede come da norma
Wait_Sem (M->cond_id,cond);
M->cond_count[cond]--;
}
void Signal_Condition(Monitor* M, int cond){
*(M->urgent_count)++;
if (M->cond_count[cond]>0){
Signal_Sem (M->cond_id,cond);
Wait_Sem (M->urgent_id,cond); //sospesosi, il processo va in attesa su urgent
}
*(M->urgent_count)--; //questo contatore resta inalterato se non vi sono processi in coda sulla condition cond
}
NB: Monitor e' un record (o classe se ti piace il c++), che al suo interno possiede tutte e 7 variabili minime caratteristiche del monitor Hoare. cond, nelle firme delle funzioni, e' il numero della condition sulla quale si vuol operare.
Il mio consiglio, comunque, e' sempre quello di studiare il codice. Non c'e' modo migliore di comprendere le logiche di queste strutture!
2) E' il monitor nel suo intero contesto che gestisce la mutua esclusione di una risorsa tra piu' processi. Il mutex della Entry Queue e' solo la coda dove processi "esterni" attendono in fila il loro turno di accesso al monitor. Esso garantisce, nel caso in cui fosse l'unico, che solo un processo alla volta possa da li' accedere al monitor.
grazie infinite, credo di aver capito
sopratutto per i codici che hai scritto: hai ragione così si capisce di più
ciao
sopratutto per i codici che hai scritto: hai ragione così si capisce di più
ciao
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo