PDF de programación - Sistemas operativos - Sincronización y comunicación entre procesos

SISTEMAS OPERATIVOS

SINCRONIZACIÓN Y COMUNICACIÓN

ENTRE PROCESOS

Francisco Rosales
<[email protected]>

ÍNDICE

© UPM 2016

Concurrencia, compartición y coordinación
Mecanismos de sincronización y modelos clásicos
Mecanismos de comunicación local y remota
Interbloqueos

Siglas y definiciones:
PL
PP
MC
BD
sii
Thread Flujo de ejecución deun
proceso pesado o ligero

Proceso Ligero o thread
Proceso Pesado
Memoria Compartida
Base de Datos
Si y sólo si

2

CONCURRENCIA

EJECUCIÓN CONCURRENTE

© UPM 2016

Sucede a muchos niveles:

Concurrencia hardware

Concurrencia software

Unidades funcionales del
procesador

Superescalar
HyperThreading

Procesador y dispositivos E/S
Multiprocesador =

N procesadores
+ memoria compartida
Número de Cores

Multicomputador =

N nodos de cómputo
+ red de interconexión

micro

Múltiples threads
en un proceso (procesos ligeros)

Multiprogramación
de un procesador

macro

Aplicación paralela

4

LA "CONDICIÓN DE CARRERA"

© UPM 2016

El acceso concurrente SIN coordinación a recursos compartidos
puede NO producir los resultados esperados
Porque...

NO se puede (ni debe) garantizar la velocidad relativa de los procesos
concurrentes (== el orden en que ejecutan)

1

lee

Ej. Procesos remotos & Transacción bancaria
1'

BBDD

lee

saldo = saldo – 20 €

3

escribe

2

resta

Pepe: 120 €

saldo = saldo + 1000 €
3'

escribe

2'

suma

¿Resultado de Pepe? 1100 o 1120 o 100

La sentencia de alto nivel más simple requiere varias instrucciones máquina

a++;

Ej. Threads & Memoria compartida
a: 0x000A
load R1, [0x000A]
add R1, 1
store R1, [0x000A]

333

¿Resultado? 5 o 4

Interrupción

1
5
6

2
3
4

5

LA "SECCIÓN CRÍTICA"

© UPM 2016

Segmentos de código susceptibles de contener

una condición de carrera

Ej.

int a; /* compartida */
<<Entrada a sección crítica>> _______________
a = a + 1;
<<Salida de sección crítica>> _______________

Protegeremos la sección crítica con mecanismos de sincronizaciónque
deberán garantizar:

Exclusión mutua: sólo entra un thread al tiempo. Esto implica que los
threads deben esperar a que esté libre la sección crítica
Progreso: un thread fuera no impide que otro entre
Espera acotada: sii espero, entraré en tiempo finito

Los mecanismos de sincronización detienen la ejecución produciendo
contención.Al programar deberemos:

Retener los recursos el menor tiempo posible (menor contención
posible)
No quedar bloqueados dentro de la sección crítica
En definitiva: coordinar el acceso a recursos compartidos

6

COORDINACIÓN EN ACCESO A RECURSOS

© UPM 2016

Implícita: la realiza el SO (gestor de recursos)

Procesos independientes
Compiten por recursos (pero lo ignoran)
Control de acceso transparente y asociado al recurso

Ej.
Ej.

Procesos pesados (PPs) y... ¡¡cualquier recurso!! hw o sw
PPs y coutilización de fichero  el fichero no se corrompe
pero ¡la información contenida puede no ser coherente!

Explícita: la realizan los procesos

Procesos cooperantes
Comparten recursos (son conscientes de ello)
Coordinan el acceso al recurso, y para ello...
Usan mecanismos de sincronización y/o comunicaciónproporcionados
por: el SO, una biblioteca o el lenguaje

Procesos ligeros (PLs) y variables en memoria compartida
PPs y coutilización de fichero como BD  fichero OK

Ej.
Ej.
e información contenida coherente
Ej.

Procesos distribuidos colaborando para jugar al mus en red



7

MECANISMOS DE SINCRONIZACIÓN

© UPM 2016

Permiten resolver la sección crítica

(== coordinar el acceso a un recurso compartido)

Para procesos fuertemente acoplados (== que comparten memoria)

Semáforos (adecuado para PPs con MC)
Mutex y Condiciones (adecuado para PLs)
Otros propios de lenguajes concurrentes (Monitores)

...se suelen poner a prueba aplicados a “modelos clásicos"

Para procesos independientes

Semáforos, sii son servicio del SO
Cerrojos sobre (regiones de) fichero

La sincronización conlleva espera. En general, esta espera será pasiva
(sin consumir ciclos de procesador)

8

PASOS EN LA RESOLUCIÓN DE UN PROBLEMA

© UPM 2016

Definir la información que se comparte

Buffer circular
Registros con campos de tamaño fijo
Registros con campos de tamaño variable
...

Definir el soporte de la información compartida

Variables comunes (threads) . Atomicidad: load, store, test & set
Región de memoria . Atomicidad: load, store, test & set
Fichero. Atomicidad: operación E/S

Definir la información de control (que también se comparte) y las
condiciones de acceso.

Contadores, etc.

Seleccionar los mecanismos de control

Tipo de mecanismo (semáforo, mutex y cond., cerrojo, etc.)
Instancias de esos mecanismos

9

SITUACIONES TÍPICAS (MODELOS CLÁSICOS)

© UPM 2016

Productor - consumidor

Almacenamiento compartido típico: Buffer circular (huecos tamaño
fijo)
Variables de control típicas:

– Nº de huecos libres
– Punteros posición

Lectores y escritores

Almacenamiento compartido típico: Conjunto de registros
Granularidad del control

– Todo el almacenamiento  Contención
– Cada registro individual  Complejidad

Variables de control típicas:

– Nº de lectores
– Nº de escritores (solamente puede haber uno)

10

SEMÁFORO

MECANISMO DE SINCRONIZACIÓN

MECANISMO: SEMÁFORO

Objeto compartido con:

Campo entero contador de valor inicial dado,
que significa:

© UPM 2016

Información
de control

sii
sii

>0
<=0

nº de veces disponible ( nº plazas)
nº de threads esperando disponibilidad

Dos acciones atómicas

sem_wait(s) === down
{
<<decrementar contador>>;
if (<<contador>> < 0)
<<esperar en s>>
}
sem_post(s) === up
{
<<incrementar contador>>
if (<<contador>> <= 0)
<<que continúe uno>>
}

Semáforo binario
== máximo valor del contador es 1
La "sección crítica" con
semáforo:

sem_wait(binario);________
<<sección crítica>>
sem_post(binario);________

SIN posesión  se puede hacer post sin hacer wait antes

12

SEMÁFOROS: SERVICIOS POSIX
int sem_init (sem_t *sem, int shared, int valini);
int sem_destroy (sem_t *sem);

Inicializar y destruir un semáforo SIN nombre

© UPM 2016

sem_t *sem_open (char *name,int flag,mode_t mode,int valini);
int sem_close (sem_t *sem);
int sem_unlink (char *name);

Abrir (o crear), cerrar y borrar un semáforo CON nombre

int sem_wait (sem_t *sem);

Decrementar el contador del semáforo (competir por pasar)

int sem_post (sem_t *sem);

Incrementar el contador del semáforo (salir)

El semáforo es un mecanismo diseñado
originalmente para PPs. Para PLs pueden

ser demasiado pesados.

13

MUTEX Y CONDICIONES

MECANISMO DE SINCRONIZACIÓN

© UPM 2016

Thread A

Thread B

lock mutex
lock mutex

Sección crítica
unlock mutex

lock mutex

a
r
e
p
s
E

obtiene mutex

Punto de

sincronización

MECANISMO: MUTEX

Mutual Exclusion

== Semáforo binario sin memoria
Cerradura cerrada, llave puesta
Abro y cierro y me llevo la llave

Dos acciones atómicas

mutex_lock(m)
{
if (<<no hay llave>>)
<<esperar llave>>;
<abrir cerrar y llevármela>>;
}
mutex_unlock(m)
{
if (<<alguien espera>>)
<<entregar llave>>;
else
<<devolver llave a cerradura>>;
}

La "sección crítica" con mutex:

mutex_lock(mutex);________
<<sección crítica>>
mutex_unlock(mutex);________

CON posesión  no se puede hacer unlock sin haber hecho lock antes

15

MECANISMO: CONDICIÓN

Permiten liberar un mutexsin
salir de la sección crítica
Tres acciones atómicas

condition_wait(c,m)
{
mutex_unlock(m);
<<esperar aviso>>;
mutex_lock(m);
}
condition_signal(c)
{
if (<<alguien espera>>)
<<avisar que siga>>;
else (<<se pierde>>)
}
condition_broadcast(c)
{
while(<<alguien espera>>)
<<avisar que siga>>;
}

© UPM 2016

A veces el thread que está (o posee)la

sección crítica no puede continuar, porque
"no se da" cierta condición que sólo podría

cambiar otro thread desde dentro de la

sección crítica.

Es preciso pues:

Liberar temporalmente el mutex que
protege la sección crítica...
...mientras se espera a que la
condición se dé.

Todo ello:

Sin abandonar la sección crítica...
...y de forma atómica.

La combinación mutex-condición
muestra la lógica del problema.

!Es realmente cómoda de usar!

16

MECANISMO: MUTEX + CONDICIÓN

A: Mientras no pueda seguir, espero

mutex_lock(mutex);
<<sección crítica...>>
while (<<no puedo continuar>>)
condition_wait(cond,mutex);
<<...sección crítica>>
mutex_unlock(mutex);

lock

c_wait
unlock mutex

Fundamental utilizar while

Se compite
por el mutex

Adquiere
el mutex

B: Si alguien podría seguir, lo indico

mutex_lock(mutex);
<<sección crítica...>>
if (<<se podría continuar>>)
condition_signal(cond);
<<...sección crítica>>
mutex_unlock(mutex);

Thread A

© UPM 2016

Thread B

lock

Adquiere
el mutex

c_signal

unlock

17

Thread bloqueado
esperando unlock
Thread bloqueado
esperando c_signal

SOLUCIONES TÍPICAS

Solución general

© UPM 2016

mutex_lock(mutex);
while (<<no puedo continuar (condición variables control)>>)

condition_wait(cond, mutex);
<<modifica variables de control>>
mutex_unlock(mutex);

<<...sección crítica del problema>>

mutex_lock(mutex);
<<modifica variables de control>>
condition_signal(cond);
mutex_unlock(mutex);

18

MUTEX: SERVICIOS POSIX

© UPM 2016

int pthread_mutex_init (pthread_mutex_t *mutex,

pthread_mutexattr_t *attr)

Inicializar un mutex con atributos attr. Existen diversas llamadas para
modificar los atributos, con NULL se especifican atributos por defecto

int pthread_mutex_destroy (pthread_mutex_t *mutex);

Borrar (destruir) un mutex

int pthread_mutex_lock (pthread_mutex_t *mutex);

Competir por tomar el mutex

int pthread_mutex_unlock (pthread_mutex_t *mutex);

Devolver el mutex (salir)

Los mutex y las condiciones son
un mecanismo idóneo para PLs

20

CONDICIONES: SERVICIOS POSIX

© UPM 2016

int pthread_cond_init (pthread_cond_t *cond,

pthread_condattr_t *attr);

Ini