Mecanismos de sincronización

Optimistas

Este mecanismo debe emplearse si el programador considera que la frecuencia de acceso a un recurso compartido es baja, es decir, que supone que la probabilidad de coincidencia de dos o más procesos al recurso compartido es baja.

El siguiente ejemplo muestra el código ejecutado por dos hilos: h_x y h_y de un mismo proceso.

int tabla[3] = { 100, 101, 102 };  /* tabla compartida por ambos hilos h<sub>x</sub> y h<sub>y</sub>. */

/* actividad del hilo */
void *actividad_hilo(void *ptr)
{
        int i;

        while(1) {
            for (i=0; i<3; i++) {
                  actualiza_tabla(i);
            }
        }
        return NULL;
}

int main(void)
{
        pthread_t hilo1, hilo2;

        pthread_create(&hilo1, NULL, actividad_hilo, NULL);  /* creación hilo<sub>x</sub>. */
        pthread_create(&hilo2, NULL, actividad_hilo, NULL);  /* creación hilo<sub>y</sub>. */
        pthread_join(hilo1, NULL);
        pthread_join(hilo2, NULL);
}

void actualiza_tabla(int i) {
        int tmp;
retry:
        tmp = tabla[i];            /* almaceno el valor de la variable compartida en una temporal. */
        tmp++;                     /* actualizo la varible temporal. */
        if (tabla[i]+1 != tmp) {   /* compruebo si la variable compartida ha sido modificada */
            goto retry;            /* mientras operaba con la variable temporal. */
        }
        tabla[i]=tmp;
}

Los inconvenientes de este tipo de mecanismo son dos:

• Se consume más memoria, pues hay que realizar una copia del recurso compartido para efectuar la comprobación.
• En situaciones de coincidencia, se tiene que volver a realizar la operación, por tanto, se desperdician recursos de procesamiento.
• En base al ejemplo anterior, hay que garantizar que la operación actualiza_tabla es atómica.

Por último, si el programador ha empleado una aproximación optimista para una situación en la que la frecuencia de coincidencia es alta, podría darse el caso de que un hilo no progrese en su ejecución de manera indefinida, al tener que volver a reintentar la actualización una y otra vez hasta conseguirlo sin que haya concurrencia.

Pesimista

Este mecanismo debe emplearse si se considera que la frecuencia de acceso al recurso compartido es alta.

En este mecanismo disponemos de tres partes:

• El protocolo de entrada, en el que se emplea un mecanismo que no permite continuar con la ejecución si otro u otros procesos están accediendo al recurso compartido.
• La sección crítica, en el que se se realizan las operaciones pertinentes con el recurso compartido.
• El protocolo de salida, en el que se vuelve a permitir el acceso al recurso compartido.

El siguiente ejemplo muestra como se implementa el control de concurrencia pesimista para 2 hilos, h_x y h_y:

   int compartida = 1;
   protocolo_de_entrada();     /* no permito acceso a variable compartida. */
   compartida++;               /* sección crítica: actualización de la variable compartidad. */
   protocolo_de_salida();      /* vuelvo a permitir acceso a la variable compartida. */

Los protocolos de entrada y salida son, generalmente, operaciones costosas en términos de recursos de procesamiento.

El inconveniente de este mecanismo es:

• Que aunque siempre se pueda implementar, se fuerzan esperas que pueden llegar a ser innecesarias.

Por último, se podría emplear un control de concurrencia pesimista para resolver un problema que se resuelve con un control de concurrencia optimista, pero no al revés.

Implementación del control de concurrencia pesimista

El control de concurrencia pesimista se puede implementar de dos formas mediante:

• Espera ocupada o activa, mediante cerrojos. En este mecanismo se comprueba continuamente la condición que permite franquear en el protocolo de entrada, por tanto, el proceso permanece en estado activo comprobando continuadamente la condición que le permite progresar en su ejecución, tiempo que está siendo desaprovechado por el procesador.
• Espera no ocupada o bloqueante, mediante semáforos, monitores y mensajes. Estos mecanismos hacen que el proceso pase a estado bloqueado cuando no se puede franquear el protocolo de entrada, por tanto, al quedar un proceso que no puede progresar en estado bloqueado, el planificador de procesos tiene que seleccionar a otro proceso.