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