Sistemas operativos modernos

Si la llamada pasa todas las pruebas, su éxito está asegurado. En ese momento ya pueden ob­ tenerse los recursos. Si se intercalan las pruebas con la obtención de recursos y alguna de ellas falla, será nece­ sario regresar todos los recursos obtenidos hasta ese punto. Si se comete algún error aquí y no se regresa algún recurso, el daño no será inmediato. Por ejemplo, una entrada de la tabla de procesos podría quedar inutilizada en forma permanente. Sin embargo, al paso del tiempo es­ te error podría presentarse en repetidas ocasiones. Tarde o temprano, todas las entradas de la tabla de procesos, o casi todas, podrían quedar inutilizadas, causando una falla del sistema en extremo impredecible y difícil de depurar. Muchos sistemas padecen este problema en forma de fugas de memoria. Por lo regular, el programa invoca a malloc para asignar espacio pero después se olvida de invocar a free para li­ berarlo. Poco a poco va desapareciendo la memoria hasta que el sistema se reinicia. Engler et al. (2000) han propuesto una forma interesante de verificar la presencia de algunos de estos errores durante la compilación. Ellos observaron que el programador conoce muchas in­ variantes que no conoce el compilador, como el hecho de que cuando se cierra un mutex, todos los caminos a partir de ese punto deben contener una apertura y ningún otro cierre del mismo mu­ tex. Estos investigadores idearon una forma de que el programador informe de este hecho al com­ pilador y le ordene que verifique todos los caminos durante la compilación para detectar violaciones de la invariante. El programador también puede especificar que la memoria asignada debe liberarse en todos los caminos, así como muchas otras condiciones. 12.4 DESEMPEÑO En condiciones iguales, un sistema operativo rápido es mejor que uno lento. Sin embargo, un sistema operativo rápido y poco confiable no es tan bueno como uno lento pero confiable. Puesto que las optimizaciones complejas suelen llevar a errores, es importante aplicarlas sólo si en verdad son necesarias. No obstante, hay puntos en los que es crucial el desempeño y bien vale la pena optimizar. En las secciones que siguen veremos algunas técnicas generales que pueden servir para mejorar el desempeño en los lugares en que es recomendable. 12.4.1 ¿Por qué son lentos los sistemas operativos? Antes de hablar de técnicas de optimización, vale la pena señalar que la lentitud de muchos sistemas operativos en gran medida es culpa del propio sistema. Por ejemplo, los sistemas opera­ tivos más antiguos, como MS-DOS y la versión 7 de UNK, arrancaban en unos cuantos segun­ dos. Los sistemas UNIX modernos y Windows 2000 pueden tardar minutos en hacerlo, pese a ejecutarse en hardware que es 100 veces más rápido. Eso se debe a que están haciendo mucho más, se desee o no. Por ejemplo, la característica Plug and Play facilita un tanto la instalación de un nuevo dispositivo de hardware, pero el precio que se paga es que, en cada arranque, el siste­ ma operativo tiene que inspeccionar todo el hardware para ver si hay algo nuevo. Esta explora­ ción de buses toma tiempo.