Los sistemas distribuidos suelen emplear tanto hilos como llamadas a procedimientos remotos (Remote Procedures Calls - RPC). Ya que los hilos se idearon como una alternativa menos costosa a los procesos estándar (procesos pesados), los investigadores han analizado las RPC en este contexto, para tratar de aligerar también su funcionamiento. Existen distintos estudios a este respecto, entre los que se pueden destacar los que se presentan a continuación.
Bershad y otros [BER90] observaron que incluso en un sistema distribuido, un gran número de RPC se realiza con procesos donde un misma máquina es la que realiza las llamadas (por ejemplo, al gestor de ventanas). Es decir un gran número de RPC son locales. Este resultado depende del sistema, pero es bastante habitual y por eso lo tuvieron en cuenta. Propusieron un nuevo esquema que permitía la llamada de un hilo de un proceso a otro hilo de otro proceso dentro de la misma máquina de forma más eficiente a la habitual :
- Cuando se inicia un hilo servidor, S, informa de su interfaz al núcleo y la exporta. Esta interfaz define los procedimientos a los que se puede llamar, sus parámetros, etc.
- Cuando se inicia un hilo cliente, C, importa la interfaz del núcleo y obtiene un identificador especial que emplea en la llamada.
- El núcleo sabe ahora que C llamará posteriormente a S, y crea una serie de estructuras de datos especiales para gestionar la llamada. Una de estas estructuras de datos es una pila de argumentos compartida por el cliente C y el servidor S, que se asocia como lectura/escritura en ambos espacios de direcciones. Para llamar al servidor S, el cliente C coloca los argumentos en la pila compartida, mediante el procedimiento normal de transferencia, y después hace una indicación al núcleo, al colocar el identificador especial en un registro. El núcleo reconoce el identificador y sabe que la llamada es local. Si hubiese sido remota la gestionaría normalmente, sin embargo al ser local la gestión cambia. El kernel modifica el mapa de memoria del cliente C para colocarle en el espacio de direcciones del servidor e inicia el hilo cliente, ejecutando el procedimiento del servidor. La llamada se realiza de forma que los argumentos ya se encuentran en su lugar, con lo cual no es necesario el copiado o la ordenación de los mismos. Como resultado se obtiene una RPC local que se realiza de una forma más rápida que por el procedimiento normal.
En esta solución se tiene en cuenta que cuando un hilo servidor se bloquea esperando una nueva solicitud, no suele mantener ninguna información de interés que se necesita tras despertar, no suele emplear variables globales y el contenido de los registros no suele interesar. Así pues no hay razón para que el hilo no muera al terminar de servir la solicitud. Cuando llega una nueva solicitud, el núcleo crea en ese momento un nuevo hilo que da servicio a la solicitud, asocia la solicitud con el espacio de direcciones del servidor y configura la pila del nuevo hilo para poder acceder al mensaje de la solicitud. Esto es lo que se llama esquema de recepción implícita, y el hilo que se crea de forma espontánea para manejar la RPC recibida se suele conocer como hilo de aparición instantánea o pop-up thread. Existen varias ventajas de este método frente al de la RPC convencional :
- Los hilos no se bloquean a la espera de nuevas solicitudes de trabajo, con lo que no se guarda información relativa al contexto.
- La creación de un nuevo hilo resulta más económica que la restauración de uno existente, ya que no hay que restaurar el contexto.
- Se gana tiempo, al no tener que copiar las solicitudes a un buffer en el espacio de direcciones de un hilo servidor.
En resumen, se logra una mejora substancial en la
velocidad.