TEORIA DE
SISTEMAS OPERATIVOS
EXPOSICION
DE METODOLOGIA DE DISEÑO DE SISTEMAS
LIC. GERMAN
RABANALES VAZQUEZ
MICHELL DIAZ
HDEZ
INDICE
} El problema del diseño
} Metas
} ¿Por qué es difícil diseñar sistemas operativos?
} Diseño de interfaces
} Principios para el diseño de interfaces
} Paradigmas o modelos
} La interfaz de llamadas al sistema
} Implementación
} Estructura del sistema operativo
} Mecanismos y políticas
} Ortogonalidad
} Asignación de nombres
} Estructuras estáticas y dinámicas
} Diversas técnicas útiles
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 solo puede ejecutar operaciones autorizadas con datos
autorizados
* aislar fallos
} Administrar el hardware
} ¡No hay una solución única!
¿Por qué es difícil diseñar sistemas operativos?
} Los SO son programas extremadamente grandes
} Los SO tienen que manejar concurrencia
} Los SO tienen que enfrentarse a usuarios hostiles
en potencia
} Los SO deben permitir a los usuarios compartir
} información y recursos con otros usuarios
seleccionados
} Los SO deben ser flexibles para poder
adaptarse a posibles
} cambios futuros en el Hardware y en el Software
} Los SO deben ser generales para poder ser usados
de muchas formas distintas
} Los SO deben ser (trans) portables
} Muchos SO deben ser compatibles con algún SO
anterior
Diseño de interfaces
Principio 1. Sencillez
} Las interfaces sencillas son más fáciles 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 única cosa, pero deben hacerla bien)
Principio 3. Eficiencia
} La implementación de los mecanismos debe ser eficiente
} Debe ser intuitivamente obvio para el programador
cu´anto
cuesta una llamada al
sistema.
Paradigmas
o modelos
} Para comenzar el diseño, un buen punto de partida
es pensar en como 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ónica
} Básicamente, hay dos tipos de clientes:
} Los usuarios, que interactúan con los programas
de aplicación
y la interfaz grafica de usuario (GUI)
} Los programadores, que tratan principalmente con
la interfaz
de llamadas al sistema
Paradigmas
de interfaz de usuario
} Se refieren a la forma en la que el usuario interactúa
con el sistema operativo y con los programas de aplicación que usa
} Lo importante no es el paradigma escogido, sino
que haya uno solo que unifique
toda la interfaz de usuario
} También es importante que todos los programas de
aplicación lo usen: los diseñadores del sistema deben proporcionar herramientas
para ello
} Ejemplos:
} Windows: acciones de ratón, opciones del menú (✭✭Archivo✮✮, ✭✭Edición✮✮, . . . )
} Palmos: letra manuscrita y puntero
Paradigmas
de ejecución
} Paradigma algorítmico
} La lógica básica se encuentra en el código
} El programa realiza llamadas al sistema para
solicitar servicios
} Ejemplo: Unix
} Paradigma controlado por eventos
} Tras una preparación inicial, el programa se
queda esperando a que el SO le notifique un evento.
} Útil para programas interactivos
} Ejemplo: Windows
Paradigmas
de ejecución
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ógicos 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
La interfaz
de llamadas al sistema
} Un SO debería ofrecer el menor número 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 especificos. Por ejemplo:
excl., execlp, execle, execv y execvp se basan en la misma llamada al sistem a:
execve.
} Las llamadas al sistema no deben ocultar la
potencia del hardware, sólo ocultar propiedades indeseables
} Habrá que decidir si se implementan llamadas al
sistema orientadas a conexiones o no
} Habrá que decidir si las llamadas al sistema son públicas
(Unix) o no (Windows)
Estructura
del sistema operativo
} Hay varias alternativas: por capas, exokernels,
cliente-servidor, etc.
} Partes del SO deben facilitar la construcción de
otras partes del SO:
} Ocultar interrupciones
} Proporcionar mecanismos sencillos de concurrencia
} Posibilitar la construcción de estructuras de
datos dinámicas Etc.
} ¡Prestar especial atención a los manejadores de
dispositivo!
} Constituyen una parte muy importante del sistema
global
} Son la principal fuente de inestabilidad
Mecanismos
y políticas
} La separación entre mecanismos y políticas ayuda
a la coherencia arquitectónica y a la estructuración del sistema
} Los mecanismos se pueden implementar en el núcleo
y la políticas fuera o dentro del núcleo
} Ejemplo 1. Planificacion de procesos
} Mecanismo: colas multinivel por prioridad donde
el planificador
siempre selecciona al proceso listo de mayor prioridad
} Política: planificacion apropiativa o
no, asignación de prioridades a procesos por usuario, etc.
} Ejemplo 2. Gestión de la memoria virtual
} Mecanismo: administración, listas de paginas
ocupadas y libres,
transferencia de págs.. entre memoria y disco
} Política: reemplazo de páginas global o local,
algoritmo de reemplazo de páginas, etc.
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ón de recursos (proceso) de la unidad de planificaci´on y ejecución
(hilo), permitiendo tener varios hilos dentro de un mismo proc.
} Ejemplo 2. Creación de procesos en Unix: se
diferencia entre crear el proceso en si (fork) y ejecutar un nuevo programa
(exec), lo que permite heredar y manipular defichero
} En general, tener un número reducido de elementos
ortogonales que pueden combinarse de muchas maneras da pie a un sistema
pequeño, sencillo y elegante.
Asignación de nombres
} Casi
todas las estructuras de datos duraderas que utiliza un
SO tienen algún tipo de nombre
o identificador
(nombre de
dispositivo, de fichero,
identificador
de proceso, etc.)
} Es
común que los nombres se asignen a dos niveles:
} Externo:
cadenas de caracteres (estructuradas o no) que usan los usuarios
} Interno:
identificacion
usada internamente por el SO
} Debe
existir algún mecanismo que permita asociar unos nombres con otros. Ejemplo:
los directorios (enlazan nombres de ficheros
con nodos-i)
} Un buen
diseño debe estudiar con detenimiento cuántos espacios de nombres van a
necesitarse, qué sintaxis tendrían los nombres, cómo van a distinguirse, etc.
Estructuras estáticas y
dinámicas
} ¿Las
estructuras de datos del SO deben ser estáticas o
} dinámicas?
} Las
estáticas son más comprensibles, más fáciles de programar y de uso más rápido
} Las
dinámicas son más flexibles y permiten adaptarse a
la cantidad de recursos disponibles. Problema: necesitan un gestor de memoria
dentro del propio SO
} Según
el caso, puede ser más adecuado un tipo u otro.
Ejemplo:
} Pila de
un proceso en el espacio de usuario: estructura dinámica
} Pila de
un proceso en el espacio de núcleo: estructura estática
} También
son posibles estructuras pseudo-dinamicas
Diversas
técnicas útiles para la implementación
} Ocultación
del hardware
} Ocultar
las interrupciones, convirtiéndolas en operaciones de sincronización entre
hilos (unlock en un mutex, envió 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 ´únicos
} La
compilación debe ser condicional
} La parte
de código dependiente debe ser lo más pequeña posible
} Ejemplo
1: HAL (Hardware Abstracción Layer) de Windows
} Ejemplo
2: directorios arch e include/ asm -* en Linux
Diversas técnicas ´útiles para
la implementación
} Indireccion
} ¡Flexibilidad!
} Ejemplo:
entrada por teclado. Al pulsar una tecla se obtiene un valor que no se
corresponde con su código ASCII ⇒
Posibilidad de utilizar configuraciones
distintas de teclados
} Ejemplo:
salida por pantalla. El código ASCII es el ´índice de una tabla con el patrón
de bits del carácter 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úmeros mayor y menor de dispositivo ⇒ Posibilidad de cambiar el
nombre a un dispositivo
} Mishell
Díaz
Diversas
técnicas útiles para la implementación
} Reentrabilidad
} Se refiere a
la capacidad de un fragmento de código dado para ejecutarse dos o más veces de
forma simultánea
} La
ejecución simultánea se puede dar en varios casos:
} En un
multiprocesador dos o más procesadores pueden estar
} ejecutando
la misma porción de código
} En un
monoprocesador puede llegar una interrupción que
} ejecute
la misma porción de código 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
Diversas
técnicas útiles para la implementación
} 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úsquedas sean más rápidas?
} 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
Diversas
técnicas útiles para la implementación
} 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én
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 ´éxito, hay que obtener los recursos necesarios (¡cuidado con los
posibles interbloqueos!)
} Acelera
la ejecución en el caso de que la llamada no se pueda realizar
Rendimiento
} ¿Qué es
mejor, un SO rápido y poco fiable o uno lento pero fiable?
} Las
optimizaciones complejas suelen llevar a errores ⇒ Optimizar sólo si realmente es necesario
} ¿Qué es
mejor, un SO sencillo y rápido o uno complejo y lento? ¡Lo pequeño es bello! ⇒ Antes de añadir 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
* Otra consideración importante es el lenguaje
de programación a utilizar
Uso de
cachés
} 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. Cachê de bloques o cachê de disco
} Ejemplo
2. Caché de entradas de directorio
} Ejemplo
3. Caché de páginas
Optimización
del caso común
} En
muchos casos es recomendable distinguir entre el caso más común y el peor caso
posible:
} Es
importante que el caso común sea rápido
} 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 éxito ⇒ Entrar
a la sección 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áforo hasta que
pueda entrar a la sección crítica
} Si lo normal
es que la primera comprobación tenga éxito, nos
} habremos
ahorrado entrar al núcleo del SO
Bibliografía
} Andrew
Tanenbaum.
} ✭✭Sistemas Operativos Modernos✮✮, 2ª edición, capítulo 12.
Prentice Hall, 2003
} Gary
Nutt.
} ✭✭Sistemas Operativos✮✮, 3ª edición, capítulo 19.
Addison Wesley, 2004
