Mutex: differenze tra le versioni
m Annullate le modifiche di 195.223.231.98 (discussione), riportata alla versione precedente di 87.12.244.112 Etichetta: Rollback |
Recupero di 1 fonte/i e segnalazione di 0 link interrotto/i.) #IABot (v2.0 |
||
Riga 39: | Riga 39: | ||
== Collegamenti esterni == |
== Collegamenti esterni == |
||
* [http://www.disi.unige.it/person/GianuzziV/SysOp/lucidi/13_mutua.html Mutua Esclusione Distribuita] ([[Sito web|sito]] dell'[[Università degli Studi di Genova|università di Genova]]) |
* [https://web.archive.org/web/20050818030945/http://www.disi.unige.it/person/GianuzziV/SysOp/lucidi/13_mutua.html Mutua Esclusione Distribuita] ([[Sito web|sito]] dell'[[Università degli Studi di Genova|università di Genova]]) |
||
{{Portale|informatica}} |
{{Portale|informatica}} |
Versione delle 15:22, 14 ott 2019
In informatica il termine mutex (contrazione dell'inglese mutual exclusion, mutua esclusione) indica un procedimento di sincronizzazione fra processi o thread concorrenti, con il quale si impedisce che più task paralleli accedano contemporaneamente ai dati in memoria o ad altre risorse soggette a race condition (o corsa critica). Questo concetto riveste importanza fondamentale nella programmazione parallela e soprattutto per i sistemi di transazione.
Condizioni
Affinché sia possibile la mutua esclusione occorrono sei condizioni:
- un solo processo o thread accede alla sezione critica;
- nessun processo può bloccarsi in sezione critica;
- evitare deadlock e starvation;
- nessuna assunzione sulla velocità dei processi;
- nessun processo fuori dalla sezione critica può impedire ad un altro di entrare;
- accesso alla sezione critica consentito in un tempo definito.
Tecnica
Per realizzare l'esclusione reciproca si assegna ad un oggetto o porzione di programma (sezione critica) un elemento che va sempre controllato prima che un processo o thread possa eseguire istruzioni sull'oggetto stesso. Se un processo o thread sta già accedendo all'oggetto, tutti i successivi devono aspettare che il primo finisca. Gli oggetti mutex utilizzati per coordinare processi diversi devono essere di per sé accessibili a tutti i processi coinvolti, il che implica necessariamente l'uso di memoria condivisa, oppure gestita direttamente dal sistema operativo.
Per realizzare ciò, la procedura di utilizzo di una risorsa critica deve essere strutturata nelle seguenti fasi:
- Richiesta
- Sezione Critica
- Rilascio
All'avvio, mediante la fase di richiesta, il processo verifica se un altro processo sta utilizzando la sezione critica. Al termine, mediante la fase di rilascio, il processo segnala che la risorsa critica utilizzata è libera e dunque utilizzabile da un altro processo.
Implementazioni
L'implementazione più comune dei mutex fa uso di monitor, ma lo stesso risultato si può ottenere anche per mezzo di semplici lock o semafori (un mutex può essere visto come caso particolare di semaforo, precisamente inizializzato ad uno). È spesso possibile migliorare la tecnica di accesso con l'ausilio di lock read/write che consentono un numero illimitato di accessi in lettura ma uno solo in scrittura. Questa tecnica è impiegata soprattutto per regolare l'accesso ai file e alle banche dati.
Per implementare un mutex in maniera efficiente è necessario che il sistema operativo offra uno scheduler adatto. Senza questa predisposizione, ed in particolare su molti sistemi operativi real-time, bisogna ricorrere a spinlock che però riducono l'efficienza del multitasking poiché utilizzano il processore durante le attese.
Supporto
Alcuni linguaggi di programmazione offrono la tecnica mutex come parte del linguaggio stesso, in particolare Ada, Java e i linguaggi di programmazione .NET. Per quasi tutti gli altri linguaggi esistono librerie che implementano il sistema mutex. Questo può essere integrato come parte dell'API o dell'ambiente runtime.
Problematiche
L'esclusione reciproca comporta il rischio di deadlock, situazione in cui più task si bloccano vicendevolmente e nessuno può più proseguire (starvation). Il problema dei filosofi a cena è un esempio di questa circostanza. Esistono algoritmi speciali per raggirare questo inconveniente (algoritmo di Peterson, algoritmo di Dekker) che si può facilmente evitare ponendo cura alla programmazione.