Estado y flujo de control

 

Siempre pensamos en un thread como una entidad que posee los siguientes elementos:

• Un estado que esencialmente consiste en (ver figura 3.8)
  • Un contexto de ejecución que incluye el conjunto de valores para los registros, considerando también el contador de programa y la pila empleada
  • La capacidad de planificar dicho contexto o de iniciar y detener la ejecución de dicho contexto en un procesador.
  En la figura, el ``estado'' del thread correspondería a la pila y juego de registros empleados en un instante determinado.
• Un flujo de control que corresponde con una serie de registros de activación en una (o varias) pila(s) y una sucesión de valores para el contador de programa. En la figura, el flujo de control está formado por la sucesión de instrucciones ejecutadas y llamadas a procedimiento realizadas que representamos con líneas discontinuas.

  
Figure 3.8: Threads: estado y flujo de control.

Sistemas como Spring han separado el concepto de estado del thread del de flujo de control (ver figura 3.9):

• Por un lado, Spring emplea una abstracción denominada Shuttle que representa el estado de la ejecución de un thread y es una entidad planificable (el planificador de Spring multiplexa los procesadores entre los Shuttles existentes). Podemos pensar en los shuttles como en ``procesadores virtuales'' que empleamos para ejecutar los flujos de control de las aplicaciones.
• Por otro lado, Spring incluye otra abstracción denominada thread para representar el flujo de control que involucra un conjunto de registros de activación correspondiente a la secuencia de llamadas a procedimiento efectuados. Este flujo de control es lo que los usuarios del sistema perciben como un thread, de ahí el nombre.

Nosotros hemos empleado la terminología de Spring por considerarla más clara, aunque otros sistemas que emplean nombres distintos para estas abstracciones (notablemente, una implementación de threads móviles para Mach [73] denomina thread al equivalente a un Shuttle en Spring y activación al equivalente a un thread en Spring).

En Off, los shuttles se conciben como contextos de procesador extensibles. Un shuttle en Off no es otra cosa que el estado necesario para ejecutar un thread. A diferencia de lo que sucede en Spring, los shuttles de Off pueden extenderse dinámicamente para incluir nuevos elementos en el ``estado de ejecución'' (hablaremos de esto en el apartado 3.3.2). El kernel se limita pues a crear, destruir y planificar shuttles. Como vemos en la figura 3.9, el procesador se multiplexa entre un conjunto de Shuttles que se emplean como abstracción básica para ejecutar threads.

  
Figure 3.9: Flujos de control (threads) y estados (shuttles)

La distinción entre shuttles y threads permite que el sistema opere con contextos de procesador (Shuttles) a nivel de planificación y gestión de procesos y, por otro lado, los usuarios perciban una abstracción distinta correspondiente a un flujo de control (thread).

Lamentablemente, a pesar de la introducción de shuttles en Spring, los threads de Spring están dentro del núcleo y son de hecho la única abstracción exportada a los usuarios (los shuttles son una abstracción interna del núcleo que no es manipulable directamente por los usuarios del sistema). Los shuttles de Off, al contrario, dejan abierta la posibilidad de emplear otras abstracciones a nivel de usuario. El kernel no los oculta en absoluto.

Como consecuencia de la ocultación, la planificación de los procesadores y otros aspectos relacionados con la implementación de los Shuttles en Spring están completamente determinados por el kernel. En cambio Off deja estas tareas en la medida de lo posible en manos de las aplicaciones.