Revocación de recursos

  

La revocación de recursos es más compleja que la asignación dado que habitualmente acarrea agravios para las aplicaciones cuyos recursos se revocan.

En sistemas convencionales es el SO el que decide de forma inapelable qué recursos y a quién deben revocarse. En la mayoría de los casos las aplicaciones ni siquiera pueden percatarse de la revocación y toman sus decisiones ignorantes de este hecho. La ignorancia de las aplicaciones ante la revocación es una causa de problemas derivados de falsas suposiciones sobre la misma.

Consiguientemente, en Off hemos optado por el uso de revocación explícita, en la que el kernel permite que las aplicaciones conozcan cuando y qué recursos se les van a revocar. Hay también algunos SO adaptables que se comportan de este modo, aunque otros no permiten a las aplicaciones tener conocimiento de revocaciones. Sólo unos pocos SO adaptables permiten a las aplicaciones participar en la decisión de revocación.

Las preguntas que hay que contestar para diseñar un mecanismo de revocación de recursos son (ver tabla 2.1):

 

¿Cuando? ¿Quién? ¿Ámbito? ¿Cómo?

SO monolítico siempre kernel sistema implícita

siempre sistema implícita

exokernel en demanda kernel+aplicación aplicación explícita

DAMN en demanda aplicación aplicación explícita

 

• ¿Cuándo se revocan los recursos?
  Habitualmente es el SO el que decide el momento apropiado en que se han de revocar recursos. El mecanismo empleado suele ser el uso de umbrales de revocación, de tal modo que si la cantidad usada de un tipo de recurso sobrepasa un umbral determinado el sistema revoca unidades de dicho recurso para aumentar su disponibilidad.

  No obstante, en sistemas monolíticos y kernels no adaptables la situación suele ser aún más dictatorial ya que en ciertas ocasiones el sistema reclama recursos incluso cuando no es necesario hacerlo.

  En Off el kernel dispara un suceso de revocación cuando hay peticiones de asignación que no pueden satisfacerse, esto es, cuando no hay más unidades libres del recurso que consideremos. En aquellos casos en que desee mantenerse un porcentaje libre de un tipo de recurso dado deberían ser las propias aplicaciones las que iniciasen la revocación.

• ¿Quién decide qué recursos hay que revocar?
  El ejecutor del algoritmo de revocación suele ser también el SO. En SSOO monolíticos y en aquellos que utilizan kernels no adaptables la implementación está centralizada en el núcleo del sistema.

  En kernels adaptables, exokernels y DAMNs las aplicaciones suelen participar en la elección de recursos a revocar. En Off el kernel sólo dispara un suceso de revocación como vimos en el punto anterior. La decisión está distribuida por completo entre las aplicaciones involucradas, como veremos al final de este apartado.

• ¿Qué ámbito tienen los recursos que se revocan?
  

  Tradicionalmente el SO revoca los recursos que él controla. En SSOO distribuidos basados en kernel éste revoca recursos restringidos a un nodo, con independencia de la aplicación que los utiliza. Esta revocación puede ser adecuada en relación a la disponibilidad de recursos locales aunque, en muchas ocasiones, puede no ser la óptima considerando todos los nodos involucrados.

  En exokernels los recursos se revocan también localmente, dentro del nodo considerado. En este caso las aplicaciones pueden decidir qué unidades liberar del recurso revocado.

  En DAMNs el kernel no revoca recursos, tan sólo dispara sucesos de revocación. Las aplicaciones deberán recurrir a algún mecanismo de arbitraje que permita seleccionar los recursos a revocar. En este caso es posible que dicho arbitraje actúe de forma diferente en función de las circunstancias, operando localmente en unos casos y globalmente en otros.

Considerando ahora el caso de un DAMN, la revocación se basa en los siguientes puntos:

• El kernel no fuerza la revocación, sólo notifica la necesidad de revocar recursos para satisfacer peticiones de asignación.
• El sistema de protección empleado debe permitir a un árbitro forzar dicha revocación en caso necesario.
• Debe permitirse la existencia de múltiples árbitros de tal modo que cada conjunto de aplicaciones puede emplear un mecanismo diferente de arbitraje.

Como puede verse, Off sólo dispara un evento de revocación para un recurso determinado cuando alguna petición de asignación no puede satisfacerse. El kernel ha concluido con eso su trabajo.

En el caso de aplicaciones que compiten por un recurso será el árbitro el que establezca un reparto adecuado del mismo entre ellas. En general, la revocación de los recursos en un nodo podría proceder como sigue:

1. En un momento dado un porcentaje de los recursos locales podrían ofrecerse al resto de la red. Así un servidor compartido ofrecería el 100%, una estación de trabajo podría ofrecer el 100% cuando el propietario no la está utilizando y bajar a un 30% o un 60% cuando el propietario la use.
2. Un árbitro por nodo puede mantener dichos porcentajes.
3. Mientras estos porcentajes estén satisfechos los árbitros pueden revocar los recursos en función de otros criterios mas tradicionales (conjunto de trabajo, uso reciente, etc.)
4. Una vez elegida una aplicación por un árbitro, esta puede intentar convencer a otras para que liberen recursos en su lugar.
5. La aplicación resultante puede escoger las unidades que menos necesita.

Si las aplicaciones funcionan correctamente este sistema no causa problemas. Si las aplicaciones se comportan con malicia o error la responsabilidad de revocar los recursos cae ahora en el árbitro. Este árbitro puede incorporar un esquema de liberación mixto similar al empleado en Aegis:

• Primero se pide con revocación explícita la liberación de recursos a una aplicación.
• Si pasado cierto tiempo no aumenta la disponibilidad en dicho recurso, se procede a una revocación implícita.