Transferencias protegidas de control

  Podría parecer que el mecanismo básico de envío de mensajes que mencionamos anteriormente debería bastar para soportar cualquier modelo de IPC. No obstante, la realidad es que es conveniente soportar transferencias protegidas de control dado que esto supone un ahorro (principalmente en latencia) para las aplicaciones. Intuitivamente, tenemos las mismas razones que tienen los arquitectos de procesadores para suministrar ``gates'': dar un mecanismo barato para que una aplicación pueda ejecutar una rutina en otro dominio de protección.

En este caso el usuario del sistema que envía el mensaje quedará bloqueado hasta que el manejador asociado al portal complete su ejecución tras la recepción del mismo. Dicho de otro modo, el shuttle del cliente se emplea para ejecutar el manejador en el servidor.

Para que un portal soporte PCTs es preciso que el servidor del portal (esto es, la aplicación donde se encuentra el manejador del portal) o el usuario que lo creó disponga de un conjunto de pilas donde puedan ejecutar las distintas invocaciones que pueda sufrir dicho portal. Nótese que las pilas deben estar en el dominio de protección del servidor, aunque las emplee el shuttle que realiza la invocación durante el transcurso de la llamada.

Para ello la información presente en el portal contiene:

• una dirección de memoria válida como base de una pila y
• una máscara de propiedades en que al menos debe incluirse el nuevo espacio de direcciones (la nueva de DTLB).

Si esta información no está presente el portal no se puede emplear para PCTs.

En cada invocación, dicha dirección se actualizará automáticamente en base a valores presentes en la base de la pila anterior. De este modo, las pilas disponibles están enlazadas y sucesivas invocaciones las van agotando una tras otra. El manejador del portal puede restaurarlas a voluntad puesto que los enlaces están mantenidos en su mismo espacio de direcciones.

La implementación de las PCTs se basa en que es factible alterar el contexto de usuario, salvado en la entrada al núcleo durante una llamada al sistema, para que el retorno se produzca en un dominio diferente.

El algoritmo empleado para efectuar una PCT es como sigue:

1. Se realiza la llamada al sistema sys_portal_send. Ésta es, naturalmente, en modo bloqueante y supondremos que el portal está en el nodo local. Si el portal fuese remoto se produciría una excepción (enviada mediante un upcall) que el usuario debería tratar. Habitualmente la llamada degenerará en el uso del mecanismo de envío de mensajes detallado anteriormente.
2. Se prepara la pila de ejecución (del manejador, en espacio de usuario) y se instala en ella un registro de activación para el manejador, incluyendo éste el mensaje en curso. Si no hubiese pila disponible la llamada se aborta.
3. Se modifican las propiedades del shuttle de acuerdo con la máscara de propiedades presente en el portal y se altera el estado del shuttle para que tras retornar de la llamada al sistema se ejecute el manejador.
4. Se modifica el contexto de usuario del shuttle de tal modo que ejecute el manejador en la pila seleccionada previamente. El contexto anterior a la modificación se salvaguarda en la pila de kernel del shuttle considerado.
5. Se retorna de la llamada al sistema en curso de tal modo que ejecute el manejador cuya instalación se ha preparado.
6. Un trampolín instalado en el punto anterior, que ejecuta cuando el manejador retorna devolverá el control al kernel. En este punto se restaura el estado (y las propiedades alteradas por la invocación del portal) salvado anteriormente. El procedimiento es el mismo que se emplea en la llamada, salvo que ahora, en lugar de crear un estado nuevo según la información presente en el portal se restaura el estado salvado anteriormente.

Cuando la modificación de propiedades del shuttle (ej.: espacio de direcciones) supone emplear recursos remotos la ejecución del manejador supondrá envío de excepciones (mediante upcalls) por parte del kernel. Dichas excepciones se tratan como en cualquier otro caso, dando lugar a la transferencia de recursos (DTLBs, etc.) de un nodo a otro.

Aunque la implementación actual no lo tolera, el diseño permite que el manejador de dichas excepciones aborte la PCT e inicie otra acción equivalente (transferir el shuttle al nodo donde están los recursos, emplear envío de mensajes asíncronos para simular la PCT entre varios nodos, etc.). La elección de la solución adecuada depende de la aplicación considerada y de la cantidad de información a transferir por la red, por lo que (de nuevo) dejamos en manos de la aplicación esta tarea.