Story Transcript
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Tema 1. Dise˜no de Sistemas Operativos Juan Piernas C´anovas Departamento de Ingenier´ıa y Tecnolog´ıa de Computadores Universidad de Murcia
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
´Indice 1
2
3
El problema del dise˜ no Metas ¿Por qu´e es dif´ıcil dise˜ nar sistemas operativos? Dise˜ no de interfaces Principios para el dise˜ no de interfaces Paradigmas o modelos La interfaz de llamadas al sistema Implementaci´ on Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´aticas y din´amicas Diversas t´ecnicas u ´tiles Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
´Indice (continuaci´on. . . )
4
Rendimiento Equilibrio espacio-tiempo Uso de cach´es Optimizaci´ on del caso com´ un
5
El m´ıtico hombre–mes
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Metas ¿Por qu´ e es dif´ıcil dise˜ nar sistemas operativos?
Metas ¡Es importante tener una idea clara de lo que se quiere! Principales objetivos que se suelen perseguir: Definir abstracciones: procesos, ficheros, hilos, . . . Proporcionar operaciones primitivas para manejar las abstracciones definidas Garantizar el aislamiento: los usuarios s´ olo puede ejecutar operaciones autorizadas con datos autorizados aislar fallos
Administrar el hardware
¡No hay una soluci´on u ´nica!
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Metas ¿Por qu´ e es dif´ıcil dise˜ nar sistemas operativos?
Razones por las que es dif´ıcil dise˜nar un sistema operativo 1 2 3
4
5
6
7 8
Los SSOO son programas extremadamente grandes Los SSOO tienen que manejar concurrencia Los SSOO tienen que enfrentarse a usuarios hostiles en potencia Los SSOO deben permitir a los usuarios compartir informaci´on y recursos con otros usuarios seleccionados Los SSOO deben ser flexibles para poder adaptarse a posibles cambios futuros en el Hardware y en el Software Los SSOO deben ser generales para poder ser usados de muchas formas distintas Los SSOO deben ser (trans)portables Muchos SSOO deben ser compatibles con alg´ un SO anterior Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Principios para el dise˜ no de interfaces Paradigmas o modelos La interfaz de llamadas al sistema
¿Por d´onde empezar a dise˜nar un sistema operativo?
Por definir la interfaz (abstracciones y operaciones primitivas) a proporcionar a los programadores de sistemas Sin olvidar las interfaces internas
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Principios para el dise˜ no de interfaces Paradigmas o modelos La interfaz de llamadas al sistema
Principios para el dise˜no de interfaces Principio 1. Sencillez Las interfaces sencillas son m´as f´aciles de entender e implementar
Principio 2. Integridad La interfaz debe permitir hacer todo lo que los usuarios necesitan hacer Pero los mecanismos que soportan la interfaz deben ser pocos y sencillos (deben hacer una u ´nica cosa, pero deben hacerla bien)
Principio 3. Eficiencia La implementaci´ on de los mecanismos debe ser eficiente Debe ser intuitivamente obvio para el programador cu´anto cuesta una llamada al sistema Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Principios para el dise˜ no de interfaces Paradigmas o modelos La interfaz de llamadas al sistema
Paradigmas o modelos Para comenzar el dise˜ no, un buen punto de partida es pensar en c´omo van los clientes a ver el sistema Para los clientes es importante que todas las caracter´ısticas del sistema formen un conjunto consistente ⇒ coherencia arquitect´ onica B´asicamente, hay dos tipos de clientes: Los usuarios, que interact´ uan con los programas de aplicaci´ on y la interfaz gr´afica de usuario (GUI) Los programadores, que tratan principalmente con la interfaz de llamadas al sistema
Atendiendo a un tipo u otro de cliente, se puede crear primero la GUI (dise˜ no descendente) o primero la interfaz de llamadas al sistema (dise˜ no ascendente) Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Principios para el dise˜ no de interfaces Paradigmas o modelos La interfaz de llamadas al sistema
Paradigmas de interfaz de usuario Se refieren a la forma en la que el usuario interact´ ua con el sistema operativo y con los programas de aplicaci´on que usa Lo importante no es el paradigma escogido, sino que haya uno solo que unifique toda la interfaz de usuario Tambi´en es importante que todos los programas de aplicaci´on lo usen: los dise˜ nadores del sistema deben proporcionar herramientas para ello Ejemplos: Windows: acciones de rat´ on, opciones del men´ u (((Archivo)), ((Edici´ on)), . . . ) PalmOS: letra manuscrita y puntero
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Principios para el dise˜ no de interfaces Paradigmas o modelos La interfaz de llamadas al sistema
Paradigmas de ejecuci´on Paradigma algor´ıtmico La l´ogica b´asica se encuentra en el c´odigo El programa realiza llamadas al sistema para solicitar servicios Ejemplo: Unix
Paradigma controlado por eventos Tras una preparaci´on inicial, el programa se queda esperando a que el SO le notifique un evento ´ para programas interactivos Util Ejemplo: Windows
Estos paradigmas no son excluyentes
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Principios para el dise˜ no de interfaces Paradigmas o modelos La interfaz de llamadas al sistema
Paradigmas de ejecuci´on (continuaci´on. . . )
main( ) { int ... ;
main( ) { mess_t msg;
init( ); do_something( ); read(...); do_something _else( ); write(...); keep_going( ); exit(0);
init( ); while (get _message(&msg)) { switch (msg.type) { case 1: ... ; case 2: ... ; case 3: ... ; } }
} } (a)
(b)
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Principios para el dise˜ no de interfaces Paradigmas o modelos La interfaz de llamadas al sistema
Paradigmas de datos
Todo SO debe tener un paradigma de datos que unifique la forma en la que la interfaz de llamadas al sistema representa a los recursos (l´ ogicos o f´ısicos) definidos en el sistema Ejemplos: FORTRAN: todo es una cinta Unix: todo es un fichero Windows: todo es un objeto Web: todo es un documento
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Principios para el dise˜ no de interfaces Paradigmas o modelos La interfaz de llamadas al sistema
La interfaz de llamadas al sistema Un SO deber´ıa ofrecer el menor n´ umero posible de llamadas al sistema. Para ello: Importante tener un paradigma de datos unificador Llamadas al sistema que manejen el caso general (¡sin perder la sencillez!) y procedimientos de biblioteca espec´ıficos. Por ejemplo: execl, execlp, execle, execv y execvp se basan en la misma llamada al sistema: execve.
Las llamadas al sistema no deben ocultar la potencia del hardware, s´olo ocultar propiedades indeseables Habr´a que decidir si se implementan llamadas al sistema orientadas a conexiones o no Habr´a que decidir si las llamadas al sistema son p´ ublicas (Unix) o no (Windows) Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Estructura del sistema operativo Hay varias alternativas: por capas, exokernels, cliente-servidor, etc. (v´ease Tema 2) Partes del SO deben facilitar la construcci´ on de otras partes del SO: Ocultar interrupciones Proporcionar mecanismos sencillos de concurrencia Posibilitar la construcci´on de estructuras de datos din´amicas Etc.
¡Prestar especial atenci´on a los manejadores de dispositivo! Constituyen una parte muy importante del sistema global Son la principal fuente de inestabilidad
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Mecanismos y pol´ıticas La separaci´on entre mecanismos y pol´ıticas ayuda a la coherencia arquitect´ onica y a la estructuraci´ on del sistema Los mecanismos se pueden implementar en el n´ ucleo y las pol´ıticas fuera o dentro del n´ ucleo Ejemplo 1. Planificaci´ on de procesos Mecanismo: colas multinivel por prioridad donde el planificador siempre selecciona al proceso listo de mayor prioridad Pol´ıtica: planificaci´ on apropiativa o no, asignaci´ on de prioridades a procesos por usuario, etc.
Ejemplo 2. Gesti´on de la memoria virtual Mecanismo: administraci´on de la MMU, listas de p´aginas ocupadas y libres, transferencia de p´ags. entre memoria y disco Pol´ıtica: reemplazo de p´aginas global o local, algoritmo de reemplazo de p´aginas, etc. Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Ortogonalidad Ortogonalidad: capacidad de combinar conceptos distintos de forma independiente. Es consecuencia directa de los principios de sencillez e integridad. Ejemplo 1. Procesos e hilos: separan la unidad de asignaci´ on de recursos (proceso) de la unidad de planificaci´on y ejecuci´on (hilo), permitiendo tener varios hilos dentro de un mismo proc. Ejemplo 2. Creaci´on de procesos en Unix: se diferencia entre crear el proceso en s´ı (fork) y ejecutar un nuevo programa (exec), lo que permite heredar y manipular descs. de fichero En general, tener un n´ umero reducido de elementos ortogonales que pueden combinarse de muchas maneras da pie a un sistema peque˜ no, sencillo y elegante. Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Asignaci´on de nombres Casi todas las estructuras de datos duraderas que utiliza un SO tienen alg´ un tipo de nombre o identificador (nombre de dispositivo, de fichero, identificador de proceso, etc.) Es com´ un que los nombres se asignen a dos niveles: Externo: cadenas de caracteres (estructuradas o no) que usan los usuarios Interno: identificaci´ on usada internamente por el SO
Debe existir alg´ un mecanismo que permita asociar unos nombres con otros. Ejemplo: los directorios (enlazan nombres de ficheros con nodos-i) Un buen dise˜ no debe estudiar con detenimiento cu´antos espacios de nombres van a necesitarse, qu´e sintaxis tendr´an los nombres, c´omo van a distinguirse, etc. Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Estructuras est´aticas y din´amicas ¿Las estructuras de datos del SO deben ser est´aticas o din´amicas? Las est´aticas son m´as comprensibles, m´as f´aciles de programar y de uso m´as r´apido Las din´amicas son m´as flexibles y permiten adaptarse a la cantidad de recursos disponibles. Problema: necesitan un gestor de memoria dentro del propio SO Seg´ un el caso, puede ser m´as adecuado un tipo u otro. Ejemplo: Pila de un proceso en el espacio de usuario: estructura din´amica Pila de un proceso en el espacio de n´ ucleo: estructura est´atica
Tambi´en son posibles estructuras pseudo-din´amicas Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Diversas t´ecnicas u´tiles para la implementaci´on Ocultaci´on del hardware Ocultar las interrupciones, convirti´endolas en operaciones de sincronizaci´on entre hilos (unlock en un mutex, env´ıo de un mensaje, etc.) Ocultar las peculiaridades de la arquitectura hardware si se desea facilitar la transportabilidad del SO Los fuentes del SO deben ser u ´nicos La compilaci´ on debe ser condicional La parte de c´ odigo dependiente debe ser lo m´ as peque˜ na posible
Ejemplo 1: HAL (Hardware Abstraction Layer) de Windows Ejemplo 2: directorios arch e include/asm-* en Linux
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Diversas t´ecnicas u´tiles para la implementaci´on Indirecci´on ¡Flexibilidad! Ejemplo: entrada por teclado. Al pulsar una tecla se obtiene un valor que no se corresponde con su c´odigo ASCII ⇒ Posibilidad de utilizar configuraciones distintas de teclados Ejemplo: salida por pantalla. El c´odigo ASCII es el ´ındice de una tabla con el patr´ on de bits del car´acter a representar ⇒ Posibilidad de configurar el tipo de letra de pantalla Ejemplo: nombres de dispositivo. En Linux, los nombres de los ficheros especiales son independientes de los n´ umeros mayor y menor de dispositivo ⇒ Posibilidad de cambiar el nombre a un dispositivo David Wheeler: “All problems in computer science can be solved by another level of indirection.” Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Diversas t´ecnicas u´tiles para la implementaci´on Reentrabilidad Se refiere a la capacidad de un fragmento de c´odigo dado para ejecutarse dos o m´as veces de forma simult´anea La ejecuci´on simult´anea se puede dar en varios casos: En un multiprocesador dos o m´ as procesadores pueden estar ejecutando la misma porci´ on de c´ odigo En un monoprocesador puede llegar una interrupci´ on que ejecute la misma porci´ on de c´ odigo que se estaba ejecutando
Lo mejor, incluso en un monoprocesador, es que: la mayor parte del SO sea reentrante (para que no se pierdan interrupciones), que las secciones cr´ıticas se protejan que las interrupciones se inhabiliten cuando no se puedan tolerar Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Diversas t´ecnicas u´tiles para la implementaci´on
Fuerza bruta ¡Optimizar cuando realmente merezca la pena! Ejemplo 1. ¿Merece la pena tener ordenada una tabla de 100 elementos que cambia continuamente para que las b´ usquedas sean m´as r´apidas? Ejemplo 2. ¿Merece la pena optimizar una llamada al sistema que tarda 10 ms para que tarde 1 ms si se utiliza una vez cada 10 segundos? ¡Optimizar las funciones y estructuras de datos de la ruta cr´ıtica! Ejemplo: cambio de contexto
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Diversas t´ecnicas u´tiles para la implementaci´on static inline void check for tasks(int cpu) { struct task struct *p; write lock irq(&tasklist lock); for each process(p) { if (task cpu(p) == cpu && (p->utime != 0 || p->stime != 0)) printk(KERN WARNING ”Task %s (pid = %d) is on cpu %d\ (state = %ld, flags = %lx) \n”, p->comm, p->pid, cpu, p->state, p->flags); } write unlock irq(&tasklist lock); } Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Diversas t´ecnicas u´tiles para la implementaci´on Verificar primero si hay errores Una llamada al sistema puede fallar por muchas razones: ficheros que no existen o que pertenecen a otra persona, destinatario de un mensaje que no existe, etc. Tambi´en hay llamadas al sistema que necesitan obtener recursos Lo mejor es comprobar primero si en verdad puede efectuarse la llamada al sistema ⇒ Situar todas las pruebas al principio del procedimiento que ejecuta la llamada al sistema Tras asegurarse el ´exito, hay que obtener los recursos necesarios (¡cuidado con los posibles interbloqueos!) Acelera la ejecuci´on en el caso de que la llamada no se pueda realizar Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Estructura del sistema operativo Mecanismos y pol´ıticas Ortogonalidad Asignaci´ on de nombres Estructuras est´ aticas y din´ amicas Diversas t´ ecnicas u ´tiles
Diversas t´ecnicas u´tiles para la implementaci´on static int ext2 unlink(struct inode * dir, struct dentry *dentry) { struct inode * inode = dentry->d inode; struct ext2 dir entry 2 * de; struct page * page; int err = -ENOENT; de = ext2 find entry (dir, dentry, &page); if (!de) goto out; err = ext2 delete entry (de, page); if (err) goto out; inode->i ctime = dir->i ctime; ext2 dec count(inode); err = 0; out: return err; } Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Equilibrio espacio-tiempo Uso de cach´ es Optimizaci´ on del caso com´ un
Rendimiento ¿Qu´e es mejor, un SO r´apido y poco fiable o uno lento pero fiable? Las optimizaciones complejas suelen llevar a errores ⇒ Optimizar s´olo si realmente es necesario ¿Qu´e es mejor, un SO sencillo y r´apido o uno complejo y lento? ¡Lo peque˜ no es bello! ⇒ Antes de a˜ nadir una funcionalidad nueva compruebe que realmente merece la pena En cualquier caso, antes de optimizar, tenga en cuenta que lo bastante bueno es generalmente suficientemente bueno (good enough is good enough) Otra consideraci´on importante es el lenguaje de programaci´ on a utilizar Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Equilibrio espacio-tiempo Uso de cach´ es Optimizaci´ on del caso com´ un
Equilibrio espacio-tiempo #define BYTE _SIZE 8 int bit_count(int byte) { int i, count = 0; for (i = 0; i < BYTE_SIZE; i++) if ((byte >> i) & 1) count++; return(count); } (a)
/* A byte contains 8 bits */ /* Count the bits in a byte. */ /* loop over the bits in a byte */ /* if this bit is a 1, add to count */ /* return sum */
/*Macro to add up the bits in a byte and return the sum. */ #define bit_count(b) (b&1) + ((b>>1)&1) + ((b>>2)&1) + ((b>>3)&1) + \ ((b>>4)&1) + ((b>>5)&1) + ((b>>6)&1) + ((b>>7)&1) (b) /*Macro to look up the bit count in a table. */ char bits[256] = {0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4, 1, 2, 2, 3, 2, 3, 3, ...}; #define bit_count(b) (int) bits[b] (c) Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Equilibrio espacio-tiempo Uso de cach´ es Optimizaci´ on del caso com´ un
Uso de cach´es
Se aplican en situaciones en las que es probable que el mismo resultado se necesite varias veces Especialmente u ´tiles para dispositivos de E/S Ejemplo 1. Cach´e de bloques o cach´e de disco Ejemplo 2. Cach´e de entradas de directorio Ejemplo 3. Cach´e de p´aginas
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Equilibrio espacio-tiempo Uso de cach´ es Optimizaci´ on del caso com´ un
Optimizaci´on del caso com´un En muchos casos es recomendable distinguir entre el caso m´as com´ un y el peor caso posible: Es importante que el caso com´ un sea r´apido El peor caso, si no se presenta a menudo, s´olo tiene que manejarse correctamente
Ejemplo: llamada EnterCriticalSection del API Win32. Algoritmo: Comprobar y cerrar mutex en espacio de usuario En caso de ´exito ⇒ Entrar a la secci´ on cr´ıtica (no ha hecho falta una llamada al sistema) En caso de fracaso ⇒ Ejecutar una llamada al sistema que bloquee al proceso en un sem´ aforo hasta que pueda entrar a la secci´ on cr´ıtica
Si lo normal es que la primera comprobaci´on tenga ´exito, nos habremos ahorrado entrar al n´ ucleo del SO Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
El m´ıtico hombre–mes
Seg´ un Brooks: un programador s´olo puede producir 1000 l´ıneas de c´odigo depurado al a˜ no en un proyecto grande Los proyectos grandes, con cientos de programadores 6= proyectos peque˜ nos ⇒ Resultados no extrapolables En proyectos grandes, el trabajo se compone de: 1/3 planificaci´ on 1/6 codificaci´ on
Juan Piernas C´ anovas
1/4 prueba de m´ odulos 1/4 prueba del sistema
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
El m´ıtico hombre–mes (continuaci´on. . . )
Para Brooks, no existe una unidad hombre–mes: si 15 personas tardan dos a˜ nos en un proyecto, 360 no van a tardar 1 mes. Razones: El trabajo no puede dividirse totalmente en actividades paralelas El trabajo debe dividirse en muchos m´ odulos y las interacciones entre ellos crecen con con el cuadrado del no de los mismos La depuraci´on es secuencial
Ley de Brooks: ((la adici´ on de personal a un proyecto de software atrasado lo atrasa m´as a´ un))
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos
El problema del dise˜ no Dise˜ no de interfaces Implementaci´ on Rendimiento El m´ıtico hombre–mes Bibliograf´ıa
Bibliograf´ıa
Andrew Tanenbaum. ((Sistemas Operativos Modernos)), 2a edici´ on, cap´ıtulo 12. Prentice Hall, 2003 Gary Nutt. ((Sistemas Operativos)), 3a edici´ on, cap´ıtulo 19. Addison Wesley, 2004
Juan Piernas C´ anovas
Tema 1. Dise˜ no de Sistemas Operativos