Aunque las abstracciones más empleadas en gestión de procesos son las tareas (o procesos) y los threads, existen en realidad multitud de abstracciones empleadas con mayor o menor éxito en los SSOO actuales para el mismo fin. En cualquier caso, todas ellas siguen girando alrededor de los conceptos de tarea o proceso (en adelante utilizaremos sólo tarea, aunque puede leerse también ``proceso'') y de thread:
Como hemos dicho anteriormente, uno de los problemas que presentan dichas abstracciones es su falta de adaptabilidad. Cada vez que una aplicación necesita algo diferente estas abstracciones deben reimplementarse y es necesario efectuar cambios importantes en el núcleo del SO. Esto ha ocurrido con los threads móviles en Mach [73] y con muchos otros servicios añadidos a la gestión de procesos de SSOO contemporáneos. En muchos casos ha sido necesario implementar un SO completamente nuevo debido a la incapacidad de soportar nuevas habilidades de las abstracciones existentes, como ocurrió con GrassHopper [50]. Por último, esta falta de adaptabilidad y la complejidad que requiere la implementación de tareas y threads dentro de un kernel conducen a ineficiencias y faltas de fiabilidad como se indicó en los capítulos anteriores.
Cuando el sistema implementa múltiples threads dentro de las tareas, la implementación se hace pesada y compleja. Se introducen con toda seguridad más errores en el sistema (puesto que el número de errores es proporcional a la complejidad y tamaño del código), perjudicando a aquellas aplicaciones que no utilizan los servicios añadidos (a las que sólo usan un thread, a las que sólo usan un dominio de protección, a las que emplearían un esquema de planificación estático de estar éste disponible, etc).
Por otro lado el sistema debe optar bien por planificar de forma simétrica los threads, bien por realizar una doble planificación (primero tareas y luego threads), bien por un esquema mixto. Sea cual sea el modelo empleado se aplicará a todas las aplicaciones incluso si la planificación resultante es peor.
Consideremos ahora la distribución y la migración de procesos en sistemas tradicionales. Cuando las tareas contienen a los threads no es factible migrar un thread aislado sin migrar también a la tarea que lo contiene (por no mencionar que habitualmente tanto tareas como threads son incapaces de abandonar el nodo en que se crearon). Esto incluye todos los recursos de la tarea, dado que los threads tienen noción sólo de la tarea que los contiene y no de los recursos que necesitan.
Esto es una consecuencia de la vinculación estrecha de los recursos a las tareas, que fuerza la compartición de recursos dentro de la misma tarea. ¿Acaso no tiene utilidad la posibilidad de tener distintos threads con distintos identificadores de usuario ejecutando dentro de un servidor, cada uno de ellos sirviendo a un usuario distinto y, aun así, compartiendo ciertos recursos del servidor? ¿No tiene utilidad que distintos threads dentro de la misma tarea mantengan diversos derechos de acceso, niveles de privilegio, protecciones de memoria, tablas de ficheros abiertos, etc.? La lista de aplicaciones es casi ilimitada.
Para solventar los mencionados problemas, tres han sido las contribuciones más relevantes en cuanto a abstracciones dedicadas a gestión de procesos en los últimos tiempos:
'' [73, 84]. Dicho
de otro modo, la distinción entre estado (los recursos necesarios
para la ejecución del thread y el contexto del mismo) y flujo de
control. Hablaremos de esto en el apartado 3.3.1.
Lo que nosotros proponemos como alternativa es el uso de una única abstracción consistente en un contexto de procesador básico que puede extenderse bajo demanda para incluir nuevos elementos. No obstante, cualquier abstracción cercana al hardware (al contexto del procesador en este caso) que pueda emplearse en un conjunto de nodos distribuidos en una red puede considerarse también como candidata para el sistema de gestión de procesos de un DAMN.