Presentada por Lourdes Tajes Martínez Dirigida por Dr. D. Juan Manuel Cueva Lovelle

1

Modelo de Computación Concurrente para un Sistema Operativo Orientado a Objetos

basado en una Máquina Abstracta

Presentada por Lourdes Tajes MartínezDirigida 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


• 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



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



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

CAP

CIÓN

SULA

Superclase

Subclase

method x1method x2method ...

SIN

CR

ON

IZA

CIÓ

N

method y1method y2method ...

SIN

CR

ON

IZA

CIÓ

N

¿SIN

CR

ON

IZA

CIÓ

N?

8



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



9



Ámbito conceptual de la tesis: Soluciones a los problemas de caos e integración


Máquina abstracta

Sistema operativo

Prototipo

Conclusiones


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


Plataforma de soporte de objetos

• Requisitos funcionales y no funcionales para el entorno de computación




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


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



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



b::metodo(args):res{ ....


Desbloqueoreturn(res);}

Complica el modelo de excepciones

17



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






Entrada al objeto: selecciona un método

Retorno

ObjetoLlamadas 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

ObjetoLlamadas 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



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






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



Requisitos funcionales y no funcionales para el entorno de computación




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 BHb 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




Modelos de objetos para la computación



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úcleo

Sistema deficheros

PlanificaciónCPU

Paginador

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




Modelos de objetos para la computación

Arquitectura del SOO: Requisitos, aproximaciones


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


Objetivos de la tesis Ámbito conceptual de la tesis: Soluciones a los problemas de caos e

integración


Máquina abstracta

Sistema operativo

Prototipo

Conclusiones


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

Reflejo Exposició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 SistemaM2

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


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


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

DeMORecepción

DeMOPlanificació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




Máquina abstracta

Sistema operativo

Prototipo

Conclusiones


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

this root_sched

current threadÁrea de Ejecución

Hilos de ejecución

42

Juego de instrucciones OO de alto nivel (1)• Instrucciones declarativas

class NombreDeLaClaseisa {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>endcodeendmethod

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


Arquitectura de referencia

• Soporte al objeto en la máquina abstracta

• Infraestructura proporcionada por la máquina abstracta


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



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


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) }


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


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 origenFin 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



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


58

Reflectividad estructural en la máquina abstractaObject

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





Máquina abstracta

Sistema operativo

Prototipo

Conclusiones


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) }


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






Objetos del Sistema


Objetos del Sistema



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


• 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


• 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






Objetos del Sistema


Objetos del Sistema



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



Á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


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 1 Subinstancia1..n

Apunta a0..1

Agregados Asociados

TInstructionA

TThreadAreaA Clase abstracta

TieneUsa

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 estructuralTClass

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



Ámbito conceptual de la tesis: soluciones a los problemas de caos e integración


Máquina abstracta

Sistema operativo

Prototipo

Conclusiones


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





Máquina abstracta

Sistema operativo

Prototipo

Conclusiones


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ínezDirigida por Juan Manuel Cueva Lovelle

Oviedo, 16 de Marzo de 2000

TESIS DOCTORAL

Documents

Presentada por Lourdes Tajes Martínez Dirigida por Dr. D. Juan Manuel Cueva Lovelle