High Quality
Open the downloaded document, and select print from the file menu (PDF reader required).
Tema
4
Procesadores
y
procesos
en
sistemas
distribuidos
Es
posible
disponer
en
un
proceso
de
más
de
un
flujo
de
ejecución.
A
cada
uno
de
estos
flujos
le
denominaremos
"thread".
La
introducción
de
threads
en
la
codificación
de
servidores
aporta
ventajas
e
inconvenientes
que
serán
estudiados
en
primer
lugar.
Por
otra
parte,
en
un
sistema
distribuido
se
dispone
de
más
de
un
procesador.
A
continuación,
estudiaremos
las
diversas
formas
de
organizar
los
procesadores.
Finalmente,
estudiaremos
la
forma
de
asignar
un
proceso
entre
todos
los
procesadores
disponibles.
4.1
Procesos
y
threads
En
los
años
ochenta
se
descubrió
que
el
concepto
de
proceso,
tal
como
lo
entendemos
en
el
mundo
UNIX,
resultaba
desproporcionado
para
los
requisitos
de
los
sistemas
distribuidos.
El
problema
radica
en
que
UNIX
asocia
un
único
thread
de
control
con
cada
proceso.
Un
proceso
es
un
recurso
costoso
en
su
creación
y
en
su
gestión.
Ello
lleva
consigo
que
la
cooperación
entre
las
distintas
actividades
de
una
apli
‐
cación
donde
cada
una
de
ellas
ha
sido
implementada
como
un
proceso
sea
difícil
de
programar
y
costo
‐
sa
en
términos
de
ciclos
de
UCP
por
el
gran
número
de
llamadas
al
sistema
requeridas
en
la
comunica
‐
ción
de
actividades
‐
comunicación
de
procesos
‐
y
en
la
planificación
de
las
mismas
‐
cambios
de
contexto
‐
(Fig.
4.1).
Fig.
4.1
Mapeo
tradicional
de
actividad
como
proceso
En
la
actualidad,
la
investigación
en
sistemas
distribuidos
y
el
concepto
de
microkernel
han
puesto
de
manifiesto
la
necesidad
de
que
en
un
mismo
espacio
de
direccionamiento
convivan
más
de
un
thread
de
control.
Aunque
no
es
la
única,
una
de
las
finalidades
de
los
threads
es
mejorar
las
prestaciones
de
los
UNIVERSIDAD NACIONAL DE TRUJILLO
ESCUELA
DE
INFORMATICA
2
servidores,
ahora
no
ocultos
en
las
profundidades
del
sistema
sino
construidos
como
procesos
de
usua
‐
rio.
En
esta
sección
discutimos
el
concepto
de
thread
y
sus
implicaciones.
4.1.1
Introducción
al
concepto
de
thread
En
ocasiones,
el
servidor
de
ficheros
debe
bloquearse
porque
los
octetos
que
solicita
un
proceso
de
usua
‐
rio
no
se
encuentran
en
la
caché
y
debe
solicitar
la
lectura
del
bloque
correspondiente
al
manejador
de
disco.
El
servidor
de
ficheros
se
bloquea
esperando
el
servicio.
Leer
un
bloque
de
disco
lleva
algún
tiem
‐
po.
Durante
este
tiempo,
el
manejador
se
también
se
bloquea.
El
resultado
del
bloqueo
del
servidor
es
que
otras
peticiones
de
bloques
por
parte
de
otros
procesos
de
usuario
no
pueden
ser
atendidas,
estén
o
no
estén
los
octetos
solicitados
disponibles
en
la
caché.
Para
subsanar
el
problema
se
debe
disponer
de
uno
o
más
threads
alternativos
en
el
servidor
de
ficheros
que
continúen
con
la
ejecución.
Así,
cuando
un
thread
se
bloquea
en
la
solicitud
de
un
bloque
al
manejador
de
disco
duro,
otro
thread
toma
el
control
sirviendo
la
siguiente
petición,
cuyos
octetos
pueden
estar
en
la
caché.
La
introdución
del
concepto
de
thread
aumenta
la
concurrencia
y
las
prestaciones
del
servidor
de
ficheros.
Puede
pensarse
que
la
concurrencia
puede
también
lograrse
mediante
réplicas
del
servidor
de
ficheros.
Cada
réplica
puede
atender
una
solicitud
de
la
aplicación
de
usuario.
Esta
es
una
opción
que
no
da
resul
‐
tado
porque,
entre
otras
cosas,
ambos
procesos
necesitan
compartir
la
caché
de
bloques.
Ello
exige
un
proceso
dedicado
a
soportar
la
caché
y
mecanismos
de
paso
de
mensajes
entre
los
dos
servidores
(Fig.
4.2),
una
opción
ineficiente
debido
a
los
costos
de
comunicación.
Fig.
4.2
Aceleración
del
servidor
de
ficheros
por
replicación
El
uso
de
threads
es
la
mejor
opción.
La
figura
4.3
a)
muestra
tres
procesos.
Cada
uno
de
ellos
tiene
su
propio
espacio
de
direccionamiento
y
descriptor
de
proceso.
Los
tres
procesos,
ya
que
no
comparten
es
‐
pacio
de
direcciones,
deben
comunicarse
haciendo
uso
de
los
servicios
de
comunicación
de
procesos
ofrecidos
por
el
sistema
operativo.
En
la
figura
4.3
b)
observamos
un
único
proceso
con
tres
threads
de
control.
Cada
uno
de
ellos
tiene
su
propio
contador
de
programa
y
su
propia
pila,
pero
todos
ellos
com
‐
parten
el
mismo
espacio
de
direcciones.
A
estos
mini
‐
procesos
se
les
denomina
threads
o
procesos
lige
‐
ros
.
Por
supuesto,
los
threads
comparten
la
UCP
en
un
sistema
monoprocesador.
En
un
hardware
multi
‐
procesador,
sin
embargo,
los
threads
pueden
ejecutar
en
paralelo.
Un
thread
puede
crear
un
thread
hijo
y,
al
igual
que
los
procesos
invocar,
llamadas
al
sistema.
Si
un
thread
se
bloquea
en
una
de
estas
llamadas,
otra
puede
tomar
la
UCP
sin
que
el
sistema
operativo
necesite
cambiar
de
contexto.
UNIVERSIDAD NACIONAL DE TRUJILLO
ESCUELA
DE
INFORMATICA
3
Fig.
4.3
a)
Tres
procesos
con
un
thread
de
control
cada
uno.
b)
Un
proceso
con
tres
threads
de
control.
Los
threads
comparten
un
mismo
espacio
de
direccionamiento,
de
modo
que
no
hay
protección
entre
ellas,
todas
tienen
acceso
a
las
varibles
globales
del
resto.
El
hecho
es
que
proporcionar
protección
entre
los
threads,
primero,
es
imposible
y,
segundo,
no
es
necesario.
A
diferencia
de
los
procesos
de
usuario,
los
threads
son
programados
por
un
mismo
programador,
de
modo
que
no
deben
intentar
acciones
per
‐
judiciales
para
el
resto
de
los
threads
sino
todo
lo
contrario
y,
si
lo
hacen
debido
a
un
error
de
codifica
‐
ción,
la
responsabilidad
recae
sobre
el
programador.
Además
de
compartir
espacio
de
direccionamiento,
los
threads
comparten
los
mismos
ficheros
abiertos,
manejadores
de
señal,
procesos
hijos,
etc,
algo
que
es
útil
cuando
los
threads
no
son
independientes,
sino
que
colaboran
en
un
fin
común.
4.1.2
El
Contexto
de
un
thread
La
figura
4.4
muestra
un
programa
que
calcula
dos
valores
y
los
suma.
La
figura
4.5
muestra
el
proceso
tradicional
UNIX
asociado
al
programa
con
el
contexto
del
proceso
determinado
por
tres
bloques
dis
‐
tintos,
los
registros,
la
identidad
del
proceso
y
los
recursos.
int r_a, r_b;main(){calcula_a(&r_a);calcula_b(&r_b);reune(r_a, r_b);}void calcula_a(int *res)
{...*res = Cálculo_a();}void calcula_b(int *res){...*res = Cálculo_b();}void reune(int p, int q){printf("%d\n", p+q);}
Fig.
4.4
Programa
máquina Bprocesosmáquina Athreadscontador deprograma
Add a Comment
This document has made it onto the Rising list!