====== Esercitazione 12 ======

===== Esercizio 1 =====

Estendere l'Esercizio 1 dell'[[informatica:sol:laboratorio17:esercitazionib:esercitazione8|Assegnamento8]] (M thread produttori ed N thread consumatori) in modo tale da  gestire il segnale SIGUSR1. In particolare, se il processo riceve il segnale SIGUSR1 dovra' essere stampato sullo standard output: 1) la lunghezza corrente della coda, 2) gli elementi che sono nella coda in quel momento.

SUGGERIMENTO: utilizzare un thread dedicato che fa da gestore unico del segnale SIGUSR1 utilizzando la chiamata di libreria ''sigwait''.

===== Esercizio 2 =====

Supponiamo di dover implementare un server concorrente che fornisce il servizio di repository di oggetti.  Le richieste servite dal server hanno il formato: //<op, <key, object>>//. L'operazione //op// puo' essere: //GET//, //PUT//, //REMOVE//, //UPDATE//. //key// e' una chiave numerica (es. 1, 1000, 200, ...), mentre //object// è una sequenza di bytes (>0) non tipata (un oggetto puo' essere un file, un area di memoria, etc.).
//PUT// inserisce l'//object// con la chiave //key// nel repository, //GET// permette di recuperare l'oggetto fornendo la chiave, //REMOVE// di cancellare l'oggetto con la data chiave ed infine //UPDATE// di aggiornare l'oggetto memorizzato nel server. 
Nell'implementazione deve essere utilizzata come struttura dati una tabella hash (ad esempio {{informatica:sol:laboratorio17:esercitazionib:icl_hash.tgz| questa}} ).
  - Scrivere una libreria che implementa le operazioni PUT/GET/REMOVE/UPDATE sulla tabella hash tenendo conto che ogni funzione puo' essere invocata da piu' thread concorrentemente.
  - Pensare ad una soluzione che non utilizzi 1 sola variabile di mutua esclusione per tutta la tabella hash. Ad esempio, se il server utilizza //k// thread workers, utilizzare //m//>//k// variabili di mutex. 
  - Ci sono sequenze di operazioni che possono portare ad inconsistenze se non opportunamente gestite? Se si come si puo' fare a risolverle?