Sistemas Operativos – 2do Parcial

Interbloqueos

Un interbloqueo es un bloqueo permanente de 2 o más procesos que están

compitiendo por un recurso o están comunicándose entre sí. Se dice que estos
están interbloqueados cuando cada uno de los procesos está bloqueado
esperando a un evento que solo puede ser generado por otro de los procesos que
está bloqueado.
El clásico ejemplo de un interbloqueo es el siguiente:

“llegan 4 vehículos a una intersección al mismo tiempo, y todos desean cruzar

hacia la derecha:
● El 1 vehículo, viaja al norte y necesita cuadrante a y b.
● El 2 vehículo necesita b y c.
● El 3 vehiculo necesita los cuadrantes c y d.
● El 4 auto necesita los cuadrante d y a.
Lo normal en la circulación vehicular es que el de la derecha tenga el paso, pero
como todos llegan más o menos al mismo tiempo, todos agarran el primer
recurso, al intentar buscar el segundo se quedan bloqueados, esperando que el
siguiente suelte el que necesita.”

Para estos casos (donde varios procesos comparten recursos) se suele definir una
región fatal, es un área en la que una vez que los procesos entran en ella, estos se
verán involucrados en un interbloqueo.
Recursos:
Se pueden distinguir 2 categorías de recursos: los reutilizables y los consumibles. Los
recursos reutilizables son aquellos que solo pueden ser utilizados de manera segura
por un proceso y no son destruidos después de su uso (por ejemplo la memoria,
dispositivos, etc). Cuando un proceso los necesita, estos obtienen una unidad del
recurso, cuando deja de ser usado el proceso lo libera.
Un caso de interbloqueo con recursos de este tipo podría ser:
“La memoria principal tiene un espacio de 200 kbytes disponibles para reservar y se
produce la siguiente secuencia de ejecución:

El interbloqueo ocurrirá si los 2 procesos logran llegar hasta la segunda interrupción,

no será posible darle memoria al otro hasta que el primero la suelte.

Los recursos consumibles son aquellos que pueden crearse y destruirse (por ejemplo
señales, interrupciones, etc). Un proceso productor desbloqueado puede crear una
cantidad ilimitada de estos recursos. Cuando un proceso consumidor toma uno de
estos recursos, este deja de existir. Un ejemplo de interbloqueos con este tipo de
recursos sería:
“Hay 2 procesos y cada uno intenta recibir un mensaje del otro de la siguiente
manera:

En este caso se producirá un interbloqueo si la función que recibe el mensaje es

bloqueante (es decir, el proceso que recibe se bloquea hasta recibir el mensaje).

No existe una estrategia efectiva que pueda tratar con todos los tipos de
interbloqueos. Existen varias estrategias:
Grafo de Asignación de recursos:
Es una herramienta útil para la graficar la asignación de recursos a los procesos. Este
es un grafo dirigido que representa el estado del sistema en cuanto a los recursos y
procesos, de tal manera que cada proceso y cada recurso se representa por un
nodo. Una arista del grafo dirigida desde un proceso a un recurso indica que este lo
ha solicitado pero que todavía no se lo ha conferido. El caso contrario donde la
arista apunta del recurso hacia el proceso indica que este se le ha sido asignado.

Un interbloqueo se representa de la siguiente manera:

Condiciones para el Interbloqueo:
Para que ocurra un interbloqueo deberán darse 4 condiciones:
1. Exclusión Mutua: Sólo un proceso podrá utilizar un recurso por momento.
Ningún otro recurso podrá acceder a tal unidad si alguien la está utilizando.
2. Retención y espera: Un proceso puede mantener los recursos asignados
mientra espera la asignación de otros.
3. Sin expropiación: No se puede forzar la expropiación de un recurso a un
proceso que lo posee.
4. Espera circular: Existe una lista cerrada de procesos, de tal manera que
cada proceso posee al menos un recurso que el siguiente necesita.

Por ciertas razones es necesario que estas condiciones se encuentran. Por ejemplo
se necesita la exclusión mutua para la coherencia e integridad de la base de
datos. Del mismo modo la expropiación no se deberá hacer de manera arbitraria.
Sí se cumplen las primeras 3 condiciones se puede producir un interbloqueo, pero
no siempre que se cumplan sucederá. Para que realmente suceda deben darse las
4 condiciones.
La 4ta condición es una consecuencia potencial de las 3 primeras. Osea si se
cumplen las 3 primeras condiciones, es probable que conduzca a una espera
circular irresoluble.
Entonces para que se produzca un interbloqueo es necesario que exista una región
fatal (es decir la culminación de las 3 primeras condiciones), sino también una
secuencia de peticiones de recursos que conduzcan hacia esta. Sí se cumple la 4ta
condición, podemos asumir que se ha entrado en la región fatal.

Tratamiento de los interbloqueos:

Existen 3 estrategias para tratar con los interbloqueos: Prevenir, predecir y detectar.

Prevención del interbloqueo:

Esta estrategia lo que busca es diseñar un sistema de manera que se excluya la
posibilidad del interbloqueo. Los métodos de prevención pueden clasificarse en 2
categorías:
● Indirecto: este busca impedir la aparición de una de las 3 primeras
condiciones necesarias para el interbloqueo.
● Directo: Este busca impedir que suceda una espera circular.

Cada condición tiene su propia técnica para evitarla:

 ● Exclusión Mutua: Generalmente esta condición no puede eliminarse. Pero
para algunos recursos, como pueden ser los ficheros, puede permitirse
múltiples accesos de lectura pero para la escritura será un acceso exclusivo,
aun así podrá haber un deadlock en escritura.

● Retención y espera: Esta puede eliminarse estableciendo ue un proceso

debe solicitar al mismo tiempo todos sus recursos requeridos, bloqueandose
hasta que estén todos disponibles (no es suficiente y rompe con el esquema
modular).

● Sin Expropiación: Una de las maneras de impedirla es sí a un proceso que

mantiene varios recursos se le niega una petición, este deberá liberar todos
los recursos que mantiene, y de ser necesario, deberá volver a pedir los que
necesite junto con el nuevo recurso. Una alternativa a esto sería que cuando
un proceso pide un recurso que otro proceso mantiene, el so le retirara el
recurso al último para brindarselo al que lo necesite (Esta estrategia es sólo
válida cuando se puede guardar y recuperar el estado actual).

● Espera Circular: Esta se puede evitar definiendo un orden lineal entre los
distintos tipos de recursos. Sí a un proceso le han asignado recursos de tipo x,
sólo podrá pedir aquellos que tengan un orden posterior a X. (Ineficiente).

Predicción del interBloqueo:

Este tipo de estrategia permite que ocurran las primeras 3 condiciones para el
interbloqueo, pero toma decisiones razonables para asegurarse de que nunca se
alcance el punto del interbloqueo. Con la predicción se decide dinámicamente si
la petición de un recurso, podrá ocasionar un interbloqueo, por lo tanto esta
requiere conocer las futuras solicitudes de recursos.
Para realizar la predicción existen 2 técnicas:
● Denegación de la iniciación del proceso: Se arma una especie de matriz de
necesidad donde indica los requisitos máximos de cada proceso con
respecto a cada recurso, cada fila de la matriz corresponde a c/d proceso.
Esta información debe ser declarada con antelación, caso contrario no
funcionara. Sólo podrá iniciarse un proceso sí se pueden satisfacer las
necesidades máximas de todos los procesos actuales más las del nuevo. (No
es óptima).

● Denegación de asignación de recursos: Esta comienza con la definición de

los conceptos de estado y estado seguro. El estado refleja la asignación
actual de recursos a procesos. Este es consiste de 2 vectores, recursos y
disponibles, y 2 matrices, Necesidad y Asignación. El Estado seguro es aquel
en el que hay al menos una secuencia de asignación de recursos a los
procesos que no implica un interbloqueo (Osea es cuando un proceso
 puede ejecutarse tranquilamente con los recursos disponibles).

La ventaja de la predicción es que no es necesario expropiar a los procesos ni

retroceder su ejecución, sin embargo tiene varias restricciones:
● Deben establecerse los requisitos máximos de cada recurso por proceso.
● Los procesos deben ser independientes.
● Debe de haber un número fijo de recursos a asignar.
● Ningún proceso puede terminar mientras mantenga recursos.

Detección del Interbloqueo:

Esta estrategia no limita el acceso a los recursos ni restringe las acciones de los
procesos. Los recursos pedidos se conceden a los procesos siempre que sea posible.
Periódicamente, el sistema operativo realiza un algoritmo que permite detectar la
condición de espera circular. La comprobación de si hay interbloqueo se puede
hacer una vez por cada petición de recursos o con menos frecuencia.
El algoritmo para la detección utiliza la matriz de asignación y el vector de
disponibles (los mismos que los de la técnica anterior) junto a una matriz de solicitud
S tal que esta representa la cantidad de recursos de tipo X solicitados por un
proceso Y. El algoritmo actúa marcando los procesos que no están en un
interbloqueo, por lo tanto todos los procesos que estén en la matriz sin marcar están
en deadLock. El objetivo de esto es el de encontrar procesos cuyas peticiones
pueden ser resueltas con los recursos disponibles, de esta manera le concede los
recursos y el proceso se ejecuta hasta terminar para así liberar todos sus recursos.

Recuperación de Interbloqueos:

Una vez que se detecta un interbloqueo es necesaria alguna estrategia para poder
recuperarse, dentro de las más usadas están:
1. Abortar todos los procesos involucrados en el interbloqueo (Es la más usada).
2. Retroceder los procesos a un punto previo (checkpoint) y volver a empezar
desde ahí (puede volver a suceder el deadlock, no usada).
3. Abortar los procesos de a poco hasta que ya no haya deadlock.
4. Expropiar sucesivamente los recursos hasta que ya no exista un interbloqueo.
Obviamente para los métodos 3 y 4 es necesario algún criterio para determinar qué
criterio seleccionó para abortar o expropiar los recursos. Lo que generalmente se
suele hacer es elegir al proceso con:
● La menor cantidad de procesamiento.
● La menor cantidad de salida producida.
● El mayor tiempo restante (estimación).
 ● El menor número de recursos asignados.
● La menor prioridad.

Virtualización:

Esta tecnología permite que una sola computadora contenga varias máquinas
virtuales, c/d una de ellas podrá tener un sistema operativo, distinto o no. La ventaja
de este método es que al fallar una máquina virtual no fallan el resto, por lo tanto
de esta manera ya no es necesario tener diversas computadoras con distintos
servidores.
Aun así la esta no es aprueba de fallas, ya que estamos poniendo todos los
servidores en un mismo lugar. Si falla el servidor que mantiene a todas las máquinas
virtuales, el resultado sería mortal. Aun así la virtualización se sigue utilizando ya que
la mayoría de las fallas en los servicios no son por un problema de hardware, sino
por uno de software.
Otra de las ventajas de virtualizar es que al no tener tantas máquinas físicas nos
ahorramos en hardware y en electricidad (Esto es realmente importante para las
grandes compañías como google). Además cuando se utilizan máquinas virtuales
es mucho más fácil migrar datos entre distintas máquinas, todo lo que hay que
hacer es mover la imagen de memoria y ya está.
Las máquinas virtuales no sólo se utilizan para los servidores, también se pueden
utilizar para ejecutar aplicaciones heredadas en los sistemas operativos que ya no
tienen soporte o que no funcionan con el hardware actual. Incluso podrían
aprovecharse para asegurarse que software actual funcione en distintos sistemas
operativos a los cuales no tenemos acceso o no poseemos el hardware para poder
correrlos.

Requerimientos para la Virtualización

Hay 2 métodos para virtualizar, se puede utilizar un hipervisor de tipo 1 (es el sistema
operativo directamente, las máquinas virtuales usan copias de hard actual) o un
hipervisor de tipo 2 (es un programa de usuario que corre sobre un SO, este
interpreta las instrucciones de máquina).
Sea cual sea el caso, las máquinas virtuales deben actuar como si estuvieran
corriendo sobre el. Deberá ser posible iniciarlas como si fueran máquinas reales, e
incluso será posible instalar cualquier sistema operativo sobre ellas.
Existen 2 hipervisores por un defecto encontrado en la intel 386, cada cpu con
modo kernel y usuario tiene un conjunto de instrucciones que sólo pueden realizarse
en modo kernel. Estas instrucciones son conocidas como instrucciones sensibles
(terminó por Popek y Goldberg 1974). Además de estas hay un conjunto de
instrucciones que producen interrupciones si se ejecutan en modo usuario, estas se
conocen como instrucciones privilegiadas (otra vez Popek y Goldberg). El
problema radica en que una máquina sólo podrá ser virtualizada si las instrucciones
sensibles son un subconjunto de las privilegiadas.

Hipervisor de tipo 1:
En este tipo de hipervisor la máquina virtual se ejecuta como un proceso de modo
usuario, por lo tanto no podrá ejecutar instrucciones sensibles, aun así ella piensa
que está ejecutando en modo kernel. Esto se conoce como modo kernel virtual
(obviamente los procesos en modo usuario están en modo usuario).
Cuando se ejecuta una instrucción sensible en una cpu sin virtualización, la
instrucción falla, lo que conlleva a una falla del SO.
En aquellos SO que tienen Virtualización, se produce una interrupción en el kernel,
de esta manera el hipervisor puede inspeccionar la instrucción para ver si fue el SO
original o el el Anfitrión el que género la interrupción. En el primer caso hace lo
necesario para ejecutar la instrucción, en el segundo, emula lo que haría el
hardware real al encontrarse con una instrucción sensible que se ejecuta en modo
usuario.

Hipervisor de tipo 2:
Esta técnica nace como una respuesta al problema generado por la intel 386
(obviamente porque existía la necesidad de virtualizar). El primer hipervisor de este
tipo fue el VMware. Este se ejecuta como un programa de usuario común sobre un
sistema operativo anfitrión. Al iniciar por primera vez actúa como si fuese una
computadora que se enciende por primera vez, esperando encontrar un cd que
contenga un SO. Una vez instalado el SO en el disco virtual, este se puede inicial al
ejecutar la VM.
Como VMware es un hipervisor de tipo 2, escanea el código en busca de bloques
básicos (un conjunto de instrucciones que terminan en una instrucción que
modifica el flujo de control) que contengan instrucciones instrucciones sensibles. En
caso de encontrarlas, las sustituirá por llamadas a un procedimiento de VMware
que las manejara.
Una vez que se sustituyeron las instrucciones sensibles, coloca el resto del bloque
básico en la caché del VMware y después las ejecuta. Esta técnica de encontrar
atrapar las instrucciones sensibles y emularlas (las suplanta por código que emulara
su comportamiento) se conoce como traducción binaria.
Una vez que se completó la ejecución de un bloque básico, el control regresa a
VMware que busca al siguiente bloque. Si ya fue traducido, se ejecuta de
inmediato, si no, se realiza el mismo proceso que se describió antes con el nuevo
bloque, y así.
La gran ventaja de este tipo de hipervisores es que se puede virtualizar en hardware
que no lo permite. Esto es posible gracias a la traducción binaria. Además esta
técnica de virtualización posee un rendimiento mucho mayor que la técnica del
hipervisor de tipo 1.

Paravirtualización:

Este método consiste en eliminar (algunas) instrucciones sensibles del sistema

operativo a virtualizar, de manera que este actúe como un programa de usuario
que realiza llamadas al hipervisor para obtener servicios (como por ej la E/S).
Para utilizar este método, es necesario que el hipervisor defina una interfaz de
programación de aplicaciones (API), la cual es un conjunto de llamadas a
procedimientos, que serán utilizadas por los SO invitados (virtualizados).
Con la paravirtualización surgen varios problemas:
● Como se haría para ejecutar el sistema operativo invitado en el hardware
nativo? recordemos que se sustituyeron las instrucciones sensibles por
llamadas al hipervisor.
● Que pasa si hay distintos hipervisores, cada uno tiene su propia api? es
posible modificar el kernel para que se ejecute en todas?

Para solucionar esto el kernel se modifica para llamar a ciertos procedimientos

especiales (de especiales no tienen mucho, buscan ser genéricos y no estar atados
a nada), conocidos como VMI (Virtual Machine Interface), cada vez que debe
hacer algo sensible. Estos procedimientos forman una capa de bajo nivel que
actúa como interfaz para el hardware o el hipervisor.
Los SO para virtualizados funcionan de manera un poco distinta a la normal. Al
ejecutarse en el hardware básico, se vincula con la biblioteca que emite la
instrucción real necesario para el trabajo. En cambio, al ejecutarse en un hipervisor,
el SO invitado se vincula con las distintas bibliotecas que componen las llamadas
apropiadas al hipervisor. (ASÍ FUNCIONA AL MENOS CON UN LINUX
PARAVIRTUALIZADO)

Virtualización de la Memoria:

Una memoria virtual es en esencia una asignación de las páginas en el espacio de

direcciones virtuales a las páginas de la memoria física. La asignación se define
mediante tablas de páginas multinivel. El problema es que al hacer que el SO tenga
un registro de control en la cpu, el cual apunta a la tabla de páginas de nivel
superior, La virtualización se complejiza en gran manera.
Por ejemplo, se está ejecutando una máquina virtual y el sistema operativo invitado
en ella decide asignar sus páginas virtuales 7, 4 y 3 a las páginas físicas 10, 11 y 12.
Crea tablas de páginas que contienen esta asignación y carga un registro de
hardware para que apunte a la página de tablas de nivel superior. Esta instrucción
es sensible. Con VT, se producirá una interrupción; con VMware producirá una
llamada a un procedimiento de VMware y en un SO paravirtualizado se generará
una llamada al hipervisor. Luego asignar las páginas físicas 10, 11 y 12 a esta
máquina virtual y establecer las páginas de tablas actuales para que asignen las
páginas virtuales 7, 4 y 3 de la máquina virtual para utilizarlas.
En el ejemplo de arriba se puede ver claramente un gran problema, que pasaría si
se crea otra máquina virtual la cual decide asignar sus páginas a las mismas
páginas físicas? Deberá buscar paginas libre y crear una nueva página de tablas
para asignar estas. Si hay otra máquina virtual y busca hacer lo mismo? pasará lo
mismo, se deberá crear una nueva asignación. Para cada máquina virtual el
hipervisor deberá crear una Shadow (Una tabla de páginas oculta) que asigne
todas las páginas virtuales a las páginas reales que el hipervisor le cedió.
Otro problema es que el SO invitado puede cambiar sus tablas de páginas, por lo
que el hipervisor deberá cambiar la shadow. En la paravirtualización no supone una
gran complejidad ya que este sabe que al terminar de modificar la tabla de
páginas de un proceso x, debe informar al hipervisor.

Virtualización de la E/S:

Una técnica para realizar la virtualización es la de sondear los dispositivos reales,

para que el SO anfitrión cargue los drivers de los dispositivos y los intente usar.
Cuando los drivers intenten realizar operaciones de E/S, leerán y escribirán en los
registros del hardware real. Como tales instrucciones son sensibles, estas serán
atrapadas por el hipervisor, que copiara los valores que entran y salen según sea
necesario.
Esto supone un problema ya que cada SO invitado cree que posee toda la
partición del disco, y puede haber más máquinas virtuales que particiones de disco.
Una manera de solventarlo es creando un archivo en el disco, el cual actuará será
utilizado como si fuera un disco por el SO invitado. Otra solución es que utilice un
disco distinto al disco utilizado realmente.
Otro problema es que debe resolverse es el uso de DMA, que utiliza direcciones de
memoria absolutas. Para solucionarlo es necesario que el hipervisor intervenga y
reasigne las direcciones antes de que este inicie.
Otra manera de tratar la virtualización de la E/S sería dedicar una máquina virtual
para que ejecute un SO estándar y que refleje todas las llamadas a la E/S de las
otras máquinas virtuales. Esta máquina virtual es conocida como dominio 0.
 Multiprocesadores:

Motivación:
Ofrecer un mayor poder de computo, entendiendo que ya no alcanza con
hacer que el reloj opere a mayor velocidad, debido a que se han alcanzado
ciertos limites físicos en cuanto a la velocidad del reloj.
Por lo tanto la metodología utilizada para alcanzar este objetivo es a través
de las computadoras masivamente en paralelo. Estas máquinas consisten en
muchas CPUs, cada una de las cuales opera a una velocidad “normal” (lo que eso
signifique en cierto año específico), pero que en conjunto tienen mucho más poder
de cómputo que una sola CPU.

Distintos Esquemas:
◦ Multiprocesadores con Memoria Compartida
◦ Multicomputadora con paso de mensajes
▪ fuertemente acoplados.
◦ Sistemas Distribuidos
▪ débilmente acoplados

Sus principales diferencias radican en la velocidad de comunicación.

◦ Multiprocesadores con Memoria Compartida (multiprocesadores)

 Cierta cantidad de CPUs (entre 2 y aproximadamente 1000) se comunican a
través de una memoria compartida.
En este modelo, cada CPU tiene el mismo acceso a toda la memoria física, y
puede leer y escribir palabras individuales mediante instrucciones LOAD y STORE.
Para acceder a una palabra de memoria por lo general se requieren de 2 a
10 nseg.
No es tan sencillo implementarlo y por lo general implica el paso de muchos
mensajes de manera interna. Sin embargo, este proceso de paso de mensajes es
invisible para los programadores.

◦ Multicomputadora con paso de mensajes (multicomputadoras)

Varios pares de CPU-memoria se conectan a una interconexión de alta

velocidad.
Cada memoria es local para una sola CPU y puede ser utilizada sólo por esa
CPU.
Las CPUs se comunican enviando mensajes de varias palabras a través de la
interconexión.
Con una buena interconexión, un mensaje corto se puede enviar en un
tiempo de 10 a 50 nseg, pero aún es más largo que el tiempo de acceso a la
memoria del esquema anterior.
No hay memoria global compartida en este diseño.
Sin embargo son mucho más fáciles de construir que los multiprocesadores
(memoria compartida), pero son más difíciles de programar.

◦ Sistemas Distribuidos
Conecta sistemas de cómputo completos a través de una red de área
amplia como Internet, para formar un sistema distribuido.
Cada uno de estos sistemas tiene su propia memoria, y los sistemas se
comunican mediante el paso de mensajes.
La única diferencia real con las multicomputadoras es que en los sistemas
distribuidos se urilizan computadoras completas, y los tiempos de los mensajes son
comúnmente entre 10 y 100 mseg. Este largo retraso obliga a que estos sistemas
débilmente acoplados se utilicen de maneras distintas a los sistemas fuertemente
acoplados(multicomputadoras).
Los tres tipos de sistemas difieren en sus retrasos por una cantidad
aproximada a los tres órdenes de magnitud. Ésa es la diferencia entre un día y tres
años.
 MULTIPROCESADORES
(Multiprocesadores con Memoria Compartida)

Sistema de cómputo en el que dos o más CPUs comparten el acceso

a una RAM común.
Un programa que se ejecuta en cualquiera de las CPUs ve un espacio
normal de direcciones virtuales (por lo general paginadas).
La única propiedad inusual que tiene este sistema es que la CPU
puede escribir cierto valor en una palabra de memoria y después puede
volver a leer esa palabra y obtener un valor distinto (tal vez porque otra CPU
lo cambió). Si se organiza en forma correcta, esta propiedad forma la base
de la comunicación entre procesadores: una CPU escribe ciertos datos en la
memoria y otra lee esos datos.

Características Regulares de los SO de multiprocesadores con otros

SO:
Manejan las llamadas al sistema,
administran la memoria,
proveen un sistema de archivos y
administran los dispositivos de E/S.
Características Particulares de los SO de multiprocesadores:
sincronización de procesos,
la administración de recursos y
la programación de tareas.

Hardware de multiprocesador
Todos los multiprocesadores tienen la propiedad de que cada CPU
puede direccionar toda la
memoria.
Las maquinas se clasifican en cuanto a la velocidad de acceso en:
UMA (Uniform Memory Access, Acceso uniforme a la memoria),
donde cada palabra de memoria se puede leer con la misma
velocidad que cualquier otra palabra de memoria.
 NUMA (Non-uniform Memory Access, Acceso no uniforme a la
memoria), donde no se tiene la propiedad anterior.

- Multiprocesadores UMA con arquitecturas basadas en bus:

Se basan en un solo bus.
Dos o más CPUs y uno o más módulos de memoria utilizan el mismo bus
para comunicarse.

Cuando una CPU desea leer una palabra de memoria, primero

comprueba si el bus está ocupado.
- Si está inactivo, la CPU coloca la dirección de la palabra que desea
en el bus, declara unas cuantas señales de control y espera hasta que la
memoria coloque la palabra deseada en el bus.
- Si el bus está ocupado cuando una CPU desea leer o escribir en la
memoria, la CPU espera sólo hasta que el bus esté inactivo.
El problema de este diseño es que con muchas CPUs, el sistema estará
totalmente limitado por el ancho de banda del bus, y la mayoría de las CPUs
estarán inactivas la mayor parte del tiempo.
La solución a este problema es agregar una caché a cada CPU.
 La caché puede estar dentro del chip de la CPU, a un lado de ésta,
en el tablero del procesador o puede ser alguna combinación de las tres
opciones anteriores.
Como esto permite satisfacer muchas operaciones de lectura desde
la caché local, habrá mucho menos tráfico en el bus y el sistema podrá
soportar más CPUs.
Implementación:
- Cada bloque de la caché se marca como de sólo lectura (en cuyo
caso puede estar presente en varias cachés al mismo tiempo) o como de
lectura-escritura (no puede estar presente en otras cachés).
- Si una CPU trata de escribir una palabra que está en una o más
cachés remotas, el hardware
del bus detecta la escritura y coloca una señal en el bus para informar a
todas las demás cachés sobre la operación de escritura.
- Si otras cachés tienen una copia “limpia” (es decir, una copia exacta
de lo que hay en memoria), sólo tienen que descartar sus copias y dejar que
la CPU que va a escribir obtenga el bloque de la caché de la memoria
antes de modificarla. Si alguna otra caché tiene una copia “sucia” (es decir,
modificada), debe escribirla de vuelta a la memoria para que pueda
continuar la escritura, o transferirla directamente a la CPU que va a realizar
la operación de escritura a través del bus.
A este conjunto de reglas se le conoce como protocolo de
coherencia de cachés y es uno de muchos.

Otra posibilidad es que cada CPU tenga no sólo una caché, sino
también una memoria privada local que utiliza mediante un bus dedicado
(privado). Para utilizar esta configuración de manera óptima, el compilador
debe colocar todo el texto del programa, las cadenas, constantes y demás
datos de sólo lectura, las pilas y las variables locales en las memorias
privadas. De esta forma, la memoria compartida se utiliza sólo para escribir
variables compartidas.
En la mayoría de los casos, esta cuidadosa colocación reducirá de
manera considerable el tráfico en el bus, pero requiere de una cooperación
activa por parte del compilador.

- Multiprocesadores UMA que utilizan interruptores de barras cruzadas.

Aun con la mejor caché, el uso de un solo bus limita el tamaño de un
multiprocesador UMA a 16 o 32 CPUs, aproximadamente. Para lograr algo
más se necesita un tipo distinto de interconexión.
El circuito más simple para conectar n CPUs a k memorias es el
interruptor (conmutador) de barras cruzadas.
Los interruptores de barras cruzadas se han utilizado por décadas en
los puntos de intercambio de los conmutadores telefónicos para conectar
un grupo de líneas entrantes a un conjunto de líneas salientes de manera
arbitraria.
En cada intersección de una línea horizontal (entrante) y una vertical
(saliente) hay un punto
de cruce, el cual es un pequeño interruptor que puede estar abierto o
cerrado en sentido eléctrico,
dependiendo de si las líneas horizontal y vertical van a conectarse o no.
 En la figura se pueden ver tres puntos de cruce cerrados al mismo
tiempo, con lo cual se permiten tres conexiones entre los pares (CPU,
memoria) (010, 000), (101, 101) y (110, 010) al mismo tiempo. También son
posibles muchas otras combinaciones.

Ventajas:
◦ es una red sin bloqueos, lo cual significa que a ninguna CPU se le
niega nunca la conexión que necesita, debido a que algún punto
de cruce o una línea ya estén ocupados (suponiendo que el
módulo de memoria en sí esté disponible).
◦ no se necesita una planeación por adelantado. Aun si ya hay siete
conexiones arbitrarias establecidas, siempre es posible conectar la
CPU restante a la memoria restante.
◦ también es posible la contención de memoria, si dos CPUs desean
acceder al mismo módulo, al mismo tiempo. Sin embargo, al
particionar la memoria en n unidades, la contención se reduce por
un factor de n en comparación con el modelo anterior.
Desventajas:
◦ el número de puntos de cruce aumenta con base en n2. Con 1000
CPUs y 1000 módulos de memoria, necesitamos un millón de puntos
de cruce por lo tanto no es factible un interruptor de barras
cruzadas de este tamaño. Sin embargo, para los sistemas de
tamaño mediano, se puede utilizar el diseño de las barras cruzadas.

- Multiprocesadores UMA que utilizan redes de conmutación multietapa

 Se basa en un conmutador de 2 X 2.
Este interruptor tiene solo dos entradas y dos salidas.
Los mensajes que llegan en cualquiera de las líneas de entrada se
pueden conmutar a cualquiera de las líneas de salida.

Formato de un mensaje:

Para nuestros fines, los mensajes deben contener hasta cuatro partes.
- El campo Módulo indica qué memoria utilizar.
- Dirección especifica una dirección dentro de un módulo.
- CódigoOp proporciona la operación, como READ o WRITE.
- El campo Valor opcional puede contener un operando, como
una palabra de 32 bits a escribir mediante una operación WRITE.
El interruptor inspecciona el campo Módulo y lo utiliza para determinar
si el mensaje se debe enviar en X o en Y.

- Multiprocesadores NUMA
 Al igual que sus parientes UMA, proveen un solo espacio de
direcciones a través de todas
las CPUs, pero a diferencia éstas, el acceso a los módulos de memoria
locales es más rápido que el acceso a los remotos. Por ende, todos los
programas UMA se ejecutarán sin cambios en las máquinas NUMA, pero el
rendimiento será peor a la misma velocidad de reloj.
Poseen tres características clave que, en conjunto, las distinguen de
otros
multiprocesadores:
1. Hay un solo espacio de direcciones visible para todas las CPUs.
2. El acceso a la memoria remota es mediante instrucciones LOAD y
STORE.
3. El acceso a la memoria remota es más lento que el acceso a la
memoria local.

Cuando el tiempo de acceso a la memoria remota no está oculto

(debido a que no hay caché), al sistema se le llama NC-NUMA (No Cache
NUMA, NUMA sin caché).
Cuando hay cachés coherentes presentes, al sistema se le llama CC-
NUMA (Cache-Coherent NUMA, NUMA con cachés coherentes).

El método más popular para construir grandes multiprocesadores CC-

NUMA en la actualidad es el multiprocesador basado en directorios. La idea
es mantener una base de datos que indique dónde está cada línea de
caché y cuál es su estado. Cuando se hace referencia a una línea de
caché, se consulta la base de datos para averiguar dónde está, y si está
limpia o sucia (modificada). Como esta base de datos se debe consultar en
cada instrucción que hace referencia a la memoria, debe mantenerse en
un hardware de propósito especial, en extremo veloz, que pueda responder
en una fracción de un ciclo del bus.
Tipos de sistemas operativos multiprocesador
Hay varias metodologías posibles:

- Cada CPU tiene su propio sistema operativo.

La manera más simple posible de organizar un sistema operativo
multiprocesador es dividir estáticamente la memoria y su propia copia
privada del sistema operativo.
En efecto, las n CPUs operan entonces como n computadoras
independientes.
Una optimización obvia es permitir que todas las CPUs compartan el
código del sistema operativo y obtengan copias privadas sólo de las
estructuras de datos del sistema operativo.
 Este esquema es aún mejor que tener n computadoras separadas, ya
que permite que todas las máquinas compartan un conjunto de discos y
otros dispositivos de E/S, y también permite compartir la memoria con
flexibilidad. Por ejemplo, aun con la asignación estática de memoria, una
CPU puede recibir una porción extra-grande de la memoria para poder
manejar con eficiencia los
programas grandes. Además, los procesos pueden comunicarse de manera
eficiente unos con otros,
al permitir que un productor escriba los datos directamente en la memoria y
que un consumidor
los obtenga del lugar en el que los escribió el productor. Aún así, desde la
perspectiva de un sistema
operativo, el que cada CPU tenga su propio sistema operativo es lo más
primitivo posible.

Vale la pena mencionar cuatro aspectos de este diseño que tal vez no sean
obvios.
En primer lugar, cuando un proceso realiza una llamada al sistema,
ésta se atrapa y maneja en su propia CPU, usando las estructuras de datos
en las tablas de ese sistema operativo.
En segundo lugar, como cada sistema operativo tiene sus propias
tablas, también tiene su propio conjunto de procesos que programa por su
cuenta. No hay compartición de procesos. Si un usuario se conecta a la CPU
1, todos sus procesos se ejecutan en la CPU 1. Como consecuencia, puede
ocurrir que la CPU 1 esté inactiva mientras la CPU 2 está cargada de trabajo.
En tercer lugar, no hay compartición de páginas. Puede ocurrir que la
CPU 1 tenga páginas de sobra, mientras que la CPU 2 esté paginando en
forma continua. No hay forma de que la CPU 2 pida prestadas algunas
páginas a la CPU 1, ya que la asignación de memoria es fija.
En cuarto lugar (y lo que es peor), si el sistema operativo mantiene una
caché en búfer de los bloques de disco de uso reciente, cada sistema
operativo hace esto de manera independiente a los demás. Por ende,
puede ocurrir que haya cierto bloque de disco presente y sucio en varias Commented [1]: waaa
cachés de búfer al mismo tiempo, con lo cual se producirán resultados
inconsistentes. La única forma de evitar este problema es eliminar las cachés
del búfer. Eso no es tan difícil, pero daña el rendimiento en forma
considerable.
Por estas razones, es muy raro que se utilice este modelo hoy en día.

-Multiprocesadores maestro-esclavo
En la figura se muestra un segundo modelo, donde, hay una copia del
sistema operativo y sus tablas presente en la CPU1, y nada más ahí. Todas las
llamadas al sistema se redirigen a la CPU1 para procesarlas ahí. La CPU1
también puede ejecutar proceso de usuario si tiene tiempo de sobra. A este
modelo se le conoce como maestro-esclavo, ya que la CPU 1 es el maestro
y todas los demás son los esclavos.

El modelo maestro-esclavo resuelve la mayoría de los problemas del

primer modelo.
Hay una sola estructura de datos (por ejemplo, una lista o un conjunto
de listas con prioridades) que lleva la cuenta de los procesos listos. Cuando
una CPU está inactiva, pide al sistema operativo en la CPU1 un proceso para
ejecutarlo, y se le asigna uno. Por ende, nunca puede ocurrir que una CPU
esté inactiva mientras que otra esté sobrecargada. De manera similar, se
pueden asignar las páginas entre todos los procesos en forma dinámica y
sólo hay una caché de búffer, por lo que nunca ocurren inconsistencias.

El problema con este modelo es que con muchas CPUs, el maestro se

convertirá en un cuello de botella. Después de todo, debe manejar todas las
llamadas al sistema de todas las CPUs. Por ende, este modelo es simple y
funciona para pequeños multiprocesadores, pero no para los grandes.
- Multiprocesadores simétricos
El SMP (Multiprocesador simétrico), elimina la asimetría.
Hay una copia del sistema operativo en memoria, pero cualquier CPU
puede ejecutarlo. Cuando se hace una llamada al sistema, la CPU en
la que se hizo la llamada al sistema atrapa para el kernel y procesa la
llamada al sistema.

Este modelo equilibra los procesos y la memoria en forma dinámica,

ya que sólo hay un conjunto de tablas del sistema operativo.
También elimina el cuello de botella de la CPU, ya que no hay
maestro.
Pero introduce sus propios problemas. En especial, si dos o más CPUs
están ejecutando código del sistema operativo al mismo tiempo, se puede
producir un desastre.
Imagine que dos CPUs seleccionan el mismo proceso para ejecutarlo,
o que reclaman la misma página de memoria libre.
La solución más simple para estos problemas es asociar un mutex (es
decir, bloqueo) con el
sistema operativo, convirtiendo a todo el sistema en una gran región crítica.
Cuando una CPU desea
ejecutar código del sistema operativo, debe adquirir primero el mutex. Si el
mutex está bloqueado,
sólo espera. De esta forma, cualquier CPU puede ejecutar el sistema
operativo, pero sólo una a la vez.
Este modelo funciona, pero casi tan mal como el modelo maestro-
esclavo, si tengo muchas CPU S tendré a varias esperando inactivas para
poder entrar a la sección critica. Por fortuna, es fácil de mejorar. Muchas
partes del sistema operativo son independientes unas de otras. Por ejemplo,
no habría problema si una CPU ejecutara el planificador mientras que otra
CPU manejara una llamada al sistema de archivos, y una tercera CPU
estuviera procesando un fallo de página.
Esta observación ocasiona que se divida el sistema operativo en varias
regiones críticas independientes que no interactúan entre sí. Cada región
crítica está protegida por su propio mutex, por lo que sólo una CPU a la vez
puede ejecutarlo. De esta forma se puede lograr mucho más paralelismo.
Sin embargo, puede ocurrir que algunas tablas (como las de procesos)
sean utilizadas por varias regiones críticas. Por ejemplo, la tabla de procesos
es necesaria para la programación, perotambién para la llamada al sistema
fork y para el manejo de señales. Cada tabla que pueda ser utilizada por
varias regiones críticas necesita su propio mutex. De esta forma, cada región
crítica se
puede ejecutar sólo por una CPU a la vez, y cada tabla crítica se puede
utilizar sólo por una CPU a
la vez.
La mayoría de los multiprocesadores modernos utilizan esta
organización. La parte difícil sobre escribir el sistema operativo para una
máquina de este tipo es dividirlo en regiones críticas que se puedan ejecutar
de manera concurrente por distintas CPUs sin interferir unas con otras, ni
siquiera en formas sutiles e indirectas. Además, cada tabla utilizada por dos
o más regiones críticas
debe estar protegida por separado por un mutex, y todo el código que
utilice la tabla debe utilizar
el mutex en forma correcta.
- Sincronización de multiprocesadores

Son necesarias primitivas de sincronización apropiadas.

Si un proceso en una máquina uniprocesador (sólo una CPU) realiza
una llamada al sistema que requiera acceder a cierta tabla crítica del
kernel, el código del kernel sólo tiene que deshabilitar las interrupciones
antes de tocar la tabla. Después puede hacer su trabajo, sabiendo que
podrá terminar sin que ningún otro proceso se entrometa y toque la tabla
antes de que haya terminado. Ç En un sistema multiprocesador,
deshabilitar las interrupciones sólo afecta a esa CPU, deshabilitándola. Las
demás CPUs se siguen ejecutando y aún pueden tocar la tabla crítica.
Como consecuencia, se debe utilizar un protocolo de mutex apropiado, el
cual debe ser respetado por todas las CPUs para garantizar que funcione la
exclusión mutua

El corazón de cualquier protocolo de mutex práctico es una

instrucción especial que permita
inspeccionar una palabra de memoria y establecerla en una operación
indivisible.

TSL (Probar y establecer bloqueo) instrucción utilizada para

implementar regiones críticas.
Lo que hace esta instrucción es leer una palabra de memoria y
almacenarla en un registro. Al mismo tiempo, escribe un 1 (o cualquier otro
valor distinto de cero) en la palabra de memoria. Desde luego que se
requieren dos ciclos de bus para realizar las operaciones de lectura y
escritura de memoria.
En un uniprocesador, mientras que la instrucción no se pueda
descomponer a mitad de ejecución, TSL siempre funcionará como se
espera.
Llevado al caso de un multiprocesador puede ocurrir lo siguiente. En la
figura se puede ver la sincronización en el peor caso,
la palabra de memoria 1000, que se utiliza como bloqueo, en un
principio es 0.
En el paso 1, la CPU 1 lee la palabra y obtiene un 0.
En el paso 2, antes de que la CPU 1 tenga la oportunidad de volver a
escribir la palabra para que sea 1, la CPU 2 entra y también lee la
palabra como un 0.
En el paso 3, la CPU 1 escribe un 1 en la palabra.
En el paso 4, la CPU 2 también escribe un 1 en la palabra.

Ambas CPUs obtuvieron un 0 de la instrucción TSL, por lo que ambas tienen

ahora acceso a la región crítica y falla la exclusión mutua.
 Para evitar este problema, la instrucción TSL debe primero bloquear el
bus, para evitar que otras CPUs lo utilicen; después realizar ambos accesos a
la memoria, y luego desbloquear el bus.

Si la instrucción TSL se implementa y utiliza en forma correcta, garantiza

que la exclusión
mutua pueda llegar a funcionar. Sin embargo, este método de exclusión
mutua utiliza un bloqueo
de giro (Spin-lock) debido a que la CPU que hace la petición sólo espera en
un ciclo estrecho, evaluando el bloqueo lo más rápido que pueda. No sólo
se desperdicia por completo el tiempo de la CPU (o CPUs) que hace la
petición, sino que también se puede imponer una carga masiva en el bus o
la memoria, reduciendo considerablemente a todas las demás CPUs que
tratan de realizar su trabajo normal.
El uso de caches para tratar de eliminar la contención del bus trae
otros problemas:
Como la instrucción TSL es una escritura (ya que modifica el bloqueo),
necesita acceso exclusivo al bloque de la caché que contiene el bloqueo.
Por lo tanto, cada instrucción TSL invalida el bloqueo en la caché de la
CPU que contiene el
bloqueo y obtiene una copia privada y exclusiva para la CPU que hace la
petición. Tan pronto como
la CPU que contiene el bloqueo toca una palabra adyacente al mismo, el
bloque de la caché se mueve a su máquina. En consecuencia, todo el
bloque de la caché que contiene el bloqueo se transporta constantemente
entre el propietario del bloqueo y el que solicita el bloqueo, generando aún
más tráfico en el bus que las lecturas individuales en la palabra de bloqueo
 La solución seria deshacernos de todas las escrituras inducidas por TSL
en el lado que hace la petición, esto reduciria el thrashing de caché en
forma considerable. Este objetivo se puede
lograr al hacer que la CPU que hace la petición realice primero una lectura
pura, para ver si el bloqueo está libre. Sólo si el bloqueo parece estar libre es
cuando se realiza una TSL para poder adquirirlo.
El resultado de este pequeño cambio es que la mayoría de los
sondeos serán ahora lecturas
en vez de escrituras. Si la CPU que contiene el bloqueo sólo lee las variables
en el mismo bloque
de caché, cada una de ellas puede tener una copia del bloque de la
caché en modo de sólo lectura
compartido, eliminando todas las transferencias del bloque de caché.
Cuando por fin se libera el bloqueo, el propietario realiza una escritura,
la cual requiere acceso exclusivo, con lo cual se invalidan todas las otras
copias en las cachés remotas. En la siguiente lectura que realice la CPU que
hace la petición, el bloque de la caché se volverá a cargar. Si hay dos o
más CPUs contendiendo por el mismo bloqueo, puede ocurrir que ambas
vean que está libre al mismo tiempo, y ambas puedan llegar a realizar una
operación TSL simultánea para adquirirlo. Sólo una de estas operaciones
tendrá éxito, por lo que no hay condición de competencia aquí debido a
que la verdadera adquisición la realiza la instrucción TSL, y esta instrucción es
atómica.
Detectar que el bloqueo está libre y tratar de obtenerlo de inmediato
con una operación TSL no garantiza la obtención del mismo. Alguien más
podría ganar, pero para que el algoritmo sea correcto, no importa quién lo
obtenga. El éxito en la lectura pura es tan sólo una sugerencia de que sería
un buen momento de adquirir el bloqueo, pero no constituye una garantía
de que la adquisición tendrá éxito

Otras Soluciones:
mediante el uso del algoritmo de backoff exponencial binario de
Ethernet (Anderson, 1990). En vez de sondear en forma continua, se
puede insertar un ciclo de retraso entre los sondeos. Al principio, el
retraso es una instrucción. Si el bloqueo sigue ocupado, el retraso se
duplica a dos instrucciones, después a cuatro instrucciones, y así hasta
llegar a cierto valor máximo. Un máximo bajo ofrece una respuesta
rápida
 cuando se libera el bloqueo, pero desperdicia más ciclos de bus en el
thrashing de la caché. Un máximo alto reduce el thrashing de la
caché a expensas de no observar que el bloque está libre con tanta
rapidez.
El algoritmo de backoff exponencial binario se puede utilizar con o sin
las lecturas puras que van antes de la instrucción TSL.
Una idea mejor incluso es proporcionar a cada CPU que desea
adquirir el mutex su propia variable de bloqueo privada para
evaluarla.
La variable debe residir en un bloque de caché no utilizado, para
evitar conflictos. El
algoritmo funciona al hacer que una CPU que no puede adquirir el
bloqueo asigne una variable de bloqueo y se adjunte a sí misma al
final de una lista de CPUs que esperan el bloqueo.
Cuando la CPU que contiene el bloque sale de la región crítica, libera
el bloqueo privado que la primera CPU en la lista está evaluando (en
su propia caché). Después, esta CPU entra a la región crítica. Cuando
termina, libera el bloqueo que está usando su sucesora, y así en lo
sucesivo.
Aunque el protocolo es algo complicado (para evitar que dos CPUs se
adjunten a sí mismas al final de la lista al mismo tiempo), es eficiente y
libre de inanición.

- Planificación de multiprocesadores

Antes se planificaba procesos, pero hoy en día con sistemas de procesos

multihilo hay que tener en cuenta otras cosas:

Es importante saber si los hilos son de kernel o de usuario. Si la ejecución de

hilos se lleva a cabo mediante una biblioteca en espacio de usuario y el kernel no
sabe nada acerca de los hilos, entonces la planificación se lleva a cabo con base
en cada proceso, como siempre. Si el kernel ni siquiera sabe que los hilos existen, es
muy difícil que pueda planificarlos.

Con los hilos del kernel sucede algo distinto. Aquí el kernel está al tanto de
todos los hilos y puede elegir y seleccionar de entre los hilos que pertenecen a un
proceso. En estos sistemas, la tendencia es que el kernel seleccione un hilo para
ejecutarlo, y el proceso al que pertenece sólo tiene un pequeño papel (o tal vez
ninguno) en el algoritmo de selección de hilos.
 Proceso contra hilo no es la única cuestión de planificación.

En un uniprocesador, la planificación es de una dimensión.

● “¿Cuál hilo se debe ejecutar a continuación?”.

En un multiprocesador, la planificación tiene dos dimensiones:

● qué hilo ejecutar y

● en cuál CPU lo va a ejecutar.

Esta dimensión adicional complica de manera considerable la planificación

en los multiprocesadores.
Otro factor que complica las cosas es que, en ciertos sistemas, ninguno de
los hilos está relacionado, mientras que en otros se dividen en grupos donde todos
pertenecen a la misma aplicación y trabajan en conjunto.

Tiempo compartido
Caso de la programación de hilos independientes.
El algoritmo de planificación más simple para lidiar con hilos no relacionados
es tener una sola estructura de datos a nivel de sistema para los hilos que estén
listos, que tal vez sea sólo una lista, pero es mucho más probable que sea un
conjunto de listas para los hilos con distintas prioridades.
En la imagen, las 16 CPUs están ocupadas en un momento dado, y hay un
conjunto de 14 hilos por orden de prioridad, esperando ser ejecutados.
La primera CPU en terminar su trabajo actual (o en hacer que su hilo se
bloquee) es la CPU 4, que después bloquea las colas de programación y
selecciona el hilo con mayor prioridad (A), como se muestra en la figura 8-12(b). A
continuación, la CPU 12 queda inactiva y selecciona el hilo B, como se ilustra en la
figura 8-12(c). Mientras que los hilos no esten relacionados de ninguna manera, es
una opción razonable llevar a cabo la planificación de esta forma, y es muy simple
de implementar con eficiencia.
 Al tener una sola estructura de datos de planificación utilizada por todas las
CPUs, éstas se comparten en el tiempo, de igual forma que como se hace en un
sistema uniprocesador.
También se proporciona un balance automático de la carga, ya que no
puede haber una CPU inactiva mientras otras están sobrecargadas.
Dos desventajas de este método son:
1. la potencial contención por la estructura de datos que se utiliza
en la programación a medida que aumenta el número de
CPUs, y
2. la sobrecarga usual que se produce al realizar un cambio de
contexto, cuando un hilo se bloquea en espera de una
operación de E/S.

soluciones:

Algunos sistemas utilizan la planificación inteligente, en la cuál un hilo que

adquiere un bloqueo de espera activa establece una bandera a nivel de proceso,
para mostrar que actualmente tiene un bloqueo de espera activa. Al liberar el
bloqueo, se borra la bandera. Así, el planificador no detiene un hilo que contenga
un bloqueo de espera activa, sino que le da un poco más de tiempo para que
complete su región crítica y libere el bloqueo.

Planificación por afinidad. Aquí, la idea básica es esforzarse en serio por

hacer que un hilo se ejecute en la misma CPU en que se ejecutó la última vez.,
teniendo en cuenta que cuando el subproceso A se ha ejecutado durante mucho
tiempo en la CPU k, la caché de esta CPU estará llena de bloques de A. Si A se
vuelve a ejecutar poco tiempo después, tal vez su rendimiento sea mejor si se
ejecuta en la misma CPU debido a que la caché de esta tal vez todavía contenga
algunos de los bloques de A.
Una manera de crear esta afinidad es mediante el uso de un algoritmo de
planificación de dos niveles. Cuando se crea un hilo, éste se asigna a una CPU, por
ejemplo con base en cuál de las CPUs tiene la menor carga en ese momento. Esta
asignación de hilos a CPUs es el nivel superior del algoritmo. Como resultado de
esta directiva, cada CPU adquiere su propia colección de hilos.
La planificación actual de los hilos es el nivel inferior del algoritmo. Cada CPU
la realiza por separado, mediante el uso de prioridades o de algún otro medio. Al
tratar de mantener un hilo en la misma CPU durante todo su tiempo de vida, se
maximiza la afinidad de la caché. No obstante, si una CPU no tiene hilos qué
ejecutar, obtiene uno de otra CPU en vez de quedar inactiva.
La planificación de dos niveles tiene tres beneficios.
1. En primer lugar, distribuye la carga de una manera casi uniforme sobre las
CPUs disponibles.
2. En segundo lugar, se aprovecha la afinidad de la caché siempre que sea
posible
3. En tercer lugar, al dar a cada CPU su propia lista de hilos listos se minimiza la
contención por estas listas, ya que es muy poco frecuente que una CPU
intente utilizar la lista de hilos listos de otra CPU.

Espacio compartido
Planificación cuando los hilos están relacionados entre sí de alguna manera
y están esparcidos en distintas CPUs.
El algoritmo de espacio compartido más simple funciona de la siguiente
manera: Suponga que se crea un grupo completo de hilos relacionados al mismo
tiempo. Al momento de su creación, el programador comprueba si hay tantas CPUs
libres como el número de hilos.
Si las hay, a cada hilo se le proporciona su propia CPU dedicada (es decir,
sin multiprogramación) y todos empiezan su ejecución.
Si no hay suficientes CPUs, ninguno de los hilos se iniciará, sino hasta que
haya suficientes CPUs disponibles.
Cada hilo se aferra a su CPU hasta que termina, y en ese momento la CPU se
regresa a la reserva de CPUs disponibles. Si un hilo se bloquea en espera de una
operación de E/S, de todas formas retiene a la CPU, que simplemente se queda
inactiva hasta que el hilo se despierta. Cuando aparece el siguiente lote de hilos, se
aplica el mismo algoritmo.
 El problema de este diseño es que al no haber multiprogramación baja la
productividad.

Solución: “Planificación por pandillas”

Consta de tres partes:

1. Los grupos de hilos relacionados se programan como una unidad, o pandilla.
2. Todos los miembros de una plantilla se ejecutan en forma simultánea, en distintas
CPUs de tiempo compartido.
3. Todos los miembros de la pandilla inician y terminan sus intervalos en conjunto.
El truco que hace funcionar la planificación por pandilla es que todas las
CPUs se planifican en forma asíncrona. Esto significa que el tiempo se divide en
quantums discretos
Al inicio de cada nuevo quantum todas las CPUs se reprograman, y se inicia
un nuevo hilo en cada CPU. Al inicio del siguiente quantum ocurre otro evento de
planificación. En el intervalo no se realiza ninguna planificación. Si un hilo se
bloquea, su CPU permanece inactiva hasta el final del quantum.
La idea de la planificación por pandilla es que todos los hilos de un hilo se
ejecuten en conjunto, de manera que si uno de ellos envía una petición a otro,
recibirá el mensaje casi de inmediato y podrá responder también casi de
inmediato.

MULTICOMPUTADORAS

Alternativa debido a que es muy difícil y costoso la construcción de

multiprocesadores a gran escala.
Son CPUs con acoplamiento fuerte que no comparten memoria.
Estos sistemas también son conocidos por una variedad de nombres,
incluyendo
clúster de computadoras y COWS (Clusters of Workstations, Clústeres de estaciones
de trabajo).
Fáciles de construir, ya que el componente básico es una PC que tiene sólo
los componentes esenciales, además de una tarjeta de interfaz de red de alto
rendimiento. El secreto para obtener un alto rendimiento es diseñar de manera
inteligente la red de interconexión y la tarjeta de interfaz. Este problema es
completamente análogo al de construir la memoria compartida en un
multiprocesador. Sin embargo, el objetivo es enviar mensajes en una escala de
tiempo en microsegundos, en vez de acceder a la memoria en una escala de
tiempo de nanosegundos, por lo que es más simple, económico y fácil de lograr.

- Hardware de una multicomputadora

El nodo básico de una multicomputadora consiste en una CPU, la memoria,
una interfaz de red y algunas veces un disco duro. En algunos casos la PC contiene
un tablero de multiprocesador de 2 o 4 vías, en donde cada nodo posiblemente
tiene un chip de doble o cuádruple núcleo en vez de una sola CPU.
A menudo se conectan cientos, o incluso miles de nodos entre sí, para formar
una multicomputadora.

Tecnología de interconexión
Cada nodo tiene una tarjeta de interfaz de red, de la cual salen uno o dos
cables (o fibras). Estos cables se conectan a otros nodos o a switches.
Topologías de interconexión:
● topología de estrella: un switch al que están conectados todos los
nodos
● anillo: los nodos forman un anillo con dos cables que provienen de la
tarjeta de interfaz de red: uno que entra al nodo por la izquierda y
otro que sale del nodo por la derecha
● rejilla o malla: diseño bidimensional que se ha utilizado en muchos
sistemas comerciales. Es muy regular y tiene la facilidad de poder
escalar a tamaños mayores.
Tiene un diámetro, que es la ruta más larga entre dos nodos
cualesquiera, y que aumenta sólo con base en la raíz cuadrada del
número de nodos.
● doble toroide: una rejilla con los bordes conectados. No sólo es más
tolerante a fallas que la rejilla, sino que el diámetro es también menor
debido a que las esquinas opuestas ahora se pueden comunicar en
sólo dos saltos
● cubo: constituye una topología tridimensional regular.
 En las multicomputadoras se utilizan dos tipos de esquemas de conmutación.

En el primero, cada mensaje primero se divide en un trozo de cierta longitud

máxima, conocido como paquete.
El esquema de conmutación, conocido como almacenamiento de
conmutación
de paquetes y retransmisión, consiste en inyectar el paquete en el primer switch
mediante la tarjeta de interfaz de red del nodo de origen. Los bits llegan uno a la
vez, y cuando llega todo el paquete en un búfer de entrada, se copia a la línea
que conduce al siguiente switch a lo largo de la ruta. Cuando llega el paquete al
switch conectado al nodo de destino, el paquete se copia a la tarjeta de interfaz
de red de ese nodo, y en un momento dado también se copia a la RAM.
Aunque el almacenamiento de conmutación de paquetes y retransmisión es
flexible y eficiente, tiene el problema de que la latencia (retraso) aumenta a través
de la red de interconexión.
El otro régimen de conmutación, conocido como conmutación de circuitos,
consiste en que el primer switch establece primero una ruta a través de todos los
switches, hasta el switch de destino.
 Una vez que se ha establecido esa ruta, los bits se inyectan desde el origen
hasta el destino, sin detenerse y con la mayor rapidez posible. No hay búfer en los
switches intermedios.
La conmutación de circuitos requiere una fase de configuración, que
requiere cierto tiempo, pero es más rápida una vez que se ha completado esta
fase. Al enviarse el paquete, la ruta se debe deshacer.
Hay una variación de la conmutación de circuitos, conocida como
enrutamiento segmentado (wormhole routing), que divide cada paquete en
subpaquetes y permite que el primer subpaquete empiece a fluir, incluso antes de
que se haya construido la ruta completa.

Interfaces de red

Todos los nodos en una multicomputadora tienen una tarjeta insertable que
contiene la conexión del nodo hacia la red de interconexión, la cual mantiene
unida toda la multicomputadora.
La forma en que están construidas estas tarjetas y la manera en que se
conectan a la CPU principal y la RAM tienen consecuencias considerables para el
sistema operativo.
En casi todas las multicomputadoras, la tarjeta de interfaz contiene una
cantidad considerable de RAM para contener los paquetes salientes y entrantes.
Por lo general, un paquete saliente se tiene que copiar a la RAM de la tarjeta de
interfaz antes de poder transmitirlo al primer switch. La razón de este diseño es que
muchas redes de interconexión son asíncronas, por lo que una vez que se inicia la
transmisión de un paquete, los bits deben seguir fluyendo a un ritmo constante. Si el
paquete está en la RAM principal no se puede garantizar este flujo continuo hacia
la red, debido al tráfico adicional en el bus de memoria. Para eliminar este
problema se utiliza una RAM dedicada
en la tarjeta de interfaz.

-Software de comunicación de bajo nivel

El enemigo de la comunicación de alto rendimiento en los sistemas de

multicomputadora es el copiado de paquetes en exceso.
En el mejor caso, habrá una copia de la RAM a la tarjeta de interfaz en el
nodo de origen, una copia de la tarjeta de interfaz de origen a la tarjeta de interfaz
de destino
(si no hay almacenamiento y retransmisión a lo largo de la ruta), y una copia de ahí
a la RAM de destino: un total de tres copias.
Para evitar este impacto en el rendimiento, muchas multicomputadoras
asignan la tarjeta de interfaz directamente al espacio de usuario y permiten que el
proceso de usuario coloque los paquetes en la tarjeta directamente, sin que el
kernel se involucre.
Este método ayuda al rendimiento, pero introduce dos problemas.
En primer lugar, ¿qué tal si hay varios procesos en ejecución en el nodo y
necesitan acceso a la red para enviar paquetes? ¿Cuál obtiene la tarjeta de
interfaz en su espacio de direcciones? Es problemático hacer una llamada al
sistema para asignar la tarjeta y desasignarla de un espacio de direcciones
virtuales, pero si sólo un proceso obtiene la tarjeta, ¿cómo envían paquetes los
demás procesos? ¿Y qué ocurre si la tarjeta está asignada al espacio de
direcciones virtuales del proceso A y llega un paquete para el proceso B, en
especial si A y B tienen distintos propietarios, ninguno de los cuales desea hacer un
esfuerzo por ayudar al otro?
Una solución es asignar la tarjeta de interfaz a todos los procesos que la
necesitan, pero entonces se requiere un mecanismo para evitar condiciones de
competencia.
El segundo problema es que tal vez el kernel necesite acceso a la red de
interconexión en sí, por ejemplo, para acceder al sistema de archivos en un nodo
remoto. No es conveniente que el kernel comparta la tarjeta de interfaz con los
usuarios, ni siquiera cuando hay tiempo compartido.La conclusión es que el diseño
más simple es tener dos tarjetas de interfaz de red, una asignada al espacio de
usuario para el tráfico de las aplicaciones, y la otra asignada al espacio del kernel
para que la utilice el sistema operativo. Muchas multicomputadoras hacen
precisamente esto.

-Software de comunicación a nivel de usuario

Para comunicarse, los procesos en distintas CPUs en una multicomputadora

se envían mensajes entre sí.
En su forma más simple, este proceso de paso de mensajes está expuesto
para los procesos de usuario. En otras palabras, el sistema operativo proporciona la
forma de enviar y recibir mensajes, y los procedimientos de biblioteca hacen que
estas llamadas subyacentes estén disponibles para los procesos de usuario.

Enviar y recibir
 En su mínima expresión, los servicios de comunicación que se proporcionen
se pueden reducir a dos llamadas (de biblioteca), una para enviar mensajes y otra
para recibirlos.
La llamada para enviar un mensaje podría ser
send(dest, &mptr);
y la llamada para recibir un mensaje podría ser
receive(direc, &mptr);

La primera llamada envía el mensaje al que apunta mptr a un proceso

identificado por dest, y hace que el proceso que hizo la llamada se bloquee hasta
que se haya enviado el mensaje. La segunda llamada hace que el proceso que
hizo la llamada se bloquee hasta que llegue un mensaje.

Comparación entre llamadas con bloqueo y sin bloqueo

- llamadas con bloqueo (algunas veces se les conoce como llamadas
síncronas). Cuando un proceso llama a send, especifica un destino y un
búfer para enviarlo
a ese destino. Mientras se está enviando el mensaje, el proceso emisor se bloquea
(es decir, se suspende). La instrucción que sigue a la llamada a send no se ejecuta
sino hasta que el mensaje se haya enviado por completo.
De manera similar, una llamada a receive no devuelve el control sino hasta
que se haya recibido en realidad un mensaje y se haya colocado en el búfer al que
apunta el parámetro. El proceso permanece suspendido en receive hasta que
llega un mensaje, aunque tarde horas en llegar.
- llamadas sin bloqueo (llamadas asíncronas).
Sí send es sin bloqueo, devuelve de inmediato el control al proceso que hizo
la llamada, antes de enviar el mensaje.
La ventaja de este esquema es que el proceso emisor puede seguir
operando en paralelo con la transmisión del mensaje, en vez de que la CPU quede
inactiva
Desventaja: el emisor no puede modificar el búfer del mensaje sino hasta
que éste
se haya enviado. Las consecuencias de que el proceso sobrescriba el
mensaje durante la transmisión serian demasiado horribles como para
contemplarlas. Peor aún, el proceso emisor no tiene idea de cuándo terminará la
transmisión, por lo que nunca sabrá cuándo es seguro volver a utilizar el búfer.
Hay tres posibles soluciones.
 La primera es hacer que el kernel copie el mensaje a un búfer interno del
kernel y que después permita que continúe el proceso (desde el punto de vista del
emisor, este esquema es igual que una llamada con bloqueo).
La segunda solución es interrumpir al emisor cuando se haya enviado el
mensaje por completo, para informarle que el búfer está disponible otra vez. En este
caso no se requiere copia, lo cuál ahorra tiempo, pero las interrupciones a nivel de
usuario hacen que la programación sea engañosa, difícil y que esté sujeta a
condiciones de competencia, lo que las hace irreproducibles y casi imposibles de
depurar.
La tercera solución es hacer que el búfer copie al escribir; es decir, se marca
como de sólo lectura hasta que se haya enviado el mensaje. Si el búfer se vuelve a
utilizar antes de enviar el mensaje, se obtiene una copia.

En consecuencia, las opciones en el lado emisor son:

1. Envío con bloqueo (la CPU queda inactiva durante la transmisión del
mensaje).
2. Envío sin bloqueo con copia (se desperdicia el tiempo de la CPU por la
copia adicional).
3. Envío sin bloqueo con interrupción (dificulta la programación).
4. Copia al escribir (probablemente se requiera una copia adicional en un
momento dado).

Llamada a procedimiento remoto _ RPC (Remote Procedure Call)

Permite que los programas llamen a los procedimientos que se encuentran

en otras CPUs. Cuando un proceso en la máquina 1 llama a un procedimiento en la
máquina 2, el proceso que hizo la llamada en la máquina 1 se suspende, y se lleva
a cabo la ejecución del procedimiento al que llamó en la máquina 2. La
información se puede transportar del proceso que hizo la llamada al procedimiento
que llamó mediante los parámetros, y puede devolverse en el resultado del
procedimiento. El programador no puede ver el paso de mensajes ni las
operaciones de E/S.
Por tradición, el procedimiento que hace la llamada se denomina cliente y el
procedimiento al que se llamó se denomina servidor.
La idea detrás de RPC es hacer que una llamada a un procedimiento
remoto sea lo más parecida a una llamada local. En su forma más simple, para
llamar a un procedimiento remoto, el programa cliente se debe enlazar con un
pequeño procedimiento de biblioteca conocido como resguardo (stub) del cliente,
el cual representa al procedimiento del servidor en el espacio de direcciones del
cliente.
 De manera similar, el servidor se enlaza con un procedimiento conocido
como resguardo del servidor. Estos procedimientos ocultan el hecho de que la
llamada al procedimiento desde el cliente al servidor no es local.

El paso 1 es cuando el cliente llama al resguardo del cliente. Esta llamada es

una llamada a un procedimiento local, donde los parámetros se meten en la pila
de la manera usual.
El paso 2 es cuando el resguardo del cliente empaqueta los parámetros en
un mensaje y realiza una llamada al sistema para enviarlo. Al proceso de
empaquetar los parámetros se le conoce como marshaling.
El paso 3 es cuando el kernel envía el mensaje de la máquina cliente a la
máquina servidor.
El paso 4 es cuando el kernel pasa el paquete entrante al resguardo del
servidor (que por lo general llama a receive desde antes).
Por último, el paso 5 es cuando el resguardo del servidor llama al
procedimiento del servidor. La respuesta sigue la misma ruta en dirección opuesta.

-Planificación de multicomputadoras

La planificación de multicomputadoras es un proceso similar a la

planificación de multiprocesadores, pero no todos los algoritmos de la primera se
aplican a la segunda. Sin embargo, el algoritmo de multiprocesador más simple
(mantener una sola lista central de procesos listos) no funciona debido a que cada
proceso sólo se puede ejecutar en la CPU en la que se encuentra ubicado.
Sin embargo, al crear un nuevo proceso podemos elegir en dónde colocarlo,
por ejemplo para balancear la carga.
Como cada nodo tiene sus propios procesos, se puede utilizar cualquier
algoritmo de planificación local. No obstante, también es posible utilizar la
planificación de pandilla de los multiprocesadores, ya que tan sólo requiere un
acuerdo inicial sobre qué proceso se debe ejecutar en qué ranura de tiempo, y
alguna forma de coordinar el inicio de las ranuras de tiempo.

Balanceo de carga
Es importante saber decidir en qué nodo debe ir cada proceso. Esto es lo
contrario a los sistemas de multiprocesadores, en donde todos los proceso viven en
la misma memoria y se pueden programar en cualquier CPU que se desee.
En consecuencia, es conveniente analizar la forma en que se pueden
asignar los
procesos a los nodos de una manera efectiva.
Los algoritmos y la heurística para realizar esta asignación se conocen como
algoritmos de asignación de procesador.

Se basan en lo que “suponen que saben” de cada proceso

- Tiempo de CPU,
- memoria requerida,
- comunicación con otros procesos, etc.
Objetivos
- Minimizar ciclos de CPU desperdiciados debido a que el nodo no
tiene trabajo
- Minimizar el uso del ancho de banda en la comunicación
- Equidad para los procesos

Ejemplos:
- Algoritmo determinístico basado en teoría de grafos.
 Otra forma son los Algoritmos distribuidos.
- El proceso se ejecuta en el nodo que lo creo al menos que el mismo esté
sobrecargado
- Muchos procesos, genera trashing, etc.

- El nodo sale a buscar un nodo no sobrecargado para “pasarle” el proceso

Pueden existir problemas con sobrecarga del enlace si todos los nodos se
encuentran sobrecargados.
- Es posible también que un nodo con poca carga informe la situación
 SISTEMAS DISTRIBUIDOS

Procesamiento distribuido

 Compartir potencia de procesamiento

 cada nodo en un sistema distribuido es una computadora completa, con todo un
complemento de periféricos.
 los nodos de un sistema distribuido pueden estar esparcidos en todo el mundo
 los nodos de un sistema distribuido puede ejecutar un sistema operativo diferente,
cada uno con su propio sistema de archivos, y pueden estar bajo una administración
diferente.
 Comparación:

 Hardware de red
 Las redes se clasifican en dos variedades principales: LANs (Redes de área local), que
cubren un edificio o un campus, y las WANs (Redes de área amplia), que pueden ser
a nivel de ciudad, del país o incluso a nivel mundial.
 Para compartir ciclos de CPU se debe contar con una infraestructura distribuida
 Utilizar almacenamiento de otras computadoras.

¿Qué es Grid computing?

Un grid es una gran colección de máquinas dispersas geográficamente y por lo general heterogénea,
que se conecta mediante una red privada o Internet, y que ofrece un conjunto de servicios para sus
usuarios. Algunas veces se le compara con una supercomputadora virtual, pero es más que eso. Es
una colección de computadoras independientes, por lo general en varios dominios administrativos,
las cuales ejecutan un nivel común de middleware para permitir que los programas y usuarios
accedan a todos los recursos de una manera conveniente y consistente.

La idea es que cuando una organización no necesita todo su poder de cómputo (por ejemplo, en la
noche), otra organización (que tal vez se encuentre a varias zonas horarias de distancia) podría
recolectar esos ciclos y después regresarle el favor 12 horas más tarde. Ahora, los investigadores de
los grids también están interesados en compartir otros recursos, específicamente el hardware
especializado y las bases de datos.
Middleware

 Es una capa intermedia entre aplicaciones de usuarios y recursos computacionales y de

almacenamiento.

 Asiste a una aplicación para interactuar o comunicarse con otras aplicaciones, software,
redes, hardware y/o sistemas operativos.
 Provee una solución que mejora la calidad de servicio, seguridad, envío de mensajes,
directorio de servicios, etc.

Middleware basado en documentos:

 Un ejemplo claro es la web. El paradigma original detrás de Web era muy simple: cada
computadora podía contener uno o más documentos, llamados páginas Web. Cada página
Web contiene texto, imágenes, iconos, sonidos, películas y demás, así como hipervínculos
(apuntadores) a otras páginas Web. Cuando un usuario solicita una página Web mediante el
uso de un programa llamado navegador Web, la página se muestra en la pantalla. Al hacer
clic en un vínculo, la página actual se sustituye en la pantalla por la página a la que apunta el
vínculo.

Middleware basado en sistemas de archivos:

 Un modelo de sistema de archivos para un sistema distribuido significa que hay un solo
sistema de archivos global, en el que usuarios de todo el mundo tienen autorización de leer
y escribir en archivos. Para lograr la comunicación, un proceso tiene que escribir datos en un
archivo y otros procesos tienen que leer los datos de vuelta. Aquí surgen muchos de los
problemas estándar con los sistemas de archivos, pero también aparecen nuevos problemas
relacionados con la distribución.
 Modelo de transferencia:
 Existen 2 modelos
  Las ventajas del modelo de envío/descarga son su simplicidad y el hecho de
que es más eficiente transferir todos los datos entre archivos a la vez que
transferirlos en piezas pequeñas. Las desventajas son que debe haber
suficiente espacio de almacenamiento para todo el archivo en forma local,
desplazar el archivo completo es un desperdicio si sólo se necesitan piezas
de éste, y surgen problemas de consistencia si hay varios usuarios
concurrentes.

 La jerarquía de directorios:
 . El siguiente problema de diseño es si todos los clientes tienen la
misma vista de la jerarquía de directorios.
 Si todos los clientes tiene la misma vista del sistema de archivos
distribuido, si una ruta es válida para una máquina, será válida para
todas. Esta propiedad facilita la programación y comprensión del
sistema
 Si los clientes tienen distintas formas de ver el sistema una ruta de
acceso seria accesible para una máquina, pero no para las demás.
Esto se utiliza En los sistemas que administran varios sistemas de
archivos mediante el montaje remoto, Es flexible y simple de
implementar, pero tiene la desventaja de que no hace que todo el
sistema se comporte como un sistema individual de tiempo
compartido a la antigua.
 Transparencia de nomenclatura.
 hay tres métodos comunes para nombrar archivos y directorios en
un sistema distribuido:
 Usar la nomenclatura de máquina + ruta, como
/máquina/ruta o máquina: ruta.
 Montar los sistemas de archivos remotos en la jerarquía de
archivos local.
 Un solo espacio de nombres que sea igual para todas las
máquinas.
 Los primeros dos métodos son fáciles de implementar, en especial
como una forma de conectar los sistemas existentes que no fueron
diseñados para un uso distribuido. El tercer método es difícil y
requiere un diseño cuidadoso, pero facilita la vida a los
programadores y usuarios.

Middleware basado en objetos:

 Un sistema muy conocido que se basa en objetos en tiempo de ejecución es CORBA

  CORBA es un sistema cliente-servidor, en el que los procesos cliente en máquinas cliente
pueden invocar operaciones en objetos ubicados en máquinas servidores (posiblemente
remotos).
 Un problema grave con CORBA es que cada objeto se encuentra sólo en un servidor, lo cual
significa que el rendimiento será terrible para los objetos que se utilizan con mucha
frecuencia en máquinas cliente por todo el mundo.
 En la práctica, CORBA sólo funciona de manera aceptable en los sistemas de pequeña escala,
como los que se utilizan para conectar procesos en una computadora, una LAN o dentro de
una sola empresa.

Middleware basado en coordinación:

Linda:

 el cual es un sistema novel para comunicación y sincronización.

 En Linda, los procesos independientes se comunican mediante un espacio de tuplas
abstracto. El espacio de tuplas es global para todo el sistema, y los procesos en cualquier
máquina pueden insertar o quitar tuplas en el espacio de tuplas sin importar en dónde estén
almacenadas. Para el usuario, el espacio de tuplas parece una gran memoria compartida
global

Conceptos:

 Job 🡪 es una tarea computacional que el usuario desea ejecutar en la grid,

obteniendo sus resultados en su máquina local.

 “Job submission” 🡪 es la acción de delegar en la grid la ubicación del mejor recurso

computacional para ejecutar un Job y transferirlo allí para su ejecución.

 Organizaciones virtuales 🡪 grupo de usuarios y recursos con objetivos de

investigación comunes.
 Middleware 🡪 capa intermedia entre aplicaciones de usuario y recursos
computacionales y de almacenamiento.
 User interface 🡪 es el punto de entrada a la grid. Es parte de la estación de trabajo
del usuario
 Storage element 🡪 dispositivos de almacenamiento para almacenar o acceder a
archivos (independientemente de su localización geográfica)
 File catalogue (LFC)🡪 permite gestionar transferencias de archivos grandes y facilitar
la disponibilidad y localización de archivos de datos que los Jobs necesitan.
 Worker nodes (WN) 🡪 son las maquinas donde los Jobs son finalmente ejecutados.
Tiene un sistema de colas locales al cual se envían los Jobs.
 Computing element (CE) 🡪 es el punto de entrada al sistema de cola local.
 El Workload Management System (WMS) 🡪 es un conjunto de componentes cuyo
objetivo es encontrar el recurso que cumple con los requerimientos del Job de un
usuario entre los Ces disponibles.
 Information System and monitoring (IS y MON) 🡪 mantienen información sobre los
recursos disponibles y el estado del sistema.
 Logging and bookkeeping service (LB) 🡪 hace seguimiento de los eventos que le
ocurren a los Jobs.
 Virtual organization management service (VOMS) 🡪 provee mecanismos de
autenticación y autorización en el acceso a los recursos.
Scheduling, scavening

 El scheduler debería encontrar la maquina más apropiada para ejecutar un Job.

 Scavening (barrido): acción por lo que se detectan las máquinas y su situación.
 Puede haber maquinas no dedicadas totalmente a la GRID y otras dedicadas a la GRID.

Desventajas de grid computing

 Recursos heterogéneos (la grid debe poder manejarlos).

 Descubrimiento, selección, reserva, asignación, gestión y monitorización de recursos son
procesos que deben controlarse externamente.
 Las aplicaciones deben estar preparadas (gridificadas) para ejecutarse sobre una GRID.
 Temas organizativos: dominios de administración, modelo de explotación y costes, política
de seguridad...
 Económicos: precio de los recursos, ofertas/demandas…

Ventajas de grid computing

 Colaboración entre grupos dispersos geográficamente y con diferente equipamiento.

 Posibilita el funcionamiento de aplicaciones a gran escala
 Facilita el acceso a recursos distribuidos desde nuestros PC
 Campos:
 medicina (imágenes, diagnosis y tratamiento)
 Bioinformática
 Nanotecnología
 Ingeniería
 Recursos naturales y medio ambiente (previsión meteorológica, observación del
planeta, modelos y predicción de sistemas complejos).
 Todos estos objetivos y beneficios se engloban en la idea de “e-ciencia”.