In tema di accesso concorrenziale alle risorse, può presentarsi (come è successo a me) il problema noto come
problema dei lettori e degli scrittori.
In realtà i problemi sono due.
Scenario Supponiamo di avere una memoria condivisa, e più thread al lavoro su di essa.
Alcuni thread vorranno accedervi soltanto in lettura, altri in scrittura.
E' chiaro che l'accesso alla memoria deve essere esclusivo, cioè non può accadere che i thread lettori possano accedere alla memoria condivisa insieme ad i thread scrittori. In particolare, più thread lettori possono avere accesso alla memoria simultaneamente, ma gli scrittori necessitano di mutua esclusione anche tra di loro.
Primo problema Potremmo proteggere l'accesso alla memoria tramite un mutex; in questo caso ovviamente nessun thread lettore potrebbe accedere alla memoria nello stesso momento di un thread scrittore, ed il problema sarebbe risolto.
Peccato che la soluzione non sia ottimale. Un lettore R1 potrebbe bloccare il mutex, ed un altro lettore R2 richiedere l'accesso. E' scocciante che il lettore R2 debba aspettare che R1 termini il suo lavoro per poter iniziare il proprio. Sarebbe meglio farlo lavorare immediatamente.
Questo è il primo problema dei lettori/scrittori:
nessun thread lettore deve restare in attesa se la risorsa è in uso in lettura. Anche noto come
precedenza ai lettori.
Secondo problema Supponiamo di proteggere l'accesso alla memoria tramite un mutex e di dare la precedenza ai lettori; la soluzione non sarebbe ancora ottimale.
Un lettore R1 potrebbe ottenere l'accesso alla memoria, uno scrittore W potrebbe essere in attesa del suo turno e potrebbe arrivare un altro lettore R2; secondo quanto detto poco fa, il lettore R2 dovrebbe immediatamente mettersi al lavoro, scavalcando l'attesa di W.
A questo punto W rischierebbe di restare in attesa in eterno (o comunque molto a lungo) finchè ci saranno lettori a richiedere l'accesso alla memoria.
Al contrario, W dovrebbe iniziare a lavorare quanto prima.
Questo è il secondo problema dei lettori/scrittori:
nessuno scrittore, una volta messo in coda, dovrà aspettare più a lungo del necessario. Noto anche come
precedenza agli scrittori.
Una soluzione al problema potrebbe essere quella di mettere in attesa i lettori in arrivo se ci sono già scrittori in attesa; prima o poi i lettori al lavoro cesseranno di lavorare e l'ultimo a farlo risveglierà uno scrittore tra quelli in attesa. Ogni scrittore, al termine del suo lavoro, dovrà sbloccare alcuni (o tutti) lettori in attesa.
Io ho scelto di utilizzare un parametro (r_per_w, cioè readers per writers: quanti lettori sbloccare al termine di ogni scrittore).
Di seguito un mio codice di esempio (in C):
mutex_t m;
semaphore_t sem_r, sem_w;
int waiting_r, waiting_w, working_r, working_w;
int r_per_w = 5;
// Tentativo di accesso in lettura
void read_lock()
{
lock(m);
if (waiting_w || working_w)
waiting_r++;
else
{
working_r++;
if (working_r) == 1 down(sem_w);
up(sem_r);
}
unlock(m);
down(sem_r);
}
void read_unlock()
{
lock(m);
working_r--;
if (working_r == 0) up(sem_w);
unlock(m);
}
void write_lock()
{
lock(m);
if (working_r == 0 && working_w == 0)
working_w++;
else
waiting_w++;
unlock(m);
down(sem_w);
}
void write_unlock()
{
int n;
lock(m);
working_w--;
if (waiting_r)
{
if (waiting_w)
n = waiting_r > r_per_w ? r_per_w : waiting_r;
else
n = waiting_r;
while (n)
{
waiting_r--;
up(sem_r);
n--;
}
}
else
up(sem_w);
unlock(m);
}
Siiiiiiiii sto mettendo mani in un Cisco!!!
