Revisión del 02:20 25 nov 2017

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 hx y hy. */

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

        while(1) {
            for (i=0; i<3; i++) {
                  actualiza_tabla(i);
                  sleep((random() % 10) + 1);    /* hilo pasa a estado bloqueado durante 1 a 10 segundos. */
            }
        }
        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 actualizació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 de comprobación y actualización es atómica. Se dice que una operación es atómica cuando es indivisible, es decir, que no quedamos en una situación intermedia al ejecutar dicha operación.

Como ventaja, este tipo de mecanismo nos ofrece un mayor grado de paralelismo, por tanto, una mayor tasa de transferencia, siempre que se emplee en una situación donde la frecuencia de concurrencia sea baja.

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.

Un mecanismo de sincronización optimista funciona de la siguiente manera:

• Paso 1. Realiza una copia del estado en el que está el recurso compartido.
• Paso 2. Opera con esa copia.
• Paso 3. Compruebo si mi copia alterada coincide con el original aplicándole también el tratamiento.

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 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 compartida. */
   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, pues requieren el uso de instrucciones atómicas cuyo tiempo de ejecución es alto.

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 o mensajería. 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.

Nota aclarativa: Definición de espera ocupada o activa

Esperar a que algo ocurra realizando continuas comprobaciones. Ejemplo:

           …
           variable= 0;
           while(variable==0);
           …

6.3 Cerrojos