Wiki de Sistemas Operativos - Contribuciones del usuario [es]

Página con listado de personas que han contribuido

2012-01-27T18:29:50Z

Antdomflo: me añado

A continuación, la lista de usuarios/as de la Universidad de Sevilla que han contribuido a la wiki. Si ponéis tu usuario/a estás solicitando al profesor que evalúe tus contribuciones a la wiki para la subida de notas de hasta 2 puntos posible:

* luigarhor
* rafperper
* sergaralo
* josalgrod1
* felgaroje
* luimunlei
* [https://1984.lsi.us.es/wiki-ssoo/index.php/Usuario:Lorruimor Lorruimor]
* albsolnog
* framorexp
* javgarang
* FerGuaTol
* jesgonbel
* fraperdom
* antdomflo

FAT

2012-01-21T18:53:15Z

Antdomflo: /* FAT 32 */ hiperenlace cluster

==Estructura==

Se dispone de la tabla de asignación de ficheros (File Allocation Table, de ahí las siglas FAT) en la que cada entrada de la tabla representa un bloque del disco. Cada entrada puede tener uno de los siguientes valores:

*Bloque libre: FREE
*Bloque defectuoso: BAD
*Último bloque de un archivo: EOF
*Cualquier otro número: bloque asignado, y el número es el número del siguiente bloque
*Entradas 0 y 1: reservadas

[[Archivo:Fat.png|Estructura FAT|center|border|600px]]

Nota: Si alguien quiere editar la imagen para mejorarla: [[https://docs.google.com/drawings/d/1CJlmPagvZl989yUOR41GBqZBL2afKt3gxxvYVkf57NU/edit?hl=en_US| Editar imagen]] --[[Usuario:Robertomartin|Robertomartin]] 12:19 6 jun 2011 (UTC)

==FAT 32==

FAT32 fue la respuesta para superar el límite de tamaño de FAT16 al mismo tiempo que se mantenía la compatibilidad con MS-DOS en modo real. Microsoft decidió implementar una nueva generación de FAT utilizando direcciones de cluster[http://es.wikipedia.org/wiki/Cl%C3%BAster_%28sistema_de_archivos%29] de 32 bits (aunque sólo 28 de esos bits se utilizaban realmente).

En teoría, esto debería permitir aproximadamente 268.435.538 clusters, arrojando tamaños de almacenamiento cercanos a los ocho terabytes. Sin embargo, debido a limitaciones en la utilidad ScanDisk de Microsoft, no se permite que FAT32 crezca más allá de 4.177.920 clusters por partición (es decir, unos 124 gigabytes). Posteriormente, Windows 2000 y XP situaron el límite de FAT32 en los 32 gigabytes. Microsoft afirma que es una decisión de diseño, sin embargo, es capaz de leer particiones mayores creadas por otros medios.

FAT32 apareció por primera vez en Windows 95 OSR2. Era necesario reformatear para usar las ventajas de FAT32. Curiosamente, DriveSpace 3 (incluido con Windows 95 y 98) no lo soportaba. Windows 98 incorporó una herramienta para convertir de FAT16 a FAT32 sin pérdida de los datos. Este soporte no estuvo disponible en la línea empresarial hasta Windows 2000.

El '''tamaño máximo de un archivo en FAT32''' es 4 gigabytes (2^32−1 bytes), lo que resulta engorroso para aplicaciones de captura y edición de video, ya que los archivos generados por éstas superan fácilmente ese límite.

http://www.pjrc.com/tech/8051/ide/fat32.html

FAT

2012-01-21T18:52:29Z

Antdomflo: /* FAT 32 */ definicion cluster

==Estructura==

Se dispone de la tabla de asignación de ficheros (File Allocation Table, de ahí las siglas FAT) en la que cada entrada de la tabla representa un bloque del disco. Cada entrada puede tener uno de los siguientes valores:

*Bloque libre: FREE
*Bloque defectuoso: BAD
*Último bloque de un archivo: EOF
*Cualquier otro número: bloque asignado, y el número es el número del siguiente bloque
*Entradas 0 y 1: reservadas

[[Archivo:Fat.png|Estructura FAT|center|border|600px]]

Nota: Si alguien quiere editar la imagen para mejorarla: [[https://docs.google.com/drawings/d/1CJlmPagvZl989yUOR41GBqZBL2afKt3gxxvYVkf57NU/edit?hl=en_US| Editar imagen]] --[[Usuario:Robertomartin|Robertomartin]] 12:19 6 jun 2011 (UTC)

==FAT 32==

FAT32 fue la respuesta para superar el límite de tamaño de FAT16 al mismo tiempo que se mantenía la compatibilidad con MS-DOS en modo real. Microsoft decidió implementar una nueva generación de FAT utilizando direcciones de [http://es.wikipedia.org/wiki/Cl%C3%BAster_%28sistema_de_archivos%29|cluster] de 32 bits (aunque sólo 28 de esos bits se utilizaban realmente).

En teoría, esto debería permitir aproximadamente 268.435.538 clusters, arrojando tamaños de almacenamiento cercanos a los ocho terabytes. Sin embargo, debido a limitaciones en la utilidad ScanDisk de Microsoft, no se permite que FAT32 crezca más allá de 4.177.920 clusters por partición (es decir, unos 124 gigabytes). Posteriormente, Windows 2000 y XP situaron el límite de FAT32 en los 32 gigabytes. Microsoft afirma que es una decisión de diseño, sin embargo, es capaz de leer particiones mayores creadas por otros medios.

FAT32 apareció por primera vez en Windows 95 OSR2. Era necesario reformatear para usar las ventajas de FAT32. Curiosamente, DriveSpace 3 (incluido con Windows 95 y 98) no lo soportaba. Windows 98 incorporó una herramienta para convertir de FAT16 a FAT32 sin pérdida de los datos. Este soporte no estuvo disponible en la línea empresarial hasta Windows 2000.

El '''tamaño máximo de un archivo en FAT32''' es 4 gigabytes (2^32−1 bytes), lo que resulta engorroso para aplicaciones de captura y edición de video, ya que los archivos generados por éstas superan fácilmente ese límite.

http://www.pjrc.com/tech/8051/ide/fat32.html

Mecanismos de sincronización

2011-12-08T12:32:48Z

Antdomflo: /* Implementación del control de concurrencia pesimista */ corrección2

= 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.

<source lang="c">
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 hilox. */
pthread_create(&hilo2, NULL, actividad_hilo, NULL); /* creación hiloy. */
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;
}
</source>

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.

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

<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 compartida. */
protocolo_de_salida(); /* vuelvo a permitir acceso a la variable compartida. */
</source>

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);
…

Mecanismos de sincronización

2011-12-08T12:32:01Z

Antdomflo: /* Implementación del control de concurrencia pesimista */ resalto

= 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.

<source lang="c">
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 hilox. */
pthread_create(&hilo2, NULL, actividad_hilo, NULL); /* creación hiloy. */
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;
}
</source>

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.

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

<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 compartida. */
protocolo_de_salida(); /* vuelvo a permitir acceso a la variable compartida. */
</source>

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);
…

Mecanismos de sincronización

2011-12-08T12:31:22Z

Antdomflo: /* Implementación del control de concurrencia pesimista */ correcció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: hx y hy de un mismo proceso.

<source lang="c">
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 hilox. */
pthread_create(&hilo2, NULL, actividad_hilo, NULL); /* creación hiloy. */
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;
}
</source>

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.

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

<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 compartida. */
protocolo_de_salida(); /* vuelvo a permitir acceso a la variable compartida. */
</source>

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);
…

Mecanismos de sincronización

2011-12-08T12:30:52Z

Antdomflo: /* Implementación del control de concurrencia pesimista */ espera

= 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.

<source lang="c">
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 hilox. */
pthread_create(&hilo2, NULL, actividad_hilo, NULL); /* creación hiloy. */
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;
}
</source>

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.

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

<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 compartida. */
protocolo_de_salida(); /* vuelvo a permitir acceso a la variable compartida. */
</source>

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);
…

Mecanismos de sincronización

2011-12-08T12:29:23Z

Antdomflo: /* Implementación del control de concurrencia pesimista */ aclaracion

= 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.

<source lang="c">
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 hilox. */
pthread_create(&hilo2, NULL, actividad_hilo, NULL); /* creación hiloy. */
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;
}
</source>

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.

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

<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 compartida. */
protocolo_de_salida(); /* vuelvo a permitir acceso a la variable compartida. */
</source>

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);
…