Apartado 5.3: Modelos de multi

5.3 Modelos de multi-threading
Introducción
n
Cada POA puede especificar su política multi-thread
n
ORB_CTRL_MODEL
n
n
n
SINGLE_THREAD_MODEL
n
n
El ORB serializa las peticiones concurrentes que se hagan a objetos de
ese POA
Obsérvese que un servidor que tiene “n” POAs y cada uno con
SINGLE_THREAD_MODEL, puede tener un thread por cada POA
activo en un momento dado
n
n
El ORB puede ejecutar peticiones a objetos de ese POA en distintos
threads
El programador tiene que hacer su código thread-safe
Si los threads compartiesen alguna estructura de datos, ésta debería
ser thread-safe
CORBA no estandariza el modelo multi-thread que usa el ORB
para un POA con política ORB_CTRL_MODEL
n
Normalmente las implementaciones permiten especificar un modelo
concreto vía configuración
Modelo “uni-thread” (1)
Cliente 1
Cola peticiones
Cliente 2
Cliente 3
Servidor
Modelo “uni-thread” (y 2)
n
Existen distintas variantes
n
n
Algunas emplean varios threads para optimizar la ejecución de algunos
aspectos (ej.: unmarshalling y demultiplexación de peticiones en servidores,
etc.)
Normalmente las implementaciones permiten anidamiento de llamadas
(a cualquier nivel de profundidad) entre clientes y servidores
:ObjetoLocalCliente :ObjetoRemotoCliente
:ObjetoRemotoServidor
op1()
op2()
n
Ventaja
n
n
Sencillez de programación
Desventaja
n
Ineficiente en servidores con carga alta
Modelo “thread por petición” (1)
n
n
Es un modelo multi-thread y el código debe ser thread-safe
El ORB crea un nuevo thread para atender cada petición que
llegue, y lo destruye cuando ésta es satisfecha
Cliente 1
Thread para pet. 1
Pet. 1
Pet. 2
Thread para pet. 2
Thread para pet. 3
Pet. 3
Thread para pet. 4
Cliente 2
Pet. 4
Cliente 3
Servidor
Modelo “thread por petición” (y 2)
n
n
Funciona bien cuando el servidor recibe un número “pequeño”
de peticiones con tiempo de ejecución “grande”, y que además
pueden proceder en paralelo
Posible problema: el servidor puede recibir muchas peticiones
simultáneamente en un momento => consumo excesivo de
recursos
n
Memoria ocupada por la pila de cada thread, cambios de contexto
de threads, creación y destrucción de threads
Modelo “thread por conexión” (1)
n
n
n
Es un modelo multi-thread y el código debe ser thread-safe
Se crea un thread distinto por cada conexión que establece un
cliente, en el que se atenderán sus peticiones
También se suele llamar “thread por cliente” (si bien, no es un
nombre preciso)
Cliente 1
Thread para cliente 1
Cola pet. 1
Cola pet. 2
Thread para cliente 2
Cola pet. 3
Cliente 2
Thread para cliente 3
Cliente 3
Servidor
Modelo “thread por conexión” (y 2)
n
n
Funciona bien para aplicaciones en las que los clientes invocan
muchas peticiones sobre el mismo servidor durante un periodo
de tiempo grande, es decir, aplicaciones “orientadas a sesión
con el usuario”
Posible problema: el servidor puede tener muchos clientes
simultáneos en un momento dado => consumo excesivo de
recursos
Modelo “pool de threads” (1)
n
n
Es un modelo multi-thread y el código debe ser thread-safe
Cuando el servidor arranca, crea un pool de threads; cada
petición que llegue la servirá un thread cualquiera que esté libre
Pool de threads
...
Cliente 1
Cola peticiones
Cliente 2
Cliente 3
Servidor
Modelo “pool de threads” (y 2)
n
Funciona bien para servidores que quieren acotar recursos
n
n
n
Amortiza la creación y destrucción de threads
Posible problema: en situación de alta carga, el acceso a la cola
de peticiones pendientes puede originar muchos cambios de
contexto de threads
Para servidores multi-thread de propósito general es el mejor
modelo
n
n
No orientados a sesión con el usuario
Mezcla de peticiones con tiempo de ejecución grande y pequeño