1 Modelo de Computación Concurrente para un Sistema Operativo Orientado a Objetos basado en una...
-
Upload
fernando-romero-peralta -
Category
Documents
-
view
216 -
download
0
Transcript of 1 Modelo de Computación Concurrente para un Sistema Operativo Orientado a Objetos basado en una...
1
Modelo de Computación Concurrente para un Sistema Operativo Orientado a Objetos
basado en una Máquina Abstracta
Presentada por Lourdes Tajes Martínez
Dirigida por Dr. D. Juan Manuel Cueva Lovelle
Oviedo, 16 de Marzo de 2000
TESIS DOCTORAL
2
Contenidos de la presentación
Objetivos de la tesis
Ámbito conceptual: Soluciones a los problemas de caos e integración
Colaboración de máquina abstracta y sistema operativo: Reflectividad
Máquina abstracta
Sistema operativo
Prototipo
Conclusiones
Líneas futuras de investigación
3
Objetivos de la tesis
• Integración del paradigma de la OO en los sistemas informáticos
Poner orden en el caos de objetos
Integrar la computación en el entorno orientado a objetos
Flexibilidad– El sistema de soporte debe ser capaz de soportar adaptación en tiempo de
ejecución a los requerimientos de las aplicaciones
4
Caos de objetos
• Causas y consecuencias
• Soluciones actuales al caos: Parciales
Permiten la comunicación entre objetos Disminución del rendimiento Falta de transparencia de las soluciones Falta de uniformidad conceptual en torno a la OO
Capa básica de soporte no OO, abstracciones e interfaz tradicionales
Capas OOAdopción parcial
Adopción no uniforme
Salto semántico
Interoperabilidad
Aplicación OO
Sistema operativo no OOCapas para comunicar aplicación-SO
5
Objetivos de la tesis
• Integración del paradigma de la OO en los sistemas informáticos
Poner orden en el caos de objetos Necesidad de construir una plataforma de soporte de objetos
Integrar la computación en el entorno orientado a objetos– Integración homogénea de la computación de objetos en el sistema OO
– Problemas de integrar concurrencia y OO
Flexibilidad– El sistema de soporte debe ser capaz de soportar adaptación en tiempo de
ejecución a los requerimientos de las aplicaciones
6
Modelos de integración de la computación en el entorno OO
Abstracciones independientes para objetos y actividades– Separación clásica de recursos/procesos en los SO Modelo conocido, ampliamente difundido e implantado Robusto Abstracciones tradicionales poco adecuadas abstracciones paranoicas Demasiadas abstracciones: Dos dimensiones software Falta de uniformidad
Abstracción de objeto que encapsula las actividades– Implantación directa del modelo conceptual de entorno de objetos Uniformidad Objetos con semántica completa que refuerza la propiedad de encapsulación
7
Concurrencia en un entorno de computación OO
• El problema de la integridad del objeto
• El problema de la herencia
• Aproximaciones para la integración de concurrencia y OO– Aproximación ortogonal
– Aproximación heterogénea
– Aproximación homogénea
ObjetoEN
CA
P
CIÓN
SULA
Superclase
Subclase
method x1
method x2
method ...
SIN
CR
ON
IZA
CIÓ
N
method y1
method y2
method ...
SIN
CR
ON
IZA
CIÓ
N
¿SIN
CR
ON
IZA
CIÓ
N?
8
Objetivos de la tesis
• Integración del paradigma de la OO en los sistemas informáticos
Poner orden en el caos de objetos Necesidad de construir una plataforma de soporte de objetos
Integrar la computación en el entorno orientado a objetos
– Integración homogénea de la computación de objetos en el sistema OO
– Problemas de integrar concurrencia y OO
Flexibilidad– El sistema de soporte debe ser capaz de soportar adaptación en tiempo de
ejecución a los requerimientos de las aplicaciones
9
Contenidos de la presentación
Objetivos de la tesis
Ámbito conceptual de la tesis: Soluciones a los problemas de caos e integración
Colaboración de máquina abstracta y sistema operativo: Reflectividad
Máquina abstracta
Sistema operativo
Prototipo
Conclusiones
Líneas futuras de investigación
10
Ámbito conceptual de la tesis: Solución a los problemas de caos e integración
• Plataforma de soporte de objetos
• Requisitos funcionales y no funcionales para el entorno de computación
• Modelos de objetos para la computación
• Arquitectura del SOO: Requisitos, aproximaciones
• Propuesta de modelo de computación y estructura interna para el SOO
11
Plataforma de soporte de objetos: SOO• Soporte nativo a la abstracción de objeto• Uniformidad en torno a la OO: Modo de trabajo OO • Infraestructura del SOO: Mecanismos uniformes • Modelo único de objeto• Homogeneidad: Objetos con idénticas propiedades • Integrar computación de objetos en el sistema de soporte de objetos• Simplicidad
• Capa básica del sistema Hace posible la existencia de objetos
Facilita la interacción de objetos
Modelo de Objetos Común
Integración de la computación
Reduce la complejidad
Elimina Salto semántico
Soluciona interoperabilidad
Homogeneidad
12
Ámbito conceptual de la tesis: Solución a los problemas de caos e integración
Plataforma de soporte de objetos
• Requisitos funcionales y no funcionales para el entorno de computación
• Modelos de objetos para la computación
• Arquitectura del SOO: Requisitos, aproximaciones
• Propuesta de modelo de computación y estructura interna para el SOO
13
Requisitos funcionales
Abstracciones adecuadas– Única abstracción adecuada es el objeto
Interacción entre objetos: Mecanismo de comunicación uniforme– Comunicación, flujo de control e introducción de la concurrencia en el
sistema
– Modelos de paso de mensajes
Concurrencia y sincronización– Concurrencia y sincronización externas transparentes
– Concurrencia y sincronización internas transparentes a los clientes• Objetos serie: Un único procesador virtual por objeto
• Objetos concurrentes: Varios procesadores virtuales por objeto
Planificación– Gestionar el reparto de tiempo: Planificador
Gestión de excepciones
• Representa entidad del mundo real
• Conjunto de procesadores virtuales
14
Modelo Síncrono
Sencillo Extendido en los lenguajes Poca sobrecarga Limita el nivel de concurrencia
Objeto a origen de la invocación Objeto b destino de la invocación
Llamada y bloqueoc:=b.método(args); Transferencia de
control
Retorno del resultado
Ejecución del método solicitado
b::método(args):res{ ...
Reanudación método origen
Desbloqueo
Envío del mensaje
return (res);}
15
Modelo Asíncrono
Aumento del nivel de concurrencia Primitiva explícita de sincronización Complica el modelo de programación
Objeto b destino de la invocación
Ejecución del método solicitado
b::método(args):res{ ...
Objeto a origen de la invocación
Invocación de un método en el objeto destino
c:=b.método(args);
No implica un bloqueo inmediato que provoque
la transferencia de control
Retorno del resultado
Reanudación método origen
Recibe el resultado: Desbloqueo
Bloqueo esperando por el mensaje de respuesta
esperar();
return(res);
}
16
Modelo espera en caso necesario
Sencillez Eficiencia Aumento nivel concurrencia Poca sobrecarga adicional respecto al modelo síncrono Adecuado para ambientes paralelos y distribuidos
Intento de invocar un método del objeto resultado: bloqueo
c.metodo-de-c(args);
Objeto a origen de la invocación
Objeto b destino de la invocación
Invocación a un método en el objeto b
c:=b.metodo(args);
No implica transferencia de
control
Retorno del resultado
Ejecución del método solicitado
b::metodo(args):res{ ....
Reanudación método origen
Desbloqueoreturn(res);}
Complica el modelo de excepciones
17
Requisitos funcionales
Abstracciones adecuadas– Única abstracción adecuada es el objeto
Interacción entre objetos: Mecanismo de comunicación uniforme– Comunicación, flujo de control e introducción de la concurrencia en el sistema
– Modelos de paso de mensajes
Concurrencia y sincronización– Concurrencia y sincronización externas transparentes
– Concurrencia y sincronización internas transparentes a los clientes• Objetos serie: Un único procesador virtual por objeto
• Objetos concurrentes: Varios procesadores virtuales por objeto
Planificación– Gestionar el reparto de tiempo: Planificador
Gestión de excepciones
• Representa entidad del mundo real
• Conjunto de procesadores virtuales
Entrada al objeto: selecciona un método
Retorno
Objeto
Llamadas concurrentes a métodos
Fin de la ejecución del método m1. Puede comenzar la ejecución
de m2 o m3m1 m2 m3
m1
Entrada al objeto: permite la ejecución simultánea de varios
métodos
Retorno
Objeto
Llamadas concurrentes a métodos Fin de la ejecución del método m1m1 m2 m3
m1
m3m2
Fin de la ejecución del método m3
Fin de la ejecución del método m2
18
Requisitos funcionales
Abstracciones adecuadas– Única abstracción adecuada es el objeto
Interacción entre objetos: Mecanismo de comunicación uniforme– Comunicación, flujo de control e introducción de la concurrencia en el sistema
– Modelos de paso de mensajes
Concurrencia y sincronización– Concurrencia y sincronización externas transparentes
– Concurrencia y sincronización internas transparentes a los clientes• Objetos serie: Un único procesador virtual por objeto
• Objetos concurrentes: Varios procesadores virtuales por objeto
Planificación– Gestionar el reparto de tiempo: Planificador
Gestión de excepciones
• Representa entidad del mundo real
• Conjunto de procesadores virtuales
19
Requisitos no funcionales
Abstracción única– Deriva en modelo de programación donde no existen conceptos separados
para datos y procesos (Economía de Conceptos)
Visión uniforme del sistema– Estructurar el sistema como un conjunto de objetos que interaccionan
– Entorno sencillo y uniforme
– Abstracción potente
Mecanismo de computación flexible Eficiencia
Problema/Solución
Modelo/RepresentaciónObjetoMensaje
SOO
20
Ámbito conceptual de la tesis: Solución a los problemas de caos e integración
Plataforma de soporte de objetos
Requisitos funcionales y no funcionales para el entorno de computación
• Modelos de objetos para la computación
• Arquitectura del SOO: Requisitos, aproximaciones
• Propuesta de modelo de computación y estructura interna para el SOO
21
Modelo de objetos (1)• Modelo pasivo
– Objetos pasivos
– Objetos proceso
– Comunicación entre objetos: Invocación de métodos
P
Objeto A Objeto B Objeto C
Invocación
Resultado
Resultado
Objeto CInvocación
Objeto AHa
Objeto B
Hb Hc
• Modelo activo– Objeto
– Interacción entre objetos: Paso de mensajes
• Recepción mensajes Análisis estado interno, ejecución / retraso método
– Modelo objetos activo Modo natural de integrar concurrencia en los objetos
22
Modelo de objetos (y 2)• Modelo pasivo
Proximidad conceptual a los entornos tradicionales Familiaridad Gran cantidad de trabajos existentes Relativa eficiencia Falta de uniformidad y homogeneidad en la abstracción Coste derivado de la poca adecuación de las abstracciones Viola el principio de encapsulación Protección Problemas para la distribución y la persistencia
• Modelo activo Soporte a una abstracción única y homogénea Uniformidad en la interacción Facilita la sincronización Fácilmente distribuible y persistente Sobrecarga
23
Ámbito conceptual de la tesis: Solución a los problemas de caos e integración
Plataforma de soporte de objetos
Requisitos funcionales y no funcionales para el entorno de computación
Modelos de objetos para la computación
• Arquitectura del SOO: Requisitos, aproximaciones
• Propuesta de modelo de computación y estructura interna para el SOO
24
Requisitos para la arquitectura del SOO
Aplicar los principios de orientación a objetos– Estructura OO en tiempo de diseño: Sistema como un marco OO
– Estructura OO en tiempo de ejecución: Sistema como conjunto de objetos
– Interfaz OO
Arquitectura flexible: Adaptación a requerimientos de aplicaciones– Flexibilidad estática: Sistemas personalizables
– Flexibilidad dinámica: Sistemas adaptables y configurables
Entorno de computación
25
Arquitectura del SOO: Aproximaciones
• MicronúcleoSistema de
ficherosPlanificación
CPUPaginador
Micronúcleo
Incremento de la flexibilidadModularidadPortabilidad del hardware
Adaptabilidad de grano gruesoFlexibilidad limitadaMenor rendimiento
• OOReutilizaciónAdaptabilidad
Facilidad para evolucionarOptimización estructurada
• Reflectividad: Implantación abierta– Separar, en lugar de ocultar: Interfaz base versus meta interfaz
Flexibilidad Rendimiento
26
Ámbito conceptual de la tesis: Solución a los problemas de caos e integración
Plataforma de soporte de objetos
Requisitos funcionales y no funcionales para el entorno de computación
Modelos de objetos para la computación
Arquitectura del SOO: Requisitos, aproximaciones
• Propuesta de modelo de computación y estructura interna para el SOO
27
Propuesta de modelo y estructura para el SOO
• Propuesta para el SOO Modelo activo
• Máquina abstracta orientada a objetos
– Micronúcleo del SOO
• Sistema operativo OO: Modifica la máquina abstracta transparentemente– Extiende y complementa el comportamiento de la máquina abstracta
• Modelo de objetos para la concurrencia• Comunicación• Planificación
– Ofrece su funcionalidad sin romper el paradigma de OO
• MA + SO = Soporte flexible a objetos
• Objeto como agente de procesamiento serie
• Modelo de objetos único
• Comunicación: Síncrono y espera en caso necesario
• Excepciones
28
Contenidos de la presentación
Objetivos de la tesis Ámbito conceptual de la tesis: Soluciones a los problemas de caos e
integración
Colaboración de máquina abstracta y sistema operativo: Reflectividad
Máquina abstracta
Sistema operativo
Prototipo
Conclusiones
Líneas futuras de investigación
29
Reflectividad
• Capacidad de un programa de manipular, como si de datos se tratasen, la representación del propio estado del programa durante su ejecución
• Modelo del sistema– Abstracción adecuada del sistema
– Razonamiento y la manipulación– Conexión Causa-Efecto.
S: Sistema de ComputaciónM(S): Modelo de SS
M(S)
Conexión de Causalidad
30
Arquitectura reflectiva
• Sistema
• Actividades
básicas
• Nivel base o Nivel sistema
• Meta nivel
• Entidades base
• Computación base
• Meta entidades
• Meta computación
Torre
Reflectiva
• Exposición
• Reflexión• Introspección
• Intervención
A
B C
Meta sistemaM2
M1
M4M3
ReflejoExposición
Invocación de un método
Computación en el meta-nivel para gestionar acciones en el nivel base
Sistema base
Meta-entidades
Entidades base
31
Definición de una arquitectura reflectiva
• Ámbito– Estructural
– Del comportamiento
• Representación– Integración uniforme Modelo-Sistema
– Arquitectura reflectiva en SOO
• Flujo de control– Reflectividad implícita
– Reflectividad explícita
Objeto aplicación
meta-objeto
Meta-nivel para el objeto
aplicación
A
B CSistema Base
Meta Sistema
M2
M1
M4M3
Reflectividad Implícita
Invocación método
Meta-computación
Retorno del Control al
Nivel BaseReflectividad Explícita
32
Modelos de reflectividad• Modelo MetaClase
Clase MetaClase
Clase Objeto
Objeto
Instancia de
Instancia deHANDLEMSG
Paso de Control al Meta nivel
M
MethodsHANDLEMSG {...}
• Modelo MetaObjeto
Paso de Control al Meta nivel
HANDLEMSG
M
MetaObjeto
Objeto
Conexión Causal
Instancia de
Clase MetaObjeto
Clase Objeto
Instancia de
MethodsHANDLEMSG {...}
Sencillez Especialización. Cambio dinámico
Parcialmente meta Compatibilidad
Especialización Monitorización Modificación No se puede actuar sobre
el mensaje
Paso de Control al Meta nivel
M
SEND
Instancia de
Objeto
Clase Mensaje
Clase Objeto
Instancia de
MetaObjeto Mensaje(Selector, Argumentos,
Receptor)
• Exposición del paso de mensajes
Definir y usar distintas
clases de comunicación Carencia de continuidad
33
Organización reflectiva del SOO
• Sistema base y meta sistema en el SOO
• Meta-interfaz
• Flujo de control
34
Máquina abstracta: Nivel base
• Marco de definición de los objetos: Instancias de la clase Object
• Soporte en tiempo de ejecución: Entidades autónomas de procesamiento
• Entorno básico de computación
• Elevar objetos de la MAOO Codificar modelo de objetos como objetos
Objetos internos definidos en el lenguaje
de desarrollo Máquina abstracta
Objetos definidos en el ensamblador de la máquina abstracta
Objetos internos que soportan la representación de las instancias en tiempo de ejecución.
Objetos internos que soportan la comunicación entre objetos
Objetos que exponen características de la máquina abstracta.
Máquina abstracta
Objetos del usuario. Codifican la solución del problema
Objetos que soportan la comunicación entre objetos
35
• Modelo Meta-Objetos: División de grano fino del meta-nivel en objetos– Instancias de la clase METAOBJETO
– Diferencias objetos base - meta-objetos• Acceso a la información
• Ejecución de métodos
• Sistema operativo: ¡Objetos, objetos!– Conjunto de meta-objetos asociados con los objetos definidos en el nivel base
– Sobreescriben la especificación del metaobjeto por defecto definido por la MA
– Asociación dinámica Entorno flexible
• Descripción OO del meta-nivel: Integración homogénea de SO con el entorno
Sistema Operativo: Meta-Nivel
Objeto base
Meta-objetos: Objetos que extienden o modifican alguna funcionalidad de la máquina abstracta
Da soporte aDa soporte a
Conjunto de objetos del sistema operativo: Meta-espacio para el objeto base
Máquina abstracta
Máquina abstracta
Da soporte a
36
Meta-Interfaz• Estructural
– Instancia, Clase, Estructura interna de la máquina, estado de ejecución, …
• Del comportamiento– Cosificar elementos de la máquina que hacen que funcionen objetos del nivel
base mediante MetaObjetos
Objeto A Objeto B
Recepción Mensajes
Sincronización de la ejecuciónPlanificación
Recepción Mensajes
Envío Mensajes
DeMO Envío
DeMO Envío
DeMORecepciónDeMO
Recepción
DeMOPlanificación
DeMOPlanificación
DeMOSincronización
DeMOSincronización
37
Transferencia de control entre el nivel base y el meta-nivel
• Reflectividad implícita
• Reflectividad explícita: Transferencia de control uniforme– Invocación directa de métodos en objetos del meta-nivel a través de una
referencia al mismo• Modificar la definición de la instrucción primitiva de invocación a métodos.
• Eventos relacionados con la ejecución de métodos
• Planificación de tareas
• Invocación de métodos
38
Ventajas de una arquitectura reflectiva aplicada a un sistema OO
Mantenimiento de la uniformidad conceptual
Extensibilidad y adaptabilidad
Separación de asuntos o incumbencias (concerns)
Favorece el diseño de distintos modelos de objetos activo
Incremento de la productividad
Generalización para multiprocesadores y sistemas distribuidos
39
Contenidos de la Presentación
Objetivos de la tesis
Ámbito conceptual de la tesis: Soluciones a los problemas de caos e integración
Colaboración de máquina abstracta y sistema operativo: Reflectividad
Máquina abstracta
Sistema operativo
Prototipo
Conclusiones
Líneas futuras de investigación
40
Máquina abstracta orientada a objetos
• Arquitectura de referencia
• Soporte al objeto en la máquina abstracta
• Infraestructura proporcionada por la máquina abstracta
• Reflectividad estructural
41
Estructura de referencia de la máquina abstracta
Área de Instancias
Área de Clases Área de Referencias
Referencias del sistema
Clases
Instancias
Referencias
Jerarquía de Clases Básicas
thisroot_sched
current threadÁrea de Ejecución
Hilos de ejecución
42
Juego de instrucciones OO de alto nivel (1)
• Instrucciones declarativasclass NombreDeLaClase
isa {ClaseDeLaQueHeredaDirectamente}
aggregation
{NombreDelAgregado: ClaseDelAgregado}
association
{NombreDelAsociado: ClaseDelAsociado}
methods
{<NombreDelMétodo> ([{ClaseDeLosParámetros}]) [:ClaseDeRetorno];}
endclass
Identificación unívoca de la clase
Relaciones Jerárquicas: Identificador de la(s) clase(s) antecesoras directas en la jerarquíaRelaciones de Agregación: Referencia del objeto
que pertenece a la clase y clase del mismo.
Relaciones de Asociación: Referencia del objeto asociado y clase del mismo.
Definición de métodos: Nombre, referencias y tipos de los parámetros, referencias y tipo
de retorno
method <NombreDelMétodo> ([{NombreParámetro: ClaseParámetro}]) [:ClaseRetorno]
[refs {<NombreReferencia: ClaseReferencia>
[instances {<ReferenciaObjeto: Clase>};]
code
<Descripción del cuerpo del método>
endcode
endmethod
Referencias que se utilizan en el método y su tipo
Instancias que se utilizan y su tipo
43
Juego de instrucciones OO de alto nivel (y 2)
• Instrucciones del Comportamiento• Instrucciones para manipulación de objetos a través de las referencias
– new <ref>– assign <refdestino>, <reforigen>– delete <ref>
• Invocación de método a través de una referencia. – <ref>.{<ámbito>:}<método>({<ref>}) [:ref]– <ref>{<ámbito>:}<método>({<ref>}) [:ref]
• Control de flujo. – exit– JT/JF <refbool>, etiqueta– JNULL/JNNULL <ref>, etiqueta– JMP etiqueta– handler etiqueta / throw
44
Jerarquía de clases
• Clases primitivas
• Clases de usuario
Primitivas de Usuario
ClasesNo necesitan ser definidas entérminos de otras clases. Lamáquina les da soporte directo.
Se definen en términos de otrasclases (agregados y asociaciones),que les dan soporte.
MétodosSon implantados directamentepor la máquina. No necesitancuerpo.
Son implantados por instruccionesnormales de la máquina. Necesitanel cuerpo con estas instrucciones
Object
Array StreamFloatInteger
FilestreamConstream
Bool
String
Lock
MetaObject Instance ClassArea
45
Máquina abstracta orientada a objetos
Arquitectura de referencia
• Soporte al objeto en la máquina abstracta
• Infraestructura proporcionada por la máquina abstracta
• Reflectividad estructural
46
Representación del objeto en tiempo de ejecución (1)
Representación completa de los objetos en tiempo de ejecución: Objetos activos como modelo de unificación semántica
Reflectividad: Aumento del soporte al objeto por parte de la MA– Soporta la relación de causalidad– Exposición del motor de ejecución
Objeto
Área de Ejecución del objeto
Métodos en ejecuciónhilos
Métodos
Estado
Enlace Meta
Meta Espacio del objeto
Meta objetos
Semántica del objeto
47
Representación del objeto en tiempo de ejecución (y 2)
Contexto de ejecución de un método: Estructura del hilo
Importancia relación objeto-hilo • Distribución• Seguridad e integridad
Contexto dinámico del hilo
Capa o contexto de ejecución de la
pila
Hilo de Ejecución
Referencia Instancia
Estado
Instanciaa la que pertenece
el método en ejecución
Referencia al origen de la llamada
Contexto estático del hilo
MC
Referencia rr Referencia exc
Pila de ejecución
Referencias objetos locales
48
Máquina abstracta orientada a objetos
Arquitectura de referencia
Soporte al objeto en la máquina abstracta
• Infraestructura proporcionada por la máquina abstracta– Comunicación entre objetos
– Semántica del objeto ante la invocación concurrente de métodos
– Planificación de actividades
– Excepciones
• Reflectividad estructural
49
Paso de mensaje en la Máquina Abstracta
• Modelo síncrono: Call– Crea nuevo hilo en objeto destino
– Transmite control al destino para ejecutar método: símil del paso de testigo
– Retorno de resultados
• Modelo espera en caso necesario: Send– Crea nuevo hilo
– Divide flujo de control
– Retorno de resultados: Objetos virtuales transparentes
• Punto de inflexión para conseguir la reflectividad del comportamiento en el sistema.
50
Call de cerca• Caso base: Máquina abstracta actúa de meta-espacio básico
finalizando la recursión reflectiva– Invocación de métodos en objetos primitivos
– Reflectividad explícita
– Retorno del meta-nivel al nivel-base
Objeto O{Instrucción 1O’’:=call(O’, m, args) }
Objeto O’
method m{Instrucción 1Instrucción n }
Máquina Abstracta
call{Instrucción 1Instrucción n }
O’’:=O’.m(args)
Invocación de métodos
Ejecución instrucción call
Creación de un nuevo hilo virtual en O’ y
suspensión hilo origen
Ejecución efectiva del método
Transferencia de control al método m
Fin ejecución método: La máquina abstracta instancia el resultado en la referencia O’’ y
reanuda el método origen
51
Call de cerca• Caso Reflectivo: Transferencia de control al meta-nivel
– objeto origen y destino son objetos del nivel base: reflectividad implícita
Objeto Base O’
Objeto Base Omethod x {instrucción 1O’’:=call(O’, m, args) }
method m{instrucción 1instrucción n }
Máquina Abstracta
call{ call(metaobjeto, metamethod, args)}
Meta-objeto’
Meta-objeto
method metamethod{instrucción 1O’’:=call(O’, m, args) }
method m{instrucción 1instrucción n }
Meta-espacio
O’’:=O’.m(args)
Invocación de métodos: Punto de inflexión para la reflectividad
Instrucción Call de la máquina
Transición síncrona del nivel base al meta-nivel:
Suspende la ejecución del método x
Invocación de m (Caso básico de call):
Creación de un nuevo hilo virtual en O’ y transferencia del meta-nivel al nivel base
Ejecución efectiva del
método m
Retorno de resultados, reanudación método
origen
Ejecución de la instrucción Call
Meta-computación que complementa el soporte que la
MA da a la invocación de métodos
52
Objeto O’Objeto Base O
method m{Instrucción 1Instrucción n }
Máquina Abstracta
send{Instrucción 1Instrucción n }
{Instrucción 1O’’:=send(O’, m, args) call(O’’, método, args)}
Send de cerca• Caso Base: Máquina abstracta actúa de meta-espacio básico
– Método en un objeto primitivo
– Método de un meta objeto desde un objeto del nivel base: Reflectividad Explícita
– Método del nivel base desde el meta nivel: Transferencia control meta-nivel nivel base
O’’:=O’m(args)
Invocación métodoEjecución de la instrucción send
Ejecución de m
Intento acceso O’’: suspensión/acceso
Creación de un nuevo hilo virtual en O’ y suspensión del método origen durante el envío del mensaje. Informa al planificador de un nuevo hilo
para ejecutar el método m en O’.
Fin send: retorna el control al origen y ambos métodos se
ejecutan en paralelo
Fin m: máquina abstracta instancia O’’
53
{instrucción 1O’’:=send(O’, m, args) call(O’’, método, args) }
Objeto Base O
method m{instrucción 1instrucción n }
Máquina Abstracta
send{ call(metaobjeto, metamétodo, args)… }
method metamétodo{instrucción 1O’’:=send(O’, m, args) }
Meta-objeto’
method m{instrucción 1instrucción n}
Meta-espacio
Send de cerca• Caso Reflectivo: Transferencia de control al meta-nivel
– Ambos objetos son del nivel base reflectividad implícita
Objeto Base O’
O’’:=O’m(args)
Meta-objeto
Invocación de método: Punto de inflexión
Ejecución de la instrucción send de la
máquina
Transferencia síncrona de control
del nivel base al meta-nivel
Meta-computación
Invocación de m (Caso básico de send): Creación de un nuevo hilo
virtual en O’ y suspensión del método origen durante el envío
del mensaje. Informa al planificador de un nuevo hilo para
ejecutar el método m en O’.
Fin ejecución instrucción
send: máquina abstracta reanuda
método origen
Fin m: máquina abstracta
instancia O’’
Intento acceso O’’: suspensión/acceso
Suspensión del método origen durante el envío del mensaje, luego ambos métodos se ejecutan en
paralelo
54
Control de la concurrencia en la Máquina Abstracta
• Soporte al control de la concurrencia entre objetos
• Soporte de la MA al control de la concurrencia intra objetos– Define en la implantación de los objetos, una política de control por
omisión: objetos serie
• Flexibilidad: Exponer modelo de objetos para la concurrencia– Meta-objetos del SO asociados con objetos base sustituyen la definición por
omisión de la MA
paso de mensajes cerraduras
Objeto Activo
Objeto Base Meta Objeto
Relación de Control de Concurrencia
Estado Secuencial
Modelo Objetos
Concurrencia
55
Planificación
• Ciclo de ejecución de la MA– Ciclo indefinido: Ejecutar instrucción señalada por MC (Method Counter) de
la referencia del sistema ct (current thread) y actualizar el valor de MC
• Cambia el valor de la referencia del sistema ct
• MA sigue ciclo de ejecución con otro hilo.
– Hilo actual libera la MA• Finalización
• Suspensión.
– Requisamiento
56
Excepciones
• Instrucciones
• Lanzar una excepción: Error en tiempo de ejecución o throw– Instancia de excepción Asociarla con exc de la capa de contexto actual
• Instalación de un gestor para la excepción: handler– Gestor: contexto de ejecución en un hilo
– Indica la instrucción donde continuar la ejecución para gestionar la excepción
• Ejecución del gestor para gestionar la excepción producida– La ejecución del programa continuará en la dirección del último gestor
ejecutado
– El método actual define un gestor en su código
– El método actual no define un gestor en su código
• handler Etiqueta• throw
57
Máquina abstracta orientada a objetos
Arquitectura de referencia
Soporte al objeto en la máquina abstracta
Infraestructura proporcionada por la máquina abstracta Comunicación entre objetos Semántica del objeto ante la invocación concurrente de métodos Planificación de actividades Excepciones
• Reflectividad estructural
58
Reflectividad estructural en la máquina abstracta
Object
ThreadArea
Instance_Class
ClassArea
InstanceArea
Thread
ExecObjectAreaReferenceArea
Exposición de la Arquitectura de
la Máquina
Exposición de los elementos estructurales que representan a los objetos en tiempo de
ejecución
Exposición del motor
en tiempo
de ejecución
Máquina Abstracta
MetaObject
MetaSpace
Exposición del
meta-espacio
59
Contenidos de la presentación
Objetivos de la tesis
Ámbito conceptual de la tesis: Soluciones a los problemas de caos e integración
Colaboración de máquina abstracta y sistema operativo: Reflectividad
Máquina abstracta
Sistema operativo
Prototipo
Conclusiones
Líneas futuras de investigación
60
Diseño del sistema operativo orientado a objetos
SO = {objetos} Espacio de objetos del sistema
Reflectividad (Máquina, SO)
Barrera deProtección entre los
Objetos de laAplicación y los
Objetos del Sistema
Objetos deAplicación
Objetos del Sistema
Mensajes entre objetosde Aplicación y del
Sistema. Por definiciónexigen una seguridad
especial
• Comunicación
• Semántica del objeto
• Planificación
61
Reflectividad en la invocación de métodos
• Aspectos expuestos– Lado Servidor: búsqueda y ejecución del método correspondiente al mensaje
– Lado Cliente: envío de mensajes en el lado del cliente
Meta ObjetoEmisor 1
Objeto 1
Meta ObjetoReceptor 2
Objeto 2
Objeto Activo 1 Objeto Activo 2
Invocación método M Ejecución M
Mensaje
Respuesta
Call
Envío de Mensajesen el Meta Nivel
•Seleccionar servidor•Gestión errores•Soporte tiempo real•Depuración
•Recepción de mensajes •Análisis entorno•Selección método•Retraso ejecución•Delegación mensajes
62
Colaboración de emisor y receptor en la invocación síncrona de un método
O’’:=O’.m(args);
Objeto Base O’Objeto Base O
{instrucción 1O’’:=call(O’, m, args) }
method m{instrucción 1instrucción n }
Máquina Abstracta
call { // Caso Reflectivo call(MOEmisor, RCallE, args) // Caso Base call(O’, m, args) }
method RCallE{call(MO’Receptor, RCallR, args) }
Meta-objeto’ Receptor
method RCallR{ if overload() delegate() else { lookup(m) call(O’, m, args) }}
Meta-nivel
send { call(MOEmisor, RSendE, args) }
Ejecución de la instrucción call
Acciones antes de invocar el
métodoInvocación síncrona de RCallR,
suspensión de RCallEInvocación síncrona
del método m
Acciones después de recibir el resultado
Transferencia del nivel base al meta-nivel para ejecutar
el método RCallE
Análisis del mensaje y toma de
decisión
Retorno síncrono, reanudará el método origen, retornando el
resultado
Meta-objeto Emisor
Retorno síncrono, irá reanudando los métodos RCallR, RCallE y el origen, retornando el resultado
63
O’’:=O’m(args);
Meta-objeto Emisor
Objeto Base O’
Máquina Abstracta
send { // Caso Reflectivo call(MOEmisor, RSendE, args) // Caso Base .....call(Sched, NewMethod, newthread)}
method RSendE{call(MO’Receptor, RSendR, args) }
method RSendR{if overload() delegate()else { lookup(m) send(O’, m, args) }}
Meta-nivel
call { call(MOEmisor, RCallE, args) }
Meta-objeto Planificador
method NewMethod{Enqueue() }
Meta-objeto’ Receptor
Colaboración de Emisor y Receptor en la Invocación Asíncrona de un método
Ejecución síncrona de
RSendE
Invocación síncrona de RSendR, suspensión de RSendE
Ejecución de la instrucción send. Transferencia del
nivel base al meta-nivel Crea un nuevo hilo virtual en O’ y
ejecuta el método Enqueue del meta-objeto planificador. Retorna el
control al meta-espacio
Análisis de mensaje y toma de decisión
Objeto Base O{ instrucción 1O’’:=send(O’, m, args) }
method m{ instrucción 1instrucción n }
64
Ventajas de la reflectividad en la invocación de métodos
Soporte adaptado a distintos tipos de lenguajes
Personalización de la invocación para mayor eficiencia
Restricciones de tiempo
Facilita la creación de entornos distribuidos y persistentes al tratar todo ello en el meta-nivel
65
Diseño del sistema operativo orientado a objetos
SO = {objetos} Espacio de objetos del sistema
Reflectividad (Máquina, SO)
Barrera deProtección entre los
Objetos de laAplicación y los
Objetos del Sistema
Objetos deAplicación
Objetos del Sistema
Mensajes entre objetosde Aplicación y del
Sistema. Por definiciónexigen una seguridad
especial
Comunicación• Semántica del objeto• Planificación
66
Reflectividad en el modelo de concurrencia interna
• Requisitos de la solución– Encapsulación
– Extensibilidad
– Modularidad
– Reusabilidad
• Aspectos expuestos– Se expone la política de sincronización de grano grueso (Política Aceptación
Mensajes)
• Objetivos del meta-objeto sincronizador– Permite a las aplicaciones establecer distintos comportamientos para un
objeto base dependiendo del entorno de ejecución en el que se vaya a utilizar, sin tener que modificar el objeto base en sí.
67
Reflectividad en el modelo de concurrencia interna
• Ejecución meta-objeto Sincronizador– Explícito
• MetaObjeto Receptor invoca método ExecNewMethod (mensaje solicitado, origen del mensaje, otros parámetros)
– Implícito• Suspensión(StopMethod), Reanudación(ResumeMethod), Finalización de un
método(EndMethod)
• Colaboración del meta-objeto sincronizador en el meta-nivel
• Ventajas Separación de incumbencias Control más sencillo de la sincronización Problema de la herencia
68
Colaboración del meta-objeto Sincronizador en el meta-nivel
Meta-objeto datos de O’
Objeto Base O’
O’’:=O’.m(args);Objeto Base O
{ instrucción 1O’’:=call(O’, m, args) }
method m{ instrucción 1instrucción n }
call { // Caso Reflectivo // Caso Base }
send { // Caso Reflectivo // Caso Base }
Meta-objeto Sincronizador
method ExecNewMethod(O’, m, args){ Entrymethod(O’, m, args)OK { call(O’, m, args) }NO { DelayMethod(O’, m, args) } }
Métodos retrasados
Métodos suspendidos
Métodos en ejecución
Meta-espacio de O’
Meta-espacio de O’’
Máquina AbstractaConsulta de los metadatos de O’
Invocación de m: Transferencia del nivel
base al meta-nivel
Receptor invoca síncronamente
ExecNewMethod
Ejecución conveniente: Invocación efectiva de m
Ejecución no conveniente: Retrasar/Rechazar m y devolver
control a O
Ejecución de EntryMethod para comprobar la adecuación del método invocado
69
Reflectividad en el modelo de concurrencia interna
• Ejecución meta-objeto Sincronizador– Explícito
• MetaObjeto Receptor invoca método ExecNewMethod (mensaje solicitado, origen del mensaje, otros parámetros)
– Implícito• Suspensión(StopMethod), Reanudación(ResumeMethod), Finalización de un
método(EndMethod)
• Colaboración del meta-objeto sincronizador en el meta-nivel
• Ventajas Separación de incumbencias Control más sencillo de la sincronización Problema de la herencia
70
Diseño del sistema operativo orientado a objetos
SO = {objetos} Espacio de objetos del sistema
Reflectividad (Máquina, SO)
Barrera deProtección entre los
Objetos de laAplicación y los
Objetos del Sistema
Objetos deAplicación
Objetos del Sistema
Mensajes entre objetosde Aplicación y del
Sistema. Por definiciónexigen una seguridad
especial
Comunicación Semántica del objeto
• Planificación
71
Reflectividad en la planificación
• Aspectos expuestos: Política de planificación– Necesidades específicas de objetos o grupos de objetos
• Meta-objetos para la planificación: Meta-Objeto Planificador
• Jerarquía de clases de planificación en tiempo de definición: Reutilización del código– Adición de nuevos planificadores: Ampliación de la jerarquía
– Anatomía de un objeto planificador• Estado: Lista de referencias a planificar
• Métodos: ScheduleNext, Enqueue, IsEmpty
– Jerarquía inicialSchedulerUSS
QueueScheduler TimeScheduler
FIFO Priority SRTN....... .......
72
Jerarquía de planificadores en tiempo de ejecución
• Planificación de objetos: Meta-objeto Planificador
• Planificación de meta-objetos: Jerarquía de objetos planificadores– La raíz de la jerarquía: El planificador de la máquina
• Transferencia de control entre los planificadores– Mecanismo de paso de mensajes síncronos y retorno de los mismos
PlanificadorRaíz
Máquina Abstracta
Planificador A
Planificador C
Planificador B
Objeto X
Objeto Y
Tiempo
Tiempo
Tiempo
Reparte
73
Visión dinámica del sistema
Nivel Base
ObjetoBase
Destino
ObjetoBase
Origen
Meta Nivel
Meta-ObjetoSincronizador
DestinoMeta-ObjetoPlanificador
Destino
Meta-ObjetoEmisorOrigen
Meta-ObjetoReceptorDestino
1: MOEmisor.RCallE(...);
2: MO’Receptor.RCallR(...);
3: MO’Sin.ExecNewMethod(...);
4: MO’Sched.Enqueue(...);
Destino.m(...);
6: ct=Ejecutar método destino
0: MS=this.GetMetaSpace(); MOEmisor=MS.GetMObyClass(“Emisor”); MOReceptor=MS.GetMObyClass(“Receptor”); MOSinc=MS.GetMObyClass(“Synch”); MOSched=MS.GetMObyClass(“Sched”);
0: MS’=destino.GetMetaSpace(); MO’Emisor=MS’.GetMObyClass(“Emisor”); MO’Receptor=MS’.GetMObyClass(“Receptor”); MO’Sinc=MS’.GetMObyClass(“Synch”); MO’Sched=MS’.GetMObyClass(“Sched”);
5: MO’.ScheduleNext(...);
74
Contenidos de la presentación
Objetivos de la tesis
Ámbito conceptual de la tesis: soluciones a los problemas de caos e integración
Colaboración de máquina abstracta y sistema operativo: reflectividad
Máquina abstracta
Sistema operativo
Prototipo
Conclusiones
Líneas futuras de investigación
75
Prototipo del SOO
• Principios aplicados en el prototipo Aplicación intensiva de los principios de la OO en el diseño y construcción
del prototipo Simplicidad
• Diseño del SOO como conjunto de objetos: Uniformidad– La aplicación intensiva de los principios de la OO en el diseño e
implantación del SOO hace que los elementos que componen el entorno se representan mediante objetos, instancia de las clases que los describen.
• Presentación del SOO Diagrama de clases general de la MA Jerarquías del prototipo para la MA Reflectividad estructural Jerarquía de objetos del sistema operativo
76
Diagrama de clases general
TInstanceArea
TThreadTStackElement
TExecArea
TClassArea
TClass
TInstance
TRef
TMethodA
A
Referenciaslocales
Ancestros
Ejecuta1
A
Pertenece
Instanciaslocales
this
Raiz 1Subinstancia1..n
Apunta a0..1
Agregados Asociados
TInstructionA
TThreadAreaA Clase abstracta
Tiene
Usa
muchos (cardinalidadmúltiple genérica)
THandler
TContext
TIMetaSpace
TIMetaObject
77
Jerarquía de clases del prototipo
• Para describir la implantación del SOO describir la jerarquía de clases del prototipo y las relaciones entre ellas.– Clases, Instancias, Métodos, Instrucciones
• Herencia y el polimorfismo facilitan reutilizar el código y construir variantes del prototipo con pequeñas modificaciones en el código.
TInstance
TIArray
TIStringTIFloatTIIntegerTIObjectTIMetaObject
TIFilestreamTIConstreamTIBoolTIStreamTISemaphore
TUserInstance
78
Jerarquía de clases para la reflectividad estructural
TClass
TCThreadArea TCInstance
TCMethodTC_Class
TClassArea
TCInstanceArea
TCContext
TCThreadTCExecObjectAreaTCReferenceArea
TCInstruction
Exposición de la Arquitectura de la
Máquina
Exposición de los elementos estructurales que representan
los objetos en tiempo de ejecución
Exposición del motor en tiempo de ejecución
Máquina Abstracta
79
Objetos internos, clases primitivas e instancias
Object Thread
Object _Class
ObjectClassArea
ObjectInstanceArea
ObjectReferenceArea
ObjectThread Area
Object Instance
Área de Clases
Área de ReferenciasÁrea de Threads
OI_Thread
OI_Class
OI_ClassArea
OI_InstanceArea
OI_ReferenceArea
OI_Thread Area
OI_Instance
Class Thread
Class_Class
ClassClassArea
ClassInstanceArea
ClassReferenceArea
ClassThread Area
ClassInstance
Cualquier Objeto
Cualquier Clase (primitiva o de
usuario)
Representación interna deInstancia deExpone a
Objetos internos de la Máquina
Abstracta
Clases Primitivas que representan aspectos internos de la Máquina Abstracta
Área de Instancias
Objetos accesibles normalmente por el usuario que exponen características internas de la Máquina Abstracta
Máquina Abstracta
80
Sistema operativo: Jerarquía de clases para la reflectividad del comportamiento
• El prototipo del Sistema Operativo consiste en una jerarquía de clases Emisor, Receptor, Planificador y Sincronizador que representan la funcionalidad del sistema operativo
TClass
TCMOEmisor
TCMetaObjectTCMetaSpace
TCMOSynchronizerTCMOReceptorTCMOScheduler
81
Contenidos de la presentación
Objetivos de la tesis
Ámbito conceptual de la tesis: soluciones a los problemas de caos e integración
Colaboración de máquina abstracta y sistema operativo: Reflectividad
Máquina abstracta
Sistema operativo
Prototipo
Conclusiones
Líneas futuras de investigación
82
Conclusiones y resultados (1)
• SOO. Soporte global a objetos– Soporte integral a objetos
– Uniformidad
– Solución global a los problemas de objetos presentados
• Ventajas de usar MAOO como base del SOO– Portabilidad
– Facilidad de comprensión
– Facilidad de desarrollo y de experimentación
– Compiladores de lenguajes
• Ventajas de extender la MAOO mediante un SOO– Economía de conceptos y uniformidad
– Extensión uniforme con el resto del sistema
83
Conclusiones y resultados (y 2)
• Modelo objetos Activo: Uniformidad total– Modelo de objetos activo transforma el objeto en una herramienta de computación autónoma
– Soporte más sofisticado a la abstracción de objeto
– Uniformidad y homogeneidad total en el sistema
– Simplicidad y economía de conceptos
• Integración de MAOO y SOOO por medio de la reflectividad– MA: Base de la torre reflectiva
• Limita la sobrecarga de la reflectividad• Semántica básica• Facilita la experimentación.
– SO: Meta-nivel• Flexibilidad estática: Sistema Personalizable • Flexibilidad dinámica: Sistema adaptable y configurable
84
Contenidos de la presentación
Objetivos de la tesis
Ámbito conceptual de la tesis: Soluciones a los problemas de caos e integración
Colaboración de máquina abstracta y sistema operativo: Reflectividad
Máquina abstracta
Sistema operativo
Prototipo
Conclusiones
Líneas futuras de investigación
85
Líneas futuras de trabajo (1)
Construcción de una jerarquía del SO más completa– Ampliar jerarquía clases SO
– Resto de la jerarquía de clases que definiría un sistema operativo completo
MAOO reflectiva guiada por eventos
– Modificar la MAOO integrando en ella un modelo de eventos basado en emisores y receptores de eventos
– Modificar el modelo reflectivo de la máquina• Reflejar un aspecto Suscribirse a determinado evento de la máquina
• Evento Paso de control al meta nivel y ejecución de un determinado método de un meta-objeto del sistema operativo
86
Líneas futuras de trabajo (y 2)
Integrar otros aspectos en la arquitectura reflectiva propuesta– Distribución
– Persistencia
– Agrupación de objetos
– Seguridad
Implantación eficiente del prototipo Dicotomía call/send
87
Modelo de Computación Concurrente para un Sistema Operativo Orientado a Objetos
basado en una Máquina Abstracta
Lourdes Tajes Martínez
Dirigida por Juan Manuel Cueva Lovelle
Oviedo, 16 de Marzo de 2000
TESIS DOCTORAL