Implementa un monitor in termini di semafori

3

Dai concetti del sistema operativo di Abraham Silberschatz, Peter B. Galvin, Greg Gagne

5.8.3 Implementing a Monitor Using Semaphores

We now consider a possible implementation of the monitor mechanism using semaphores. For each monitor, a semaphore mutex (initialized to 1) is provided. A process must execute wait(mutex) before entering the monitor and must execute signal(mutex) after leaving the monitor.

Since a signaling process must wait until the resumed process either leaves or waits, an additional semaphore, next, is introduced, initialized to 0. The signaling processes can use next to suspend themselves. An integer variable next count is also provided to count the number of processes suspended on next. Thus, each external function F is replaced by

wait(mutex);
...
body of F
...
if (next count > 0)
    signal(next);
else
    signal(mutex);

Mutual exclusion within a monitor is ensured.

  1. Poiché il semaforo mutex è inizializzato a 1, è usato per limitare al massimo un processo può essere all'interno del monitor?

  2. Il semaforo next indica il numero di processi sospesi su next . Questi processi sono sospesi su next all'interno di un monitor?

  3. Se le risposte alle due domande precedenti sono sì, si contraddicono a vicenda?

    Se no, come funziona realmente un monitor?

Grazie.

    
posta Tim 28.10.2016 - 02:21
fonte

1 risposta

2
  1. Since the semaphore mutex is initialized to 1, is it used for limiting at most one process can be inside the monitor?

Sì.

  1. The semaphore next means the number of processes suspended on next. Are these processes suspended on next all inside a monitor?

Sì, alcuni sono sospesi su next , altri su mutex . Quelli sospesi su next sono "dentro" il monitor, nel senso che hanno superato l'attesa su mutex , e hanno usato questa esclusione reciproca per eseguire un test delle condizioni all'interno della sicurezza (atomicità) del blocco che il monitor fornisce, eppure hanno scelto di cedere fino ad un momento successivo, e sono quindi sospese sulla coda next invece che sulla coda mutex .

Questa è una funzione opzionale. Se nessun cliente produce mai a causa di condizioni, allora ci saranno solo clienti in attesa di mutex . Se un cliente cede a causa di condizioni, ha la priorità sui clienti che non hanno ancora passato il wait originale per mutex . (Poiché il filo produce a causa delle condizioni, rilascia efficacemente il monitor durante il sonno e lo riattiva al risveglio, tuttavia non perde la sua priorità, ad esempio è nella coda next ora, non in mutex coda.)

  1. If the answers to the above two questions are yes, do they contradict each other?

No, perché la coda next ha uno scopo diverso ed è facoltativamente utilizzata quando un thread che ha ottenuto il blocco sceglie di produrre invece di rilasciare semplicemente il blocco.

Un altro testo lo afferma in qualche modo più chiaro:

5.8.3 Implementing a Monitor Using Semaphores

• One possible implementation of a monitor uses a semaphore "mutex" to control mutual exclusionary access to the monitor, and a counting semaphore "next" on which processes can suspend themselves after they are already "inside" the monitor ( in conjunction with condition variables, see below. ) The integer next_count keeps track of how many processes are waiting in the next queue. Externally accessible monitor processes are then implemented as:

• Condition variables can be implemented using semaphores as well. For a condition x, a semaphore "x_sem" and an integer "x_count" are introduced, both initialized to zero. The wait and signal methods are then implemented as follows. ( This approach to the condition implements the signal-and-wait option described above for ensuring that only one process at a time is active inside the monitor. )

    
risposta data 28.10.2016 - 03:52
fonte

Leggi altre domande sui tag