Este documento presenta detalles sobre un curso de sistemas operativos. Explica qué es un sistema operativo, sus objetivos, evaluación, reglas y aspectos importantes como la administración de recursos, abstracción del hardware y apoyo a usuarios y programadores. También resume los contenidos tentativos como aspectos generales e historia, administración de procesos, memoria, E/S, archivos y protección.

1. Sistemas de Computación 2007-1 Cecilia Hernández [email_address]

2. Que veremos hoy? Detalles del curso Aspectos importantes acerca SOs Qué es un SO (Sistema Operativo)? Contenidos Objetivos Tendencias

3. Detalles del curso Sitio web: http://www.inf.udec.cl/~sc Bibliografía Silberschatz, Galvin, Gagne, "Operating System Concepts", 5th y 6th edition, John Wiley & Sons, Inc (2003) Silberschatz, Galvin, Gagne, "Operating System Concepts with Java", 6th edition, John Wiley & Sons, Inc (2004) Andrew Tanenbaum, “Sistemas Operativos Modernos”, Primera Edición, Prentice Hall. 1993. Deitel H. M. “Sistemas Operativos”. Segunda Edición, Addison Wesley Iberoamericana. 1993. Bovet Daniel P., Sesati Marco, “Understanding the Linux Kernel” (2nd Edition). O'Reilly Media, Inc. 2002 Andrew Tanenbaum, “Sistemas Operativos Distribuidos”, Primera Edición, Prentice Hall. 1995

4. Evaluación 2 Certámenes Aprox. 6 Proyectos Participación Nota Presentación : 0.85*prom certs + 0.15*prom proyectos Si Nota Presentación < 4 Nota Final = Nota Presentación*0.65 + Examen*0.3 + Nota Participación*0.05 Else Nota Final = 0.65*prom certs + 0.3*prom proyectos + Nota Participación*0.05

5. Reglas del Juego Trabajos en grupos de 2 o 3 personas. Penalidad por atraso, 10% por día, sábado y domingo incluídos No asistencia a certamen/proyecto/tarea debe ser avalado con certificado médico La no entrega de tarea o proyecto tiene como consecuencia calidad de NCR La copia de un certamen/proyecto/tarea es causal de 1 para los involucrados

6. Aspectos importantes acerca SO SO: Componente básico de un sistema computacional moderno Magia para la mayoría de las personas SO: ejemplo de sistema complejo Muy grande, muy caro de construir Windows NT, XP: por ~10 años, más de 1000 personas involucradas. Cómo manejar complejidad? Abstracción, modularidad, proceso iterativo Int main() { cout<<“ Hola Mundo”<<endl;} Requiere ejecución de muchas líneas de código, no visible a programador.

7. Qué es un SO? SO : software entre Hardware y aplicaciones Proporciona abstracción del hardware Proporciona protección Permite utilizar hardware de millones de maneras emacs SO Hardware g++ Aplicación/Firefox

8. Objetivos de la clase Perspectiva de los Sistemas Operativos Como usuario/programador, como desarrollar aplicaciones Como diseñar/implementar un Sistema Operativo Aspectos a aprender en esta clase Cuáles son las partes de un sistema operativo Componentes de SO y su interacción Cuáles son las interfaces importantes Cuáles son las características/requerimientos de un sistema operativo (se compromenten y varían en el tiempo) Políticas y mecanismos Cuáles son los algoritmos típicos utilizados

9. Programa Tentativo Aspectos Generales e Historia Administración de Procesos Administración de Memoria Sistemas de Entrada/Salida Sistemas de Archivos Protección y Seguridad Inroducción a Sistemas Distribuidos

10. Sistemas Operativos Qué es ? Administrador de recursos Abstracción Desempeño Protección Soporte usuario/programador Abstracción Normalmente viene con conjunto de utilitarios Todo el software que el usuario no escribió que le permite escribir aplicaciones No completamente, programador utiliza editores, compiladores y bibliotecas que no son parte de SO, pero muchas veces vienen con instalaciones estandar

11. Definición de Sistema Operativo Como administrador de recursos Nivel de software que maneja y controla los recursos computacionales y periféricos por el usuario . Abstracción de complejidad del hardware. Sistema operativo abstrae hardware en recursos lógicos CPU -> Procesos, Hebras Memoria -> Memoria virtual, paginación Disco -> Archivos Tarjetas de Red -> sockets Control en la ejecución de procesos, protección usuarios, etc. Como apoyo en el desarrollo de aplicaciones Set de utilitarios y ambientes que ayudan al usuario a crear aplicaciones Shells, sistemas gráficos, etc

12. Estructura Lógica de un Sistema Operativo Servicios para Aplicaciones Servicios independientes del Hardware Servicios dependientes del Hardware Shells Ambientes gráficos Utilitarios Administración de Procesos TCP/IP Sistemas Archivos Drivers Administración de Memoria Interrupciones, Memoria física, TLB, CPUs, dispositivos Control de acceso

13. Beneficios usando SO Para programadores desarrollando aplicaciones Facilidades para programar Es mejor usar archivos a tener que lidiar con el disco directamente Portabilidad (configuración entre máquinas y arquitecturas) Para usuarios Seguridad Sistema operativo proteje procesos (espacios de memoria independientes). De usuarios, usuario/kernel Justicia Sistema operativo regula que todos los procesos tengan su oportinidad de ejecución Eficiencia Muchos usuarios pueden compartir un Computador Muchos procesos se ejecutan concurrentemente

14. Características/requerimientos de un SO Estructura . Como organizar componentes de SO Compartir . Como los usuarios comparten los recursos Nombres . Como los usuarios o programas nombran los recursos Protección . Como los usuarios/programas se protejen entre ellos (usuario/usuario, programa/programa) Seguridad . Como se proteje el sistema de ataques. Como se mantiene la integridad del sistema y sus recursos. Rendimiento . Como mejorarlo (por qué es lento?) Confiabilidad . Y en caso de falla (programa o hardware), que ocurre?

15. Características/requerimientos de un SO Extensibilidad . Como podemos incorporar nuevas características Comunicación . Como los usuarios se comunican con otros usuarios en diferentes computadores Concurrencia . Como son creadas y controladas las actividades concurrentes/paralelas Escalabilidad . Como reacciona el sistema cuando la carga de trabajo o recursos aumentan Persistencia . Como hacer que los datos perduren en el tiempo.

16. Características/requerimientos de un SO Distribución . Como múltiple computadores interectuan entre sí. Contraloría o Monitoreo . Como se lleva la cuenta del uso de recursos. En sistemas comerciales, como cobrar en función de algunos índices (uso disco, velocidad de conexión, tiempo ejecución, etc)

17. Por qué deben estudiar SO en su carrera? Construir, modificar o administrar un SO o alguno de sus componentes Tomando en cuenta el hardware sobre el cual se ejecutan Mayor discusión más adelante. Entender el desempeño de un SO Comportamiento de SO afecta toda el sistema y usuarios que la usan Constituye un desafío para entender sistemas complejos Midiendo y optimizando desempeño del sistema Aplicación en otras áreas Ingeniería de software (diseño e implementación de aplicaciones), usando recursos y abstracciones disponibles Desarrollo en la construcción de algoritmos Más avanzados Proponiedo cambios en técnicas, algoritmos que maximicen la facilidad de configuración y utilización, uso de recursos, proposiciones en cambio de arquitectura, construcción de compiladores, mejoras en protección y seguridad, etc

18. Evolución de SOs Con el inicio de los computadores digitales Computadores eran compartidos por programadores quienes manipulaban hw y escribían su propio código para acceso a dispositivos y recopilación de resultados (ejecuciones exitosas o fallidas) Posteriormente operador realizada trabajo de cargar y recopilar info en disposivos correspondientes Inicios Inicio de compartición. Bibliotecas y manejadores de dispositivos Sistema operativo era una biblioteca que se linkeaba en un programa. Programa se cargaba completamente en memoria y se ejecutaba. Básicamente el sistema operativo era una biblioteca run-time

19. Evolución de SOs Sistemas batch Sistema operativo estaba almacenado en una porción de la memoria Cargaba trabajo a ejecutar a memoria usando un lector de tarjeta Ejecutaba trabajo e imprimía resultado, contenido de memoria y registros para depuración Cargaba próximo trabajo Tarjetas de control especificaban al computador que hacer. Operadores ordenaban trabajos con requerimientos similares en grupos (batches) y los ejecutaban Con este enfoque la CPU pasaba mucho tiempo ociosa Diferencias entre dispositivos I/O, mecánicos mucho más lento que electrónicos Gap entre velocidad de CPU y dispositivos siempre muy grande

20. Evolución de SOs Spooling (Simultaneous Peripheral Operation On-Line) Con la invensión de Discos más rápidos que lectores de tarjeta y acceso a dispositivos de salida como impresoras Sobreponer lectura/escritura a dispositivos de E/S mientras se ejecuta proceso en CPU Spool : buffer que mantiene info de entrada o salida de un dispositivo Leer de dispositivos de entrada a disco Escribir de dispositivos de salida a disco Usar CPU mientras se lee y escribe a disco Grupo de trabajos pueden ser leídos a disco Sistema operativo elige trabajo a ejecutar (planificación) Sin embargo, CPU aun sigue ociosa por mucho tiempo cuando programa interactua con periférico

21. Evolución de SOs Sistemas Multiprogramados Para aumentar la utilización del sistema Mantiene varios programas cargados en memoria simultáneamente Protección es importante Mientras un programa espera por I/O otro puede estar ejecutándose beneficios por el uso de dispositivos I/O asincrónicos necesita saber cuando el disposito termina interrupciones polling Objetivo es optimizar throughput (#trabajos/tiempo) aunque castiga tiempo de respuesta

22. Evolución de SOs Sistemas de Tiempo Compartido Para soportar uso interactivo En un principio un servidor para varios terminales Cada usuario cree que el sistema esta dedicado a él Tiempo de respuesta es preferido a throughput Sistema operativo divide el tiempo de CPU entre los usuarios Procesos se ejecutan por un pequeño periodo de tiempo o hasta que requieran I/O, entonces el próximo proceso en la lista entra en ejecución Usuarios pueden ejecutar procesos interactivos, como editores, depuradores, etc Primer sistema: MULTICS ( ~ 1960) Protección es importante

23. Sistemas actuales Sistemas de Escritorio Maximización de utilización de CPU no es tan importante como lo es facilidad de uso para el usuario Sistemas gráficos (ventanas, menus, etc) Seguridad es un aspecto importante, sobretodo ahora que la mayoría de los computadores modernos están conectados en red Estaciones de trabajo, son básicamente computadores para ser usados por usuarios, pero poseen hw más poderoso, como buenas tarjetas gráficas y CPUs Actualmente computadores de escritorio están incluyendo la tecnología multicore

24. Sistemas actuales Sistemas Distribuidos Sistemas que facilitan el uso de recursos distribuidos geográficamente Computadores conectados en red (LAN, WAN) Soportan comunicación entre trabajos (procesos) Permite la compartición de recursos (hardware, software) balance de carga, autentificación y control de acceso Permite algo de paralelismo, pero no es el objetivo principal Algunos modelos que se usan en el desarrollo de aplicaciones distribuidas Sistemas Peer to Peer Servidores y clientes. No hay distinción entre el cliente y el servidor, ambos actúan como los dos. Se conocen como peers Sistemas Cliente/servidor Clientes envian requerimientos que servidores procesan y responden a clientes. SO distribuidos Proporcionan ilusión que existe un solo SO que controla recursos distribuidos en red.

25. Sistemas actuales Sistemas basados en clusters Compuestos por dos o más sistemas individuales acoplados Definición general : computadores comparten almacenamiento y están conectados mediante una LAN con alto ancho de banda Tipos Asimétricos: uno es el principal y otro monitorea principal y pasa a ser el principal en caso de falla Simétricos: dos o más computadores ejecutan las aplicaciones y se monitorean entre ellas Sistemas basados en Multiprocesadores Mejoran productividad, confiabilidad Comúnmente utilizados en aplicaciones científicas Computadores paralelos SMPs (Symmetric Multi-Processors) MPPs (Massively Parallel Processors) NOWs (Networks Of Workstations) Grid Computacional Incluye clusters y almacemamiento distribuido geográficamente

26. Sistemas actuales Sistemas incrustados CPUs baratas presentes en muchos artículos Celulares, PDAs, juegos, iPods Sistemas Handheld PDAs (Personal Digital Assistants) Limitados por tamaño CPU lenta comparada con PC si no requeriría una batería grande Pequeña memoria La mayoría no implementan memoria virtual Usan tecnología como BlueTooth e infrarojo para comunicarse con otros PDAs y PCs Comunicación inalámbrica ahora también esta accesible para PDAs

27. Sistemas actuales Sistemas de tiempo real Especialmente diseñados con restricciones de tiempo importantes Deben responder a eventos que ocurren con alta precisión de tiempo Sistemas computacionales de emergencia Control de tráfico aéreo Se agrupan de acuerdo a los requerimientos en tiempos de respuesta Tipos Duros: Con restricciones de tiempo importantes. Algunas características avanzadas de SOs no se encuentran, por ejemplo, memoria virtual normalmente no es implementada. Se usan en sistemas de control industrial y robótica. Suaves: Menos restrictivo sólo requiere que procesos no esperen indifinidamente y tengan prioridad sobre otros.

28. Tendencias en SOs Mejoras tecnológicas avanzan rápidamente Código de SOs tiende a cambiar mucho más lentamente que Hardware Construcción de sistemas se extiende mucho más allá que el SO

29. Citas famosas “ I think there is a world market for maybe five computers ” Thomas Watson, IBM, 1943 “ There is no reason for any individual to have a computer in their home ” Ken Olson, Digital, 1977 “ 640K ought to be enough for anybody ” Bill Gates, 1981

30. Citas famosas Scientists from RAND Corporation have created this model to illustrate how a &quot;home computer&quot; could look in the year 2004. However the needed technology will not be economically feasible for the average home. Also the scientists readily admit that the computer will require not yet invented technology to actually work, but 50 years from now scientific progress is expected to solve these problems. With teletype interface and the Fortran language, the computer will be easy to use and only

31. Tendencia en Desempeño de CPU Desempeño de CPU paró de doblarse cada 18 meses en el 2002 Fuente: David Patterson

32. Ley de Moore Continúa mejorando la cantidad de transistores por chip

33. Por qué desempeño crece a menor pendiente? Según la ley de Moore, es posible conseguir más transistores por chip Problema con CPUs Diseño de chips se está haciendo más complejo Tiempos de comunicación se hacen más importantes Ruido en los circuitos pasa a ser un factor importante Problemas para seguir aumentando la velocidad del reloj (uso de energía y disipación de calor) Tecnologías multicore permiten aumentar desempeño a costo de velocidad de reloj

34. Qué ofrece las empresa ahora?

35. Qué pasa con la Educación en Computación? “ Given this sea change, how much of the curriculum a nd what fraction of the CS faculty i s oblivious to concurrency? How many algorithms, data structures, languages, compilers, debuggers, operating systems, books, and lectures must change to match the transformation in underlying technology if they are to remain relevant in the 21st century?” David Patterson -- Computer Science Education in the 21st Century Aparece en Communications of the ACM : Documento completo aparece en http://www.inf.udec.cl/~chernand/sc/2007-1/links/p27-patterson.h

36. Desafío en computación paralela Cómo podemos obtener una aceleración de N en un multiprocesador de N procesadores? Software debe ser paralelizable Métricas para medir aceleración? Latencia: Tiempo para completar una tarea (tambien puede referirse a tiempo de respuesta) Throghput (productividad): Razón a la cual tareas son completadas

37. Un ejemplo de la vida diaria Problema: Producir cachorros Se puede paralelizar el problema? Latencia : No se puede mejorar Cada perrita no puede parir en una semana Latencia 2 meses Productividad : Si 10 perritas pueden producir un cachorro por mes Productividad : 10/mes

38. Un ejemplo del área Qué será más importante para una empresa que vende por internet Ser capaz de manejar más clientes? Hacer que cada transacción se realice más rápido?

39. Paralelismo en teoría Ley de Amdahl: Predice desempeño total en base a una mejora local. En una máquina paralela mejora dada por el número de CPUs N : número de procesadores F : Factor que no se puede mejorar, en este caso fracción de computación secuencial Que significa F = 0 ??? F + (1 - F) / N 1 S =

40. Ejemplo: Ley de Amdahl Programa ocupa el 70% del tiempo ejecutando código fácilmente paralelizable, y un 30% en código completamente secuencial (no paralelizable). ¿Cúal es la aceleración al ejecutar este programa en un computador paralelo con 2, 3, 4 y 5 CPUs? ¿Cuál es la máxima aceleración posible de alcanzar a través de paralelismo? 3.3 2.3 2.1 1.85 1.54 S inf. 5 4 3 2 N

41. Evaluación en la práctica Predecir desempeño es difícil porque hay muchas formas de paralelismo Múltiple procesadores SMP (Symmetric multiprocessors) Procesadores multicore Procesadores multithreaded Clusters Ejecución de software permite evaluar experimentalmente

42. Soporte de la arquitectura para el Sistema Operativo En parte el sistema operativo está sujeto a la arquitectura que lo soporta Lista de instrucciones de la CPU (s) Controladores como MMU y DMA Arquitectura construida para soportar SO Reloj Intrucción Test and Set (para sincronización atómica) Protección de memoria Operaciones de control I/O Interrupciones y excepciones Diferencia entre ellas?

43. Protección en SO Objetivos Evitar que sistema se caiga producto de una aplicación con errores Evitar que una aplicación/usuario maliciosa(o) tome el control del sistema (seguridad) Proteger datos de usuarios de usuarios y aplicaciones no confiables

44. Ideas utilizadas en protección Apropiación: entregar a usuarios y aplicaciones lo que puede quitar Tiempo CPU (uso de reloj de sistema) Interposición: Llevar cuenta de lo que aplicación está usando. En cada acceso verificar acceso es legal Estructuras de datos usadas en SO para ello Modo protegido/no protegido Aplicaciones usuarios ejecutadas en modo no protegido SO ejecutadas en modo protegido Operaciones de seguridad sólo permitidas en modo protegido Como sabe el procesador que una instrucción protegida debe ser ejecutada? Arquitectura debe soportar modo kernel y modo usuario

45. Intrucciones Protegidas Algunas instrucciones son de uso exclusivo del SO Directamente accesar dispositivos I/O (discos, tarjetas de red) Manipulación de administración de memoria punteros a tablas de página, carga a TLBs, etc Manipulación de bits de modo nivel de interrupción de prioridades Cruce de modo usuario a kernel Código usuario debe llamar un procedimiento del SO SO define una secuencia de llamados a sistema

46. Arquitectura y SO Frontera entre aplicaciones usuario y sistema (kernel) Permite a SO ejecutar instrucciones protegidas Aplicaciones entran a modo kernel ejecutando llamadas a sistema

47. Llamadas a sistema Transición de modo usuario a modo kernel Hay una intrucción de llamado a sistema que Causa una excepción (a través de una interrupción software) que direcciona a un handler del kernel Pasa un parámetro indicando el llamado a sistema que debe invocar Guarda el estado del que llama (caller) (registros, bit de modo) para ser restaurados al terminar SO verifica los parámetros (punteros) del que llama (caller) Debe retornar al modo usuario cuando termine

48. Ilustración de la transición de modo usuario a kernel Modo usuario Modo kernel Applicación usuario (llamado a sistema req) Llamado a sistema Almacena estado app Manejador llamadas sistema Ejecuta Llamada sistema Restablece estado app, retorna modo usuario continua ejecución

49. Preguntas Qué pasaría si el SO no salvara el estado de las aplicaciones antes de ejecutar un llamado a sistema? Por qué el sistema debe verificar parámetros en los llamados a sistema? Qué pasaría si una aplicación de usuario modificara el vector de interrupciones del sistema? Cómo el sistema evita que una aplicación lea directamente del disco en lugar de pasar por las verificaciones de control de acceso del sistema de archivos?

51. Protección de Memoria Problema1. SO debe protejer programas unos de otros. Programas de diferentes usuarios. Malintencionados o no. Solución: Memoria Virtual, donde cada aplicación tiene su propio espacio de direccionamiento, el cual se mapea a memoria física a medida que la aplicación lo requiera Problema2. Kernel debe proteger sus programas y datos Solución: Dividir el espacio de direccionamiento en la mitad La que corresponde al kernel requiere modo de acceso priviligiado TLBs y registro para puntero a tabla de páginas proporcionados por HW

52. Espacio de direccionamiento en linux

53. Operación de SO Sistema computacional compuesto por CPU y controladores de dispositivos incluyendo memoria. Cada tipo de dispositivo tiene asociado un controlador. Controladores funcionan en base a eventos. Antes de SO. Programa inicial para empezar (bootstrap program) (en ROM). Inicializa todos los aspectos del sistema, Registros de CPU, controladores de dispositivos, contenido de memoria Debe cargar SO en memoria para ejecutarlo. SO empieza ejecución con algún programa como init (Unix) y luego espera por la ocurrencia de eventos.

54. Operación de SO Una vez que el kernel esta en ejecución cualquier entrada al kernel ocurre mediante un evento. Eventos detienen ejecución actual cambia modo a modo kernel. SO llama a manejador de eventos Kernel define manejadores para cada tipo de evento La arquitectura define los tipos (ejemplos, reloj, interrupciones I/O) Cuando el procesador recibe un evento de un tipo transfiere el control al manejador de eventos en el SO manejador salva estado de proceso actual manejador llama a la rutina que atiende evento manejador restaura estado del proceso

55. Interrupciones y Excepciones Eventos en el sistema ocurren a través de interrupciones y excepciones Excepciones. Causadas por ejecución de intrucciones de SW x86 assembly: instrucción “int” falta de página: intento de escribir en una página con permisos de lectura solamente Interrupciones. Causadas por dispositivos HW reloj (ha pasado el tiempo programado) dispositivo termina con I/O (click on mouse, o termino copia de bloque a disco, etc) llega un paquete de red

56. Estructura I/O Secuencia en una operación de I/O SO ejecuta intrucciones especiales de I/O o I/O mapeada a memoria CPU carga datos en registros de controlador de dispositivo Controlador de dispositivo examina datos y determina que acción tomar 2 posibilidades de acción una vez que empieza I/O sincrónica (espera término I/O) asincrónica (control transferido a proceso de usuario mientras I/O termina) I/O asincrónica (más eficiente uso de recursos) dispositivo realiza una operación asincrónica a la CPU

57. Estructura I/O Dispositivo envía una interrupción a través del bus cuando termina En memoria hay una tabla que contiene la lista de direcciones de kernel de rutinas para manejar varios tipos de interrupciones CPU se cambia a la dirección indicada por el vector mediante la señal de interrupción

58. Relojes Como controla el SO que un proceso se acapare la CPU? Reloj que genera una interrupción periódicamente Antes de ejecutar un proceso, el SO carga el reloj con un tiempo para que luego de expirado se genere una interrupción (quantum) Cuando el quantum expira el control es transferido al SO para la ejecución del siguiente proceso (planificación de procesos)

59. Sincronización Interrupciones pueden ocurrir en cualquier momento proceso a ejecutarse puede interferir con proceso que esta siendo ejecutado SO debe poder sincronizar procesos concurrentes sanamente Sincronización debe permitir la ejecución de set de instrucciones que lean-modifiquen-escriban atomicamente (sin ser interrumpida) una forma: desabilitando interrumpciones (arquitectura debe soportarlo). No aceptable en un sistema multiprocesador otra forma: teniendo una intrucción atómica special que conste de estas tres operaciones (test-and-set)

60. Preguntas Qué pasaría si el SO no salvara el estado de las aplicaciones antes de ejecutar un llamado a sistema? Por qué el sistema debe verificar parámetros en los llamados a sistema? Qué pasaría si una aplicación de usuario modificara el vector de interrupciones del sistema? Cómo el sistema evita que una aplicación lea directamente del disco en lugar de pasar por las verificaciones de control de acceso del sistema de archivos?