MUTEXES

Shibu lijack

Un mutex es una variable que puede estar en uno de dos estados: desbloqueado o bloqueado. Por ello, solo se necesita un bit para representarlo, aunque en la practica es comn que se utilice un entero, de tal modo que 0 signifique desbloqueado y todos los dems valores signifiquen bloqueado.

Se usan dos procedimientos con mutexes. Cuando un subproceso ( o proceso) necesita obtener acceso a una regin critica, invoca a mutex_lock. Si el mutex esta desbloqueado (o sea que la regin critica esta disponible), la llamada procede y el subproceso invocador puede entrar en la regin critica. En cambio, si el mutex esta bloqueado, el subproceso invocador se bloqueara hasta que el subproceso que esta en la regin critica termine e invoque a mutex_unlock. Si hay varios subprocesos bloqueados en espera en el mutex, se escoge uno de ellos al azar y se le permite adquirir el bloqueo.

Por su sencillez, es fcil implementar los mutexes en espacio de usuario, si se cuenta con una instruccin TSL.

El cdigo mutex_lock es similar al de entrar_region, pero con una gran diferencia crucial. Cuando entrar_region no logra entrar en la regin critica, sigue probando el bloqueo una y otra vez. En algn momento llegara una interrupcin de reloj y se calendarizara otro proceso para ejecutarse. Tarde o temprano el proceso que tiene el bloqueo podr ejecutarse y lo liberara.

Con los threads, la situacin es diferente debido a que no existe ningn reloj que detenga a los threads que se han ejecutado durante demasiado tiempo. Consecuentemente, un thread que intenta apropiarse de un cerrojo mediante espera activa, permanecer por siempre en el bucle de espera y nunca conseguir el cerrojo debido a que no est permitiendo que se ejecute ningn otro thread y que se libere el cerrojo. Aqu es donde se presenta la diferencia entre entrar_en_regin y mutex_lock. Cuando mutex_lock falla intentando apropiarse del cerrojo, llama a thread_yield para ceder la CPU a otro thread. Consecuentemente no existe espera activa. La prxima vez que se ejecute el thread, volver a comprobar el cerrojo.

Ya que thread_yield es precisamente una llamada al thread planificador en el espacio de usuario, se ejecuta muy rpidamente. Como consecuencia, ni mutex_lock ni mutex_unlock requieren ninguna llamada al ncleo.
De esta manera, mediante el uso de esas dos primitivas los threads a nivel de usuario pueden sincronizarse enteramente dentro del espacio de usuario, utilizando procedimientos que requieren tan slo un puado de instrucciones.

Si dos o ms procesos comparten la mayora o incluso todo su espacio de direcciones, la distincin entre procesos y threads queda un poco difuminada pero sin embargo sigue presente.

Dos procesos que comparten un espacio de direcciones comn todava tienen diferentes ficheros abiertos, alarmas de temporizacin y otras propiedades propias de los procesos. Los threads dentro de un mismo proceso comparten todas esas caractersticas. Varios procesos que comparten un espacio de direcciones comn nunca consiguen la eficiencia de los threads a nivel del usuario ya que el ncleo est profundamente involucrado en su gestin.