Dom 18 Agosto, 06:40:23 - 2019

Autore Topic: Esame 27 gennaio 2015  (Letto 2447 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline claudio123

  • Studente
  • *
  • Post: 20
  • FeedBack: +0/-0
    • Mostra profilo
Re:Esame 27 gennaio 2015
« Risposta #15 il: Mer 04 Gennaio, 15:54:51 - 2017 »
Io l'esercizio sui semafori l'ho interpretato nel seguente modo:

IPOTESI:
Si suppone che la memoria condivisa R contenga inizialmente un messaggio già depositato ma non ancora letto.

generic sem s1;
binary sem s2[M];
generic sem s3;

INIT:
       s1=0; s3=2;
       for(i=1;i<=M;i++){ s2=1;}

SCRIVI (Pi):
       wait(s1,2);
       <write message in R>;
       signal(s3,2);
       for(i=1;i<=M;i++){ signal(s2) }

LEGGI (PRi):
       me=getpid();
       wait(s2[me]);
       wait(s3,1);
       <read message from R>;
       signal(s1,1);
 
Spiegazione:
A valle dell'ipotesi fatta in precedenza, i processi PRi (esattamente 2 distinti) dovranno in prima battuta leggere il messaggio presente in R. Se per assurdo viene chiamata la procedura SCRIVI da un processo Pi, esso viene bloccato dall'istruzione wait(s1,2).
Viene quindi eseguita la procedura LEGGI da un primo processo PRx il quale leggerà il contenuto di R per la prima volta aggiornando i valori dei vari semafori come descritto dalla procedura stessa. A questo punto se un processo Pi tenta di eseguire  la procedura SCRIVI esso viene bloccato ancora una volta per effetto sempre della wait(s1,2), infatti finchè un messaggio in R non viene letto esattamente 2 volte da due processi PRi diversi esso non potrà essere sovrascritto.
Non rimane allora che eseguire ancora la procedura LEGGI per un altro processo PRy (NOTA BENE: il semaforo binario S2 serve proprio ad assicurare che due processi diversi leggano il messaggio in R) il quale leggerà per la seconda volta il messaggio in R.
A questo punto se un altro processo PRz tenta di eseguire la procedura Leggi, esso verrà bloccato dalla wait(s3,1). Potrà ora intervenire un processo Pi con la procedura SCRIVI grazie alla quale verrà scritto un nuovo messaggio in R e i semafori verranno settati con i valori iniziali.

Offline polyc

  • Studente
  • *
  • Post: 1
  • FeedBack: +0/-0
    • Mostra profilo
Re:Esame 27 gennaio 2015
« Risposta #16 il: Sab 28 Gennaio, 11:46:10 - 2017 »
Io l'esercizio sui semafori l'ho interpretato nel seguente modo:

IPOTESI:
Si suppone che la memoria condivisa R contenga inizialmente un messaggio già depositato ma non ancora letto.

generic sem s1;
binary sem s2[M];
generic sem s3;

INIT:
       s1=0; s3=2;
       for(i=1;i<=M;i++){ s2=1;}

SCRIVI (Pi):
       wait(s1,2);
       <write message in R>;
       signal(s3,2);
       for(i=1;i<=M;i++){ signal(s2) }

LEGGI (PRi):
       me=getpid();
       wait(s2[me]);
       wait(s3,1);
       <read message from R>;
       signal(s1,1);
 
Spiegazione:
A valle dell'ipotesi fatta in precedenza, i processi PRi (esattamente 2 distinti) dovranno in prima battuta leggere il messaggio presente in R. Se per assurdo viene chiamata la procedura SCRIVI da un processo Pi, esso viene bloccato dall'istruzione wait(s1,2).
Viene quindi eseguita la procedura LEGGI da un primo processo PRx il quale leggerà il contenuto di R per la prima volta aggiornando i valori dei vari semafori come descritto dalla procedura stessa. A questo punto se un processo Pi tenta di eseguire  la procedura SCRIVI esso viene bloccato ancora una volta per effetto sempre della wait(s1,2), infatti finchè un messaggio in R non viene letto esattamente 2 volte da due processi PRi diversi esso non potrà essere sovrascritto.
Non rimane allora che eseguire ancora la procedura LEGGI per un altro processo PRy (NOTA BENE: il semaforo binario S2 serve proprio ad assicurare che due processi diversi leggano il messaggio in R) il quale leggerà per la seconda volta il messaggio in R.
A questo punto se un altro processo PRz tenta di eseguire la procedura Leggi, esso verrà bloccato dalla wait(s3,1). Potrà ora intervenire un processo Pi con la procedura SCRIVI grazie alla quale verrà scritto un nuovo messaggio in R e i semafori verranno settati con i valori iniziali.

Secondo me in questo modo ti ritrovi nel peggiore dei casi il semaforo S1 a -2n(n numero di Pi) poiche' tutti i Pi fanno wait di 2 su S1. Percio' la signal eseguita su S1 da PRi non basta a far ritornare S1 a un valore >= 0.
Con un mio collega abbiamo pensato a questa soluzione ipotizzando il buffer R vuoto all'inizio.

Codice: [Seleziona]
binary_sem MUTEX //mutua esclusione tra i processi scrittori
binary_sem MuTEX2 //mutua esclusione tra processi lettori
sem READ // attesa di lettura per i processi lettori
sem WRITE //attesa di scrittura per il processo entrato in sezione critica

Init:

//R VUOTO
WRITE = 2
READ = 0
MUTEX = 1
MUTEX2 = 1


Pi:
  SCRIVI:
    wait(MUTEX) //entro in sezione critica
    wait(WRITE,2) //aspetto le letture dei 2 processi()
    <scrivi su R>
    signal(READ,2) //segnala che 2 processi possono leggere
    signal(MUTEX) //esco dalla sezione critica

PRi:
  LEGGI:
    wait(MUTEX2)//entro in sezione critica
    wait(READ)//aspetta che Pi abbia scritto
    <leggi R>
    signal(WRITE)//segnala che un processo ha letto
    signal(MUTEX2)//esco dalla sezione critica

fatemi sapere che ne pensate