Diferencia entre revisiones de «Mecanismos de sincronización»

De Wiki de Sistemas Operativos
Saltar a: navegación, buscar
(Optimistas: ejemplo)
(Pesimista: revisión)
Línea 21: Línea 21:
 
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.
 
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==
+
= Pesimista =
Se considera que la frecuencia de acceso al recurso compartido es alta.
+
Este mecanismo debe emplear si se considera que la frecuencia de acceso al recurso compartido es alta.
En este mecanismo disponemos de tres partes :
 
*Un protocolo de entrada : en el cual se restringe el permiso de acceso para las variables compartidas.
 
*Una sección crítica : donde se realizan todas las operaciones con las variables compartidas.
 
*Un protocolo de salida : en el cual se restablece el permiso de acceso para las variables compartidas.
 
  
(Toda operación con una variable compartida necesita un protocolo de entrada y otro de salida)
+
En este mecanismo disponemos de tres partes:
  
<font color="DarkGreen">/*Ejemplo de control pesimista suponiendo 2 hilos, hx y hy*/</font><br/>
+
* El protocolo de entrada, en el que se emplea un mecanismo que no permite continuar con la ejecución si otro y otros procesos están accediendo al recurso compartido.
  <font color="#0000FF">int</font> compartida = 1;
+
* La sección crítica, en el que se se realizan las operaciones pertinentes con el recurso compartido.
        no_permito_acceso_variable_compartida();      <font color="DarkGreen">/* protocolo de entrada */</font>
+
* El protocolo de salida, en el que se vuelve a permitir el acceso al recurso compartido.
                compartida++;                      <font color="DarkGreen">/* sección crítica */</font>
 
        permito_acceso_a_variable_compartida();  <font color="DarkGreen">/* protocolo de salida */</font>
 
  
'''¿Cómo implementamos el protocolo de entrada y salida en el control de concurrencia pesimista?'''
+
El siguiente ejemplo muestra como se implementa el control de concurrencia pesimista para 2 hilos, h<sub>x</sub> y h<sub>y</sub>:
  
Interrumpiendo la conmutación, desactivando las interrupciones, seguidamente ejecutando la sección crítica y finalmente permitiendo el acceso a las variables compartidas y activando las interrupciones.
+
<source lang="c">
 +
  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. */
 +
</source>
  
'''¿Cómo implementar el control de concurrencia pesimista?'''
+
Los protocolos de entrada y salida son, generalmente, operaciones costosas en términos de recursos de procesamiento.
  
*Espera ocupada/activa : cerrojos. Se comprueba continuamente la condición que permite franquear el protocolo de entrada
+
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.
*Espera no ocupada/no activa : semáforos, monitores y mensajes. Se pasa a estado bloqueado cuando no se puede franquear el protocolo de entrada.
+
 
 +
== 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.
 +
* 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 y, de esta manera, no se

Revisión del 09:37 30 mar 2011

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: hx y hy de un mismo proceso.

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

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.

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 emplear 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 y 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, hx y hy:

   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.

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.
  • 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 y, de esta manera, no se