Tema1 Isa

El problema del dise no
Dise no de interfaces
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Tema 1. Dise no de Sistemas Operativos
Juan Piernas Canovas
Departamento de Ingeniera y Tecnologa de Computadores
Universidad de Murcia
Juan Piernas Canovas Tema 1. Dise no de Sistemas Operativos
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Indice
1
Metas
Por que es difcil dise nar sistemas operativos?
2
Principios para el dise no de interfaces
Paradigmas o modelos
La interfaz de llamadas al sistema
3
Implementaci on
Estructura del sistema operativo
Mecanismos y polticas
Ortogonalidad
Asignaci on de nombres
Estructuras estaticas y dinamicas
Diversas tecnicas utiles
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Indice (continuacion. . . )
4
Rendimiento
Equilibrio espacio-tiempo
Uso de caches
Optimizaci on del caso com un
5
El mtico hombremes
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Metas
Metas
Es importante tener una idea clara de lo que se quiere!
Principales objetivos que se suelen perseguir:
Denir abstracciones: procesos, cheros, hilos, . . .
Proporcionar operaciones primitivas para manejar las
abstracciones denidas
Garantizar el aislamiento:
los usuarios solo puede ejecutar operaciones autorizadas con
datos autorizados
aislar fallos
Administrar el hardware
No hay una solucion unica!
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Metas
Razones por las que es difcil dise nar un sistema operativo
1
Los SSOO son programas extremadamente grandes
2
Los SSOO tienen que manejar concurrencia
3
Los SSOO tienen que enfrentarse a usuarios hostiles en
potencia
4
Los SSOO deben permitir a los usuarios compartir
informacion y recursos con otros usuarios seleccionados
5
Los SSOO deben ser exibles para poder adaptarse a posibles
cambios futuros en el Hardware y en el Software
6
Los SSOO deben ser generales para poder ser usados de
muchas formas distintas
7
Los SSOO deben ser (trans)portables
8
Muchos SSOO deben ser compatibles con alg un SO anterior
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Por donde empezar a dise nar un sistema operativo?
Por denir la interfaz (abstracciones y operaciones primitivas)
a proporcionar a los programadores de sistemas
Sin olvidar las interfaces internas
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Principio 1. Sencillez
Las interfaces sencillas son mas faciles 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 unica cosa, pero deben hacerla
bien)
Principio 3. Eciencia
La implementaci on de los mecanismos debe ser eciente
Debe ser intuitivamente obvio para el programador cuanto
cuesta una llamada al sistema
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Para comenzar el dise no, un buen punto de partida es pensar
en como van los clientes a ver el sistema
Para los clientes es importante que todas las caractersticas
del sistema formen un conjunto consistente coherencia
arquitectonica
Basicamente, hay dos tipos de clientes:
Los usuarios, que interact uan con los programas de aplicaci on
y la interfaz graca 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)
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Paradigmas de interfaz de usuario
Se reeren a la forma en la que el usuario interact ua con el
sistema operativo y con los programas de aplicacion que usa
Lo importante no es el paradigma escogido, sino que haya uno
solo que unique toda la interfaz de usuario
Tambien es importante que todos los programas de aplicacion
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
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Paradigmas de ejecucion
Paradigma algortmico
La logica basica se encuentra en el codigo
El programa realiza llamadas al sistema para solicitar servicios
Ejemplo: Unix
Paradigma controlado por eventos
Tras una preparacion inicial, el programa se queda esperando a
que el SO le notique un evento
Util para programas interactivos

Ejemplo: Windows
Estos paradigmas no son excluyentes
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Paradigmas de ejecucion (continuacion. . . )
main( ) main( )
{ {
int ... ; mess_t msg;
init( ); init( );
do_something( ); while (get _message(&msg)) {
read(...); switch (msg.type) {
do_something_else( ); case 1: ... ;
write(...); case 2: ... ;
keep_going( ); case 3: ... ;
exit(0); }
} }
}
(a) (b)
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Paradigmas de datos
Todo SO debe tener un paradigma de datos que unique la
forma en la que la interfaz de llamadas al sistema representa a
los recursos (l ogicos o fsicos) denidos en el sistema
Ejemplos:
FORTRAN: todo es una cinta
Unix: todo es un chero
Windows: todo es un objeto
Web: todo es un documento
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Un SO debera ofrecer el menor n umero posible de llamadas al
sistema. Para ello:
Importante tener un paradigma de datos unicador
Llamadas al sistema que manejen el caso general (sin perder
la sencillez!) y procedimientos de biblioteca especcos. 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, solo ocultar propiedades indeseables
Habra que decidir si se implementan llamadas al sistema
orientadas a conexiones o no
Habra que decidir si las llamadas al sistema son p ublicas
(Unix) o no (Windows)
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
Asignacion de nombres
Hay varias alternativas: por capas, exokernels, cliente-servidor,
etc. (vease Tema 2)
Partes del SO deben facilitar la construcci on de otras partes
del SO:
Ocultar interrupciones
Proporcionar mecanismos sencillos de concurrencia
Posibilitar la construccion de estructuras de datos dinamicas
Etc.
Prestar especial atencion a los manejadores de dispositivo!
Constituyen una parte muy importante del sistema global
Son la principal fuente de inestabilidad
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
La separacion entre mecanismos y polticas ayuda a la
coherencia arquitect onica y a la estructuraci on del sistema
Los mecanismos se pueden implementar en el n ucleo y las
polticas fuera o dentro del n ucleo
Ejemplo 1. Planicaci on de procesos
Mecanismo: colas multinivel por prioridad donde el planicador
siempre selecciona al proceso listo de mayor prioridad
Poltica: planicaci on apropiativa o no, asignaci on de
prioridades a procesos por usuario, etc.
Ejemplo 2. Gestion de la memoria virtual
Mecanismo: administracion de la MMU, listas de paginas
ocupadas y libres, transferencia de pags. entre memoria y disco
Poltica: reemplazo de paginas global o local, algoritmo de
reemplazo de paginas, etc.
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
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 planicacion y ejecucion
(hilo), permitiendo tener varios hilos dentro de un mismo proc.
Ejemplo 2. Creacion 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 chero
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.
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
Casi todas las estructuras de datos duraderas que utiliza un
SO tienen alg un tipo de nombre o identicador (nombre de
dispositivo, de chero, identicador 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: identicaci on usada internamente por el SO
Debe existir alg un mecanismo que permita asociar unos
nombres con otros. Ejemplo: los directorios (enlazan nombres
de cheros con nodos-i)
Un buen dise no debe estudiar con detenimiento cuantos
espacios de nombres van a necesitarse, que sintaxis tendran
los nombres, como van a distinguirse, etc.
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
Las estructuras de datos del SO deben ser estaticas o
dinamicas?
Las estaticas son mas comprensibles, mas faciles de programar
y de uso mas rapido
Las dinamicas son mas exibles 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 mas adecuado un tipo u otro.
Ejemplo:
Pila de un proceso en el espacio de usuario: estructura
dinamica
Pila de un proceso en el espacio de n ucleo: estructura estatica
Tambien son posibles estructuras pseudo-dinamicas
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
Diversas tecnicas utiles para la implementacion
Ocultacion del hardware
Ocultar las interrupciones, convirtiendolas en operaciones de
sincronizacion entre hilos (unlock en un mutex, envo 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 unicos
La compilacion debe ser condicional
La parte de codigo dependiente debe ser lo mas peque na
posible
Ejemplo 1: HAL (Hardware Abstraction Layer) de Windows
Ejemplo 2: directorios arch e include/asm-* en Linux
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
Indireccion
Flexibilidad!
Ejemplo: entrada por teclado. Al pulsar una tecla se obtiene un
valor que no se corresponde con su codigo ASCII
Posibilidad de utilizar conguraciones distintas de teclados
Ejemplo: salida por pantalla. El codigo ASCII es el ndice de
una tabla con el patr on de bits del caracter a representar
Posibilidad de congurar el tipo de letra de pantalla
Ejemplo: nombres de dispositivo. En Linux, los nombres de los
cheros 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.
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
Reentrabilidad
Se reere a la capacidad de un fragmento de codigo dado para
ejecutarse dos o mas veces de forma simultanea
La ejecucion simultanea se puede dar en varios casos:
En un multiprocesador dos o mas procesadores pueden estar
ejecutando la misma porcion de codigo
En un monoprocesador puede llegar una interrupcion que
ejecute la misma porcion de codigo 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 crticas se protejan
que las interrupciones se inhabiliten cuando no se puedan
tolerar
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
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 mas rapidas?
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
crtica! Ejemplo: cambio de contexto
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
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, ags =%lx) \n,
p->comm, p->pid, cpu, p->state, p->ags);
}
write unlock irq(&tasklist lock);
}
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
Vericar primero si hay errores
Una llamada al sistema puede fallar por muchas razones:
cheros que no existen o que pertenecen a otra persona,
destinatario de un mensaje que no existe, etc.
Tambien 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 ejecucion en el caso de que la llamada no se pueda
realizar
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Ortogonalidad
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 nd 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;
}
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Uso de caches
Optimizacion del caso com un
Rendimiento
Que es mejor, un SO rapido y poco able o uno lento pero
able?
Las optimizaciones complejas suelen llevar a errores
Optimizar solo si realmente es necesario
Que es mejor, un SO sencillo y rapido 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 sucientemente bueno (good
enough is good enough)
Otra consideracion importante es el lenguaje de programaci on
a utilizar
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Uso de caches
#dene BYTE_SIZE 8 /* A byte contains 8 bits */
int bit _count(int byte)
{ /
*
Count the bits in a byte.
*
/
int i, count = 0;
for (i = 0; i < BYTE_SIZE; i++) /
*
loop over the bits in a byte
*
/
if ((byte >> i) & 1) count++; /
*
if this bit is a 1, add to count
*
/
return(count); /
*
return sum
*
/
}
(a)
/
*
Macro to add up the bits in a byte and return the sum.
*
/
#dene 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, ...};
#dene bit _count(b) (int) bits[b]
(c)
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Uso de caches
Uso de caches
Se aplican en situaciones en las que es probable que el mismo
resultado se necesite varias veces
Especialmente utiles para dispositivos de E/S
Ejemplo 1. Cache de bloques o cache de disco
Ejemplo 2. Cache de entradas de directorio
Ejemplo 3. Cache de paginas
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Uso de caches
En muchos casos es recomendable distinguir entre el caso mas
com un y el peor caso posible:
Es importante que el caso com un sea rapido
El peor caso, si no se presenta a menudo, solo 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 seccion crtica (no ha hecho
falta una llamada al sistema)
En caso de fracaso Ejecutar una llamada al sistema que
bloquee al proceso en un semaforo hasta que pueda entrar a la
seccion crtica
Si lo normal es que la primera comprobacion tenga exito, nos
habremos ahorrado entrar al n ucleo del SO
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
El mtico hombremes
Seg un Brooks: un programador solo puede producir 1000
lneas de codigo depurado al a no en un proyecto grande
Los proyectos grandes, con cientos de programadores =
proyectos peque nos Resultados no extrapolables
En proyectos grandes, el trabajo se compone de:
1/3 planicacion
1/6 codicacion
1/4 prueba de modulos
1/4 prueba del sistema
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
El mtico hombremes (continuacion. . . )
Para Brooks, no existe una unidad hombremes: 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 n
o
de los mismos
La depuracion es secuencial
Ley de Brooks: ((la adici on de personal a un proyecto de
software atrasado lo atrasa mas a un))
Implementaci on
Rendimiento
El mtico hombremes
Bibliografa
Bibliografa
Andrew Tanenbaum.
((Sistemas Operativos Modernos)), 2
a
edici on, captulo 12.
Prentice Hall, 2003
Gary Nutt.
((Sistemas Operativos)), 3
a
edici on, captulo 19.
Addison Wesley, 2004

Tema1 Isa

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema1 Isa

Cargado por

Copyright:

Formatos disponibles

El problema del dise no

Util para programas interactivos

También podría gustarte