Diferencia entre revisiones de «Mecanismos de sincronización»
| Línea 2: | Línea 2: | ||
== Optimista== | == Optimista== | ||
Se considera que la frecuencia de acceso a un recurso compartido es baja, es decir, suponemos que la probabilidad de acceso simultanea a un recurso compartido es baja. | Se considera que la frecuencia de acceso a un recurso compartido es baja, es decir, suponemos que la probabilidad de acceso simultanea a un recurso compartido es baja. | ||
| − | Ejemplo de control optimista suponiendo 2 hilos, hx y hy. | + | |
| − | + | <font color="DarkGreen">/*Ejemplo de control optimista suponiendo 2 hilos, hx y hy.*/</font><br/> | |
| − | + | <font color="#0000FF">int</font> compartida = 1, tmp; | |
| − | + | retry: | |
| − | tmp = compartida; /* anoto */ | + | tmp = compartida; <font color="DarkGreen">/* anoto */</font> |
| − | tmp++; /* actualizo temporal */ | + | tmp++; <font color="DarkGreen">/* actualizo temporal */</font> |
| − | if(compartida+1 != tmp) | + | <font color="#0000FF">if</font>(compartida+1 != tmp) |
| − | + | <font color="#0000FF">goto</font> retry; <font color="DarkGreen">/* compruebo si la variable compartida ha sido modificada mientras operaba con el temporal */</font> | |
Los inconvenientes de este tipo de mecanismo es su elevado recurso de memoria, ya que se debe tener una copia del recurso compartido y efectuar la comprobación, y su alto recurso de procesamiento, al tener que volver a realizar la operación. Por esto último, puede darse el caso de que un hilo esté sin progresar durante un tiempo indefinido, si se da el caso de que siempre que se le agote el tiempo de procesador asignado debido a que otro hilo modifique el recurso compartido. | Los inconvenientes de este tipo de mecanismo es su elevado recurso de memoria, ya que se debe tener una copia del recurso compartido y efectuar la comprobación, y su alto recurso de procesamiento, al tener que volver a realizar la operación. Por esto último, puede darse el caso de que un hilo esté sin progresar durante un tiempo indefinido, si se da el caso de que siempre que se le agote el tiempo de procesador asignado debido a que otro hilo modifique el recurso compartido. | ||
| Línea 21: | Línea 21: | ||
(Toda operación con una variable compartida necesita un protocolo de entrada y otro de salida) | (Toda operación con una variable compartida necesita un protocolo de entrada y otro de salida) | ||
| − | Ejemplo de control pesimista suponiendo 2 hilos, hx y hy | + | |
| − | + | <font color="DarkGreen">/*Ejemplo de control pesimista suponiendo 2 hilos, hx y hy*/</font><br/> | |
| − | + | <font color="#0000FF">int</font> compartida = 1; | |
| − | + | no_permito_acceso_variable_compartida(); <font color="DarkGreen">/* protocolo de entrada */</font> | |
| − | + | 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 E/S en el control de concurrencia pesimista?''' | '''¿Cómo implementamos el protocolo de E/S en el control de concurrencia pesimista?''' | ||
Revisión del 21:01 28 mar 2011
Tipos de mecanismos de sincronización :
Optimista
Se considera que la frecuencia de acceso a un recurso compartido es baja, es decir, suponemos que la probabilidad de acceso simultanea a un recurso compartido es baja.
/*Ejemplo de control optimista suponiendo 2 hilos, hx y hy.*/
int compartida = 1, tmp; retry: tmp = compartida; /* anoto */ tmp++; /* actualizo temporal */ if(compartida+1 != tmp) goto retry; /* compruebo si la variable compartida ha sido modificada mientras operaba con el temporal */
Los inconvenientes de este tipo de mecanismo es su elevado recurso de memoria, ya que se debe tener una copia del recurso compartido y efectuar la comprobación, y su alto recurso de procesamiento, al tener que volver a realizar la operación. Por esto último, puede darse el caso de que un hilo esté sin progresar durante un tiempo indefinido, si se da el caso de que siempre que se le agote el tiempo de procesador asignado debido a que otro hilo modifique el recurso compartido.
Pesimista
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)
/*Ejemplo de control pesimista suponiendo 2 hilos, hx y hy*/
int compartida = 1; no_permito_acceso_variable_compartida(); /* protocolo de entrada */ compartida++; /* sección crítica */ permito_acceso_a_variable_compartida(); /* protocolo de salida */
¿Cómo implementamos el protocolo de E/S en el control de concurrencia pesimista?
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.
¿Cómo implementar el control de concurrencia pesimista?
- Espera ocupada/activa : cerrojos. Se comprueba continuamente la condición que permite franquear el protocolo de entrada
- Espera no ocupada/no activa : semáforos, monitores y mensajes. Se pasa a estado bloqueado cuando no se puede franquear el protocolo de entrada.
