You are on page 1of 22

Planificación de Hilos

• Planificación Apropiativa:
– Un hilo se suspende para dejar paso a otro hilo.

• Planificación No Apropiativa (de Corrutinas):


– El hilo realiza invocación al sistema de gestión de
hilos.
o Ventaja: secciones de código evitan competencia.
o Desventaja: no aprovecha sistemas multiprocesador.
– Tener cuidado con secciones de código grandes sin
llamadas al sistema (yield()).
– No aptos para aplicaciones en tiempo real.

• En general cada dominio de tiempo real tiene su
propia planificación de hilos.

Implementación de Hilos
Implementación de Hilos
Implementación de Hilos

• Se puede combinar las ventajas de estos dos


tipos de implementación.

– Indicar planificaciones de nivel de usuario al núcleo.


Implementación de Hilos
• Una mejora de a la planificación jerárquica es la
activación del planificador.
– El núcleo debe comunicar de las eventos relevantes en
su planificación.

• La activación del Planificador (SA):


– Componentes: núcleo ejecutándose en uno o mas
procesadores y las aplicaciones ejecutándose sobre
el.
– Cada aplicación contiene un planificador.
– El núcleo asigna procesadores virtuales a cada
proceso, la asignación depende de las características

Pro ce s
del proceso.
o A
N Ú C LE O

– Pro ce s
B
o
Implementación de Hilos
• La activación del Planificador:
– Es una llamada del núcleo al proceso para notificarle
de un evento.
– Se considera como una unidad de tiempo en un
procesador virtual.
– El planificador de usuario debe asignar sus hilos al
SA.
– El numero de SA es máximo el numero de
procesadores virtuales asignados al proceso.


Implementación de Hilos

• Los cuatro tipos de notificaciones son:


– Procesador Virtual Asignado.
– SA bloqueado.
– SA desbloqueado.
– SA apropiado

• Este esquema es potencialmente eficiente, ya
que ningún hilo de nivel de usuario estará en
estado de PREPARADO mientras exista un
procesador virtual sobre cual ejecutarse.

 Comunicación
 e Invocación
Primitivas de Sincronización

• La inserción de comunicación de alto nivel en el


núcleo tiene mayor eficiencia.
– Se usa primitivas de comunicación en grupo.
– El ahorro de llamadas al sistema es mayor de esta
forma.

• Por ejemplo, si el middleware proporciona RMI
sobre sockets el cliente debe realizar dos
llamadas al sistema de comunicaciones para
cada invocación remota.

• En la practica, el middleware proporciona la


mayor parte de los recursos de comunicación
de alto nivel.
Implementación de Hilos

• Desarrollar este software a nivel de usuario es


mas sencillo.
– Normalmente el middleware se implementa sobre
sockets con acceso a protocolos de Internet (TCP o
UDP).
– El uso de sockets proporciona portabilidad e
interoperabilidad.

• Aun así se esta desarrollando primitivas de
comunicación con menores costes sobre
núcleos experimentales.
Protocolos y Apertura
• Los sistemas operativos deben proporcionar
protocolos estándar.

– Deben permitir la intercomunicación middleware
sobre diferentes plataformas.
– Algunos núcleos incorporaban sus propios protocolos
de red (Amoeba RPC, VMTP y Sprite RPC).
– Otros núcleos dejaban la elección de los mismos de
manera abierta (Mach, Chorus). Estos núcleos
dejaban esta tarea a un servidor.

• Además, el middleware debe sacar partido de
protocolos de bajo nivel.
– Tecnologías inalámbricas (infrarrojos, BlueThoot) sin
actualizar aplicaciones.

Protocolos y Apertura

• Además, el middleware debe sacar partido de


protocolos de bajo nivel.

– Los protocolos se organizan en pilas de niveles.


– Integración estática de niveles: se incluye un nivel
tipo driver de manera permanente.

– Composición dinámica de protocolos: la pila de


protocolos se compone dinámicamente según los
requisitos de la aplicación.
– Ejemplo: El uso de un protocolo de solicitud-respuesta de
nivel de red inalámbrica para reducir latencias de ida y
vuelta.
Presentaciones de la Invocación

• Factor critico en el diseño de sistemas


distribuidos.
• Mientras mas separación de funcionalidad entre
espacios de direcciones , se necesitan mas
invocaciones remotas.
– Las fracciones de milisegundo son relevantes en los
costes de invocación.
– La sobrecarga de software es mayor a la de la red en
los tiempos de invocación (LAN o intranets).
– En la invocación remota sobre internet ocurre lo
contrario.

• RPC y RMI tienen gran aceptación como
mecanismos para el procesamiento cliente-
servidor de propósito general.
– Se las esta estudiando para aprovechar de mejor
Costes de Invocación

• Cada mecanismo de invocación provoca que


ejecute código fuera del objeto que invoca.
– Los mecanismos de invocación pueden ser síncronos
o asíncronos.
• Cada invocación supone la comunicación de
argumentos a este código y la devolución de
datos al que invoca.

Costes de Invocación

• Diferentes tipos de invocación.


Invocación Utilizando la Red

• RPC o RMI nulo:


– Sin parámetros, ejecuta procedimiento nulo y no


devuelve valores.
– NO lleva datos de usuario.
– Bajo ciertas condiciones toma un tiempo de decenas
de milisegundo.
– En contraste, una llamada convencional nulo toma
una fracción de us.
– Se envía un total de 100 Bytes.
– El mayor retardo se atribuye a las tareas del núcleo y
el código en tiempo de ejecución a nivel de
usuario.
– Estos costes son importantes porque miden la
latencia.
Invocación Utilizando la Red

• Con un RPC que solicita datos a un servidor:


– El retardo es casi proporcional al tamaño de datos
solicitados.
– También se debe considerar el AB, a mas datos
mayor ancho de banda.


Invocación Utilizando la Red

• Pasos de un RPC o RMI:


– El cliente empaqueta los argumentos de llamada, lo


envía y recibe y desempaqueta la respuesta.
– En el servidor, un hilo de trabajo recibe la solicitud
entrante e invoca el resguardo del servidor.
– El resguardo del servidor desempaqueta el mensaje,
invoca el procedimiento, empaqueta y envía la
repuesta.



Invocación Utilizando la Red

• Componentes significativos en el retardo de


invocación remota:
– Empaquetamiento.
– Copia de datos:
• En la frontera usuario y núcleo.
• En cada nivel de protocolo.
• Entre el interfaz de red y los buffers del núcleo.
– Inicialización de paquetes.
– Planificación de hilos y conmutación de contexto.
– Espera por reconocimientos.

• Un diseño cuidadoso del sistema operativo puede
ayudar a reducir algunos costes.

Compartición de Memoria

• Regiones Compartidas:
– Comunicación rápida entre un proceso usuario y
núcleo o entre procesos de usuario.
– Los datos se comunican mediante lectura y escritura
en esta región.
– Los datos no son copiados hacia o desde las
direcciones del núcleo.
– Aunque se puede necesitar llamadas al sistema e
interrupciones software para la sincronización.
– Se justifica si se la usa lo suficiente (minimizar al
coste de inicio).

• Aun con regiones compartidas el núcleo debe
copiar los datos del búfer a las interfaces de
red
– U-Net permite al código de usuario acceder
Elección del Protocolo

• Uso de TCP para las interacciones solicitud-


respuesta.
– Su retardo no necesariamente es peor que UDP.
– Se debe ser cuidadoso porque no fue diseñado para
este propósito.
– El almacenamiento en TCP puede impedir la
obtención de buenas prestaciones, además de las
sobrecargas por conexión.
– Se debe enviar el numero suficiente de mensajes por
la misma conexión para hacer despreciable esa
sobrecarga.

• TCP con HTTP:
– Las sobrecargas son evidentes en invocaciones web,
porque HTTP 1.0 hace una conexión diferente en
cada invocación.
– El arranque lento de TCP envía al inicio una ventana
Elección del Protocolo

• TCP con HTTP:


– HTTP 1.1 usa las conexiones persistentes, las cuales
permanecen luego de varias invocaciones.
– El coste inicial se amortiza si las invocaciones son al
mismo servidor .

• Almacenamiento por defecto del Sistema
Operativo:
– Desactivarlo afectaría negativamente en el retardo
de invocación.
– El búfer debe estar lleno para enviar los mensajes
juntos y no en paquetes separados.
– Se reduce la latencia introducida por cada paquete.
– Se usa un temporizador para saber cuando enviar los