Anteprima
Vedrai una selezione di 10 pagine su 329
Sistemi operativi (teoria completa + domande) Pag. 1 Sistemi operativi (teoria completa + domande) Pag. 2
Anteprima di 10 pagg. su 329.
Scarica il documento per vederlo tutto.
Sistemi operativi (teoria completa + domande) Pag. 6
Anteprima di 10 pagg. su 329.
Scarica il documento per vederlo tutto.
Sistemi operativi (teoria completa + domande) Pag. 11
Anteprima di 10 pagg. su 329.
Scarica il documento per vederlo tutto.
Sistemi operativi (teoria completa + domande) Pag. 16
Anteprima di 10 pagg. su 329.
Scarica il documento per vederlo tutto.
Sistemi operativi (teoria completa + domande) Pag. 21
Anteprima di 10 pagg. su 329.
Scarica il documento per vederlo tutto.
Sistemi operativi (teoria completa + domande) Pag. 26
Anteprima di 10 pagg. su 329.
Scarica il documento per vederlo tutto.
Sistemi operativi (teoria completa + domande) Pag. 31
Anteprima di 10 pagg. su 329.
Scarica il documento per vederlo tutto.
Sistemi operativi (teoria completa + domande) Pag. 36
Anteprima di 10 pagg. su 329.
Scarica il documento per vederlo tutto.
Sistemi operativi (teoria completa + domande) Pag. 41
1 su 329
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

La exec in realtà non è una singola system call ma una famiglia di system call.

Le più comuni sono:

  • FILOSOFI A CENA

Un altro esempio di utilizzo dei semafori sono i cosiddetti semafori privati.

I semafori privati sono semafori dedicati ad un determinato thread che consente ad esso di sapere se può fare o meno una determinata operazione. Sono tanti quanti sono i thread che lavorano. Un thread prima di poter eseguire la sua operazione va a guardare questo semaforo assegnato a lui e se è verde la può fare, se è rosso qualche altro thread deve svegliarlo.

Facciamo un esempio effettuando la sincronizzazione di 5 filosofi a cena che alternano due attività: la prima è quella di pensare che possono fare senza chiedere il permesso agli altri (indipendente: non richiede alcun tipo di sincronizzazione) e la seconda è quella di mangiare. Per mangiare dal loro piatto devono usare 2 forchette ma le

forchette sono solo 5. La forchetta al lato sinistro di un filosofo è condivisa dal filoso che è alla sua sinistra. Non tutti i filosofi quindi possono mangiare contemporaneamente e si devono sincronizzare.

Le risorse condivise in questo caso sono le forchette. Vorremmo una situazione in cui nessun filosofo rimane a digiuno e non vorremmo invece che si verifichi un deadlock (un deadlock si potrebbe verificare se ad esempio i filosofi si sono talmente confusi da creare una situazione in cui nessuno né mangia né pensa).

Vediamo come si potrebbe verificare una situazione di deadlock:

La nostra applicazione multithread è costituita da 5 thread tutti dello stesso tipo.

i a ie a i defi i a il fil f e a c

Il motodo run() è questo while(true)(attività indipendente) e poi mangia. Pensare non comporta nessun problema di sincronizzazione. Quando poi hanno finito di pensare e vogliono mangiare, prima di mangiare hanno bisogno di accedere alle 2 forchette (che

stanno una alla sinistra e una alla destra del proprio piatto) e lo fanno attraverso due regioni critiche.

Supponiamo che quasi contemporaneamente tutti i filosofi finiscono di pensare e riescono tutti ad accedere alla propria forchetta sinistra, poi provano a prendere la forchetta destra.

Se tutti e 5 i filosofi si sono impadroniti della forchetta sinistra, le 5 forchette sono tutte impegnate e nessun filoso riesce a prendere la forchetta destra.

In questa situazione ci troviamo in una situazione di deadlock ed è una soluzione scorretta del problema.

La soluzione a questa situazione è la seguente che va implementata utilizzando isemafori. Essa consiste nel non provare a prendere separatamente la forchetta sinistra e destra, ma contemporaneamente. Quando un filosofo ha finito di mangiare, le lascia entrambe.

Andremo ad utilizzare un semaforo binario e un array di semafori. Ciascuno dei filosofi avrà un suo semaforo di riferimento che gli farà capire se può

Il tuo compito è formattare il testo fornito utilizzando tag html. ATTENZIONE: non modificare il testo in altro modo, NON aggiungere commenti, NON utilizzare tag h1; Il testo formattato con i tag html è il seguente:

mangiare; se quel semaforo privato suo è rosso deve aspettare che un altro degli altri semafori lo vada a svegliare. Le strutture di sincronizzazione sono: mutex (semaforo binario inizializzato a verde), un array di semafori privati, uno per ogni filosofo e una serie di variabili condivise che servono per capire che cosa sta succedendo.

Nell'i le e a i e dei d e e di e di_f che a() e la cia_f che a() ci ai a ll a a di i e i che c ie e e e g i fil f che e e e 0 1 o 2. a e e a l a ale a di a i i del fil f ( e il fil f a ella fa eQuesti interi di pensiero ci mettiamo in 0, se ha preso le due forchette e sta mangiando 2, se non ha ottenuto le due forchette ed è affamato 1). In questo array condiviso tutti i filosofi possono ca e c a a face d a . L a a c a c e c a e e c a LEFT e RIGHT che identificano una determinata forchetta. I nostri 5 filosofi sono identificati da un indice i e in base a questo indice riesco a capire quale è la sua forchetta destra e quella sinistra.

Le forchette sono etichettate con un numero. I filosofi vanno da 0 a 4 e anche le forchette sono identificate da un indice. Vediamo come lavorano questi due metodi. e_f() e _f() a c e a a e d ce de

Questi due metodi che sono tafilosofo che le esegue. Il filosofo zero per provare a capire se le sue forchette sono disponibili, la prima cosa che fa è attivare il metodo take_fork() con indice 0. La prima cosa che fa è assicurarsi di stare da solo e quindi di fare queste operazioni in mutua esclusione facendo un down del mutex.

Il suo stato cambia, da che stava pensando adesso è diventato affamato e attiva il metodo test. Non prende le forchette ma va prima a vedere se le forchette sono disponibili. Anche il metodo test ha un indice i, in questo caso 0.

Nel metodo test va a guardare 3 condizioni. La prima condizione sembrerebbe inutile e c ad a a da e e a affa a e ca e a c d esicuramente vera, ma siccome viene utilizzato anche per gli altri filosofi questa condizione non è

sempre vera. Dopo aver verificato questa condizione, va a guardare che cosastanno facendo i filosofi alla sua sinistra e alla sua destra.

Se sono 0 il filoso alla mia destra è 1 e quello alla mia sinistra è 4. LEFT e RIGHTa e e a d ce de f f a a a e a a de a.

Se uno dei due sta mangiando vuol dire che ha già preso una delle mie forchette o entrambe.

Se si verificano queste tre condizioni, il filosofo 0 è sicuro che le forchette che gli servono sono sul tavolo e le prende. Prenderle trasporta il filosofo 0 nello stato EATING (sta mangiando) e poi fa un up (mette la luce al verde) sul proprio semaforo privato contenutoe a a dei semafori privati (i semafori sono tutti inizializzati a rosso).

Questo up va fatto perché poi dopo nel metodo take_fork() vado a rimettere a zero tramited () e af a e a a a a e. Se a e e fa , e afpersonale non andava ad 1 e quando dopo faceva il down() il semaforo privato era già a zero e andava in wait() (ricordarsi la classe semaforo).

e rilasciare le forchette perché i filosofi vicini stanno mangiando. Alla fine, tutti i filosofi rimangono bloccati nello stato HUNGRY e il programma si blocca. Per risolvere questo problema, possiamo utilizzare un algoritmo di coordinamento chiamato "algoritmo del cameriere". In questo algoritmo, viene introdotto un cameriere che controlla il numero di filosofi che possono mangiare contemporaneamente. Il cameriere ha un limite massimo di filosofi che possono mangiare contemporaneamente e tiene traccia del numero di filosofi che stanno mangiando. Quando un filosofo vuole mangiare, deve chiedere il permesso al cameriere. Se il numero di filosofi che stanno mangiando è inferiore al limite massimo, il cameriere concede il permesso al filosofo di mangiare. Altrimenti, il filosofo deve aspettare finché uno dei filosofi che stanno mangiando non finisce di mangiare. Utilizzando l'algoritmo del cameriere, possiamo evitare il deadlock e garantire che tutti i filosofi abbiano la possibilità di mangiare.

entrambe le forchette. Chi li sveglierà?

Il filosofo 1 sarà svegliato dal filosofo 0 quando ha finito di mangiare perché quando ha finito il filosofo 0 esegue il metodo put_fork() con indice 0.

Il filosofo 0, in questo metodo ha finito di mangiare e vuole rimettersi a pensare. La prima cosa che fa è provare ad accedere alla regione critica che prova a modificare lo stato attuale di tutti i filosofi. Se ci riesce modifica il suo stato e va a fare un test sul filosofo alla sua sinistra e alla sua destra (non più su se stesso).

Il test sul filosofo 4, ovvero quello alla sinistra del filosofo 0. Se il filosofo alla sua sinistra non è HUNGRY, è inutile andare a guardare le altre cose e che ha bisogno di una forchetta (del filosofo 0) e fa il check se il filosofo 0 ha la forchetta sinistra e la lascia sul tavolo; quando poi il filosofo 4 la vorrà utilizzare lo farà.

I filosofi 1 e 2

Prima di uscire il test va fatto anche sul filosofo 1 (RIGHT) forchetta alla

sua sinistra ma non poteva prenderla perché quello 0 stava mangiando. Il filosofo 0 e 1 affamati e che la forchetta a sinistra sia disponibile, ma anche quella a destra deve essere disponibile e che lo stato del filosofo 2 sia diverso da EATING. A questo punto lo stato del filosofo 1 viene settato da quello 0 a EATING e poi sempre il filosofo 0 va a svegliare il semaforo privato del filosofo 1; stava in wait() quindi viene svegliato. Il processo viene ripetuto indefinitamente perché nel metodo main abbiamo un while(TRUE).

invece di usare l'interno pathname. È un intero maggiore di zero. A Lo standard input è un canale standard da cui giunge un flusso di dati in ingresso al programma. Il programma li trasferisce effettuando operazioni di lettura. Il file descriptor ad esso associato è 0.

Lo standard output è un canale standard su cui un programma scrive i suoi dati in output.

Il programma trasferisce i dati effettuando operazioni di scrittura. Il file descriptor ad esso associato è 1. Lo standard error è un canale standard di output tipicamente usato dai programmatori per i messaggi d'errore o di diagnostica. È indipendente dal canale standard 1, ovvero quello di output e il file descriptor ad esso associato è 2. I file standard vengono aperti dalla shell (terminale) del sistema operativo. Chiamare una read subito dopo una write, restituisce 0 perché il cursore nel file è all'ultima posizione quindi non legge niente dopo. Bisogna usare la funzione lseek che sposterà il cursore in base ai parametri che inseriamo. Questa system call inizia a scrivere da dove stavo posizionato attualmente il cursore nel file. Il primo parametro è il file descriptor del file aperto e nel quale si vuole effettuare la scrittura. Il secondo parametro è un array di caratteri di dimensione prefissata che all'interno in.

Ogni casella tiene memorizzato un carattere. Il terzo parametro indica il numero di byte da leggere dal buffer di caratteri (array di caratteri) e da scrivere nel file. Restituisce il numero di byte scritti nel file oppure restituisce -1 in caso di errore. Se non richiamo questa system call, quando viene aperto un file, il cursore è impostato di default all'inizio del file. Se per caso dopo una open si vuole scrivere con una write, le stringhe che verranno scritte nel file verranno scritte all'inizio del file, sovrascrivendo le prime stringhe e lasciando inalterate le restanti se sono presenti. Restituisce la posizione del file attuale dopo l'effetto della system call. Restituisce -1 in caso di errore.

Esempio di traduzione da indirizzo logico ad indirizzo fisico:

Vogliamo trasformare un indirizzo logico di bit in un indirizzo fisico che andrà sull'address bus costituito da 15 bit. Abbiamo la nostra memoria virtuale di 64k.

Dettagli
Publisher
A.A. 2021-2022
329 pagine
SSD Scienze matematiche e informatiche INF/01 Informatica

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher Piconsss di informazioni apprese con la frequenza delle lezioni di Sistemi operativi e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli studi della Campania "Luigi Vanvitelli" o del prof Aversa Rocco.