Sistemas Operativos
Temario
Unidad 1. Introducción a los sistemas operativos
1.1 Definición y concepto sistemas operativos.
1.2 Funciones y características sistemas operativos.
1.3 Evolución histórica sistemas operativos.
1.4 Clasificación sistemas operativos.
1.5 Estructura: niveles o estratos de diseño.
1.6 Núcleo.
Unidad 2. Administración de Procesos y del procesador.
2.1 Concepto de proceso.
2.2 Estados y transiciones de los procesos
2.3 Procesos ligeros: Hilos o hebras.
2.4 Concurrencia y secuencialidad.
2.5 Niveles objetivos y criterios de planificación.
2.6 Técnicas de administración del planificador.
Introducción a los sistemas operativos
1
Abstracciones
Espacio de direcciones
Memoria utilizable por un proceso.
Unidad de protección de memoria.
Habitualmente formado por 3 componentes:
1 código: .text
2 datos: .data, .bss y heap
3 pila: stack
variables locales
marcos de procedimientos
Tamaño:
código: tamaño fijo
datos: pueden crecer hacia arriba
pila: pueden crecer hacia abajo
En sistemas operativos, un hilo de ejecución, hebra o subproceso es la unidad de procesamiento más pequeña que puede ser planificada por un sistema operativo.
La creación de un nuevo hilo es una característica que permite a una aplicación realizar varias tareas a la vez (concurrentemente). Los distintos hilos de ejecución comparten una serie de recursos tales como el espacio de memoria, los archivos abiertos, situación de autenticación, etc. Esta técnica permite simplificar el diseño de una aplicación que debe llevar a cabo distintas funciones simultáneamente.
Un hilo es simplemente una tarea que puede ser ejecutada al mismo tiempo con otra tarea.
Los hilos de ejecución que comparten los mismos recursos, sumados a estos recursos, son en conjunto conocidos como un proceso. El hecho de que los hilos de ejecución de un mismo proceso compartan los recursos hace que cualquiera de estos hilos pueda modificar éstos. Cuando un hilo modifica un dato en la memoria, los otros hilos acceden a ese dato modificado inmediatamente.
Lo que es propio de cada hilo es el contador de programa, la pila de ejecución y el estado de la CPU (incluyendo el valor de los registros).
El proceso sigue en ejecución mientras al menos uno de sus hilos de ejecución siga activo. Cuando el proceso finaliza, todos sus hilos de ejecución también han terminado. Asimismo en el momento en el que todos los hilos de ejecución finalizan, el proceso no existe más y todos sus recursos son liberados.
La comunicación entre procesos (comúnmente IPC, del inglés Inter-Process Communication) es una función básica de los sistemas operativos. Los procesos pueden comunicarse entre sí a través de compartir espacios de memoria, ya sean variables compartidas o buffers, o a través de las herramientas provistas por las rutinas de IPC. La IPC provee un mecanismo que permite a los procesos comunicarse y sincronizarse entre sí, normalmente a través de un sistema de bajo nivel de paso de mensajes que ofrece la red subyacente.
La comunicación se establece siguiendo una serie de reglas (protocolos de comunicación). Los protocolos desarrollados para internet son los mayormente usados: IP (capa de red), protocolo de control de transmisión (capa de transporte) y protocolo de transferencia de archivos , protocolo de transferencia de hipertexto (capa de aplicación).Los procesos pueden estar ejecutándose en una o más computadoras conectadas a una red. Las técnicas de IPC están divididas dentro de métodos para: paso de mensajes, sincronización, memoria compartida y llamadas de procedimientos remotos (RPC). El método de IPC usado puede variar dependiendo del ancho de banda y latencia (el tiempo desde el pedido de información y el comienzo del envío de la misma) de la comunicación entre procesos, y del tipo de datos que están siendo comunicados.
Concurrencia y paralelismo
Gestión de memoria
Memoria virtual
Planificación/gestión de recursos
Gestión de E/S
Ficheros
Interacción de los componentes del sistema
Interfaz de programación de aplicaciones (API)
Paso de parámetros
Gestión de procesos
Gestión de ficheros
Gestión de directorios
Definición y concepto sistemas operativos.
La mayoría de los usuarios de computadora han
tenido algo de experiencia con un sistema operativo, pero no es fácil precisar
con exactitud qué es un sistema operativo. Parte del problema consiste en que
el sistema operativo realiza dos funciones que básicamente no están
relacionadas entre sí y, dependiendo de a quién le preguntemos, por lo general
se nos habla principalmente de una función o de la otra. Veamos ahora las dos.
El sistema operativo como máquina extendida
Como ya dijimos, la arquitectura (conjunto de instrucciones, organización de
memoria, E/S y estructura de buses) de la mayor parte de las computadoras en el
nivel de lenguaje de máquina es primitiva y difícil de programar, sobre todo
para entrada/salida. A fin de hacer más concreto este punto, veamos brevemente
cómo se realiza la E/S de disco flexible usando el chip controlador NEC PD765
(o su equivalente), utilizado por la mayor parte de las computadoras
personales. (En todo este libro usaremos indistintamente los términos “disco
flexible” y “disquete”.)
El PD765 tiene 16 comandos, cada uno de los
cuales se especifica cargando entre 1 y 9 bytes en un registro de dispositivo.
Estos comandos sirven para leer y escribir datos, mover el brazo del disco y
formatear pistas, así como para inicializar, detectar, restablecer y recalibrar
el controlador y las unidades de disco. Los comandos más básicos son READ y
WRITE, cada uno de los cuales requiere 13 parámetros empacados en 9
bytes.
Estos parámetros especifican cosas tales como
la dirección del bloque de disco que se va a leer, el número de sectores por
pista, el modo de grabación empleado en el medio físico, el espaciado de la
brecha entre sectores y qué hacer con una marca de “dirección de datos
eliminada”. Si usted no entiende a qué nos referimos, no se preocupe; de eso se
trata precisamente: es algo muy esotérico.
Cuando se completa la operación, el chip
controlador devuelve 23 campos de estado y error empacados en 7 bytes. Por si
esto no fuera suficiente, el programador del disco flexible también debe tener
presente en todo momento si el motor está encendido o apagado.
Si el motor está apagado, debe encenderse (con
un retardo de arranque largo) antes de que puedan leerse o escribirse datos.
Empero, el motor no puede dejarse encendido demasiado tiempo, pues el disco
flexible se desgastaría. Por tanto, el programador debe encontrar un equilibrio
entre los retardos de arranque largos y el desgaste de los discos flexibles (y
la pérdida de los datos que contienen).
Sin entrar en los verdaderos detalles, debe quedar claro que
el programador ordinario seguramente no quiere intervenir de manera demasiado
íntima en la programación de los discos flexibles (o de los duros, que son
igualmente complejos, y muy distintos). En vez de ello, lo que el programador
quiere es manejar una abstracción sencilla, de alto nivel. En el caso de los
discos, una abstracción típica sería que el disco contiene una colección de
archivos con nombre. Cada archivo puede abrirse para lectura o escritura,
leerse o escribirse, y por último cerrarse. Los detalles de si la grabación
debe usar o no modulación de frecuencia modificada y cuál es la situación
actual del motor no deberán aparecer en la abstracción presentada al usuario.
El programa que oculta la verdad acerca del hardware y presenta al programador
una vista sencilla y bonita de archivos con nombre que pueden leerse y
escribirse es, por supuesto, el sistema operativo. Así como el sistema
operativo aísla al programador del hardware del disco y presenta una interfaz
sencilla orientada a archivos, también oculta muchos asuntos desagradables
referentes a interrupciones, temporizadores, administración de memoria y otras
funciones de bajo nivel. En cada caso, la abstracción que el sistema operativo
ofrece es más sencilla y fácil de usar que el hardware subyacente. En esta
vista, la función del sistema operativo es presentar al usuario el equivalente
de una máquina extendida o máquina virtual que es más fácil de programar que el
hardware subyacente.
El sistema operativo como administrador de recursos
El concepto del sistema operativo como algo cuya función
primordial es ofrecer a los usuarios una Interfaz cómoda es una visión
descendente. Una visión ascendente alternativa postula que el sistema operativo
está ahí para administrar todos los componentes de un sistema complejo. Las
computadoras modernas constan de procesadores, memorias, temporizadores,
discos, ratones, interfaces con redes, impresoras láser y una gran variedad de
otros dispositivos. En la visión alternativa, la misión del sistema operativo
es asegurar un reparto ordenado y controlado de los procesadores, memorias y
dispositivos de E/S entre los diferentes programas que compiten por ellos.
Imagine lo que sucedería si tres programas que se ejecutan
en alguna computadora trataran de imprimir sus salidas simultáneamente en la
misma impresora. Las primeras líneas del listado podrían ser del programa 1, las
siguientes del programa 2, luego algunas del programa 3, y así sucesivamente.
El resultado sería un caos. El sistema operativo puede poner orden en el caos
potencial almacenando temporalmente en el disco todas las salidas destinadas
para la impresora. Cuando un programa haya terminado, el sistema operativo podrá
copiar su salida del archivo de disco donde se almacenó a la impresora,
mientras que el otro programa puede continuar generando salidas, ajeno al hecho
de que dichas salidas no están yendo directamente a la impresora (todavía).
Cuando una computadora (o red) tiene múltiples usuarios, la
necesidad de administrar y proteger la memoria, los dispositivos de E/S y demás
recursos es aún mayor, ya que de otra manera los usuarios podrían interferirse.
Además, es frecuente que los usuarios tengan que compartir no sólo hardware,
sino también información (archivos, bases de datos, etc.). En pocas palabras,
esta es visión del sistema operativo sostiene que su tarea primordial es seguir
la pista de quién está usando cuál recurso, atender solicitudes de recursos,
contabilizar la utilización y mediar entre solicitudes en conflicto
provenientes de diferentes programas y usuarios.
Ver mejor: https://www.examtime.com/es-ES/p/2288332
Funciones y características sistemas operativos.
En general, se puede decir que un Sistema Operativo tiene
las siguientes características:
Conveniencia. Un Sistema Operativo hace más conveniente el
uso de una computadora.
Eficiencia. Un Sistema Operativo permite que los recursos de
la computadora se usen de la manera más eficiente posible.
Habilidad para evolucionar. Un Sistema Operativo deberá
construirse de manera que permita el desarrollo, prueba o introducción efectiva
de nuevas funciones del sistema sin interferir con el servicio.
Encargado de administrar el hardware. El Sistema Operativo
se encarga de manejar de una mejor manera los recursos de la computadora en
cuanto a hardware se refiere, esto es, asignar a cada proceso una parte del
procesador para poder compartir los recursos.
Relacionar dispositivos (gestionar a traves del kernel). El
Sistema Operativo se debe encargar de comunicar a los dispositivos periféricos,
cuando el usuario así lo requiera.
Manejar las comunicaciones en red. El Sistema Operativo
permite al usuario manejar con alta facilidad todo lo referente a la
instalación y uso de las redes de computadoras.
Procesamiento por bytes de flujo a través del bus de datos.
Facilitar las entradas y salidas. Un Sistema Operativo debe
hacerle fácil al usuario el acceso y manejo de los dispositivos de Entrada/Salida
de la computadora.
Técnicas de recuperación de errores.
Evita que otros usuarios interfieran. El Sistema Operativo
evita que los usuarios se bloqueen entre ellos, informándoles si esa aplicación
está siendo ocupada por otro usuario.
Generación de estadísticas.
Permite que se puedan compartir el hardware y los datos
entre los usuarios.
El software de aplicación son programas que se utilizan para
diseñar, tal como el procesador de palabras, lenguajes de programación, hojas
de cálculo, etc.
El software de base sirve para interactuar el usuario con la
máquina, son un conjunto de programas que facilitan el ambiente plataforma, y
permite el diseño del mismo.
El Software de base está compuesto por :
Cargadores.
Compiladores.
Ensambladores.
Evolución histórica sistemas operativos
Los sistemas operativos han estado evolucionando durante
muchos años. En las siguientes secciones examinaremos brevemente este
desarrollo. Dado que, históricamente, los sistemas operativos han estado de
manera muy estrecha vinculados con la arquitectura de las computadoras en las
que se ejecutan, estudiaremos las sucesivas generaciones de computadoras para
ver qué clase de sistemas operativos usaban. Esta correspondencia entre las
generaciones de sistemas operativos y de computadoras es algo burda, pero
establece un poco de estructura que de otra forma sería inexistente.
La primera computadora digital verdadera fue diseñada por el
matemático inglés Charles Babbage (1792-1871). Aunque Babbage invirtió la mayor
parte de su vida y su fortuna tratando de construir su “máquina analítica”,
nunca logró que funcionara correctamente porque era totalmente mecánica, y la
tecnología de su época no podía producir las ruedas, engranes y levas con la
elevada precisión que él requería. Huelga decir que la máquina analítica no
contaba con un sistema operativo.
Como acotación histórica interesante, diremos que Babbage se
dio cuenta de que necesitaría software para su máquina analítica, así que
contrató a una joven mujer, Ada Lovelace, hija del famoso poeta británico,
Lord Byron, como la primera programadora de la historia. El
lenguaje de programación Ada® recibió su
La primera generación (1945-55):
Tubos de vacío y tableros
de conmutación
Después del fracaso de los trabajos de Babbage, fueron pocos
los avances que se lograron en la construcción de computadoras digitales hasta
la Segunda Guerra Mundial. A mediados de la década de 1940, Howard Aiken en
Harvard, John von Neumann en el Institute for Advanced Study en Princeton, J. Presper
Eckert y William Mauchley en la University of Pennsylvania y Konrad Zuse en
Alemania, entre otros, lograron construir máquinas calculadoras usando tubos de
vacío. Estas máquinas eran enormes, y ocupaban cuartos enteros con decenas de
miles de tubos de vacío, pero eran mucho más lentas que incluso las
computadoras personales más baratas de la actualidad.
En esos primeros días, un solo grupo de personas diseñaba,
construía, programaba, operaba y mantenía a cada máquina. Toda la programación
se realizaba en lenguaje de máquina absoluto, a menudo alambrando tableros de
conmutación para controlar las funciones básicas de la máquina. No existían los
lenguajes de programación (ni siquiera los de ensamblador). Nadie había oído
hablar de los sistemas operativos. La forma de operación usual consistía en que
el programador se anotaba para recibir un bloque de tiempo en la hoja de
reservaciones colgada en la pared, luego bajaba al cuarto de la máquina,
insertaba su tablero de conmutación en la computadora, y pasaba las siguientes
horas con la esperanza de que ninguno de los cerca de 20000 tubos de vacío se
quemara durante la sesión. Prácticamente todos los problemas eran cálculos
numéricos directos, como la producción de tablas de senos y cosenos.
La segunda generación (1955-65):
Transistores y sistemas por
lote, La introducción del transistor a mediados de la década de
1950 alteró el panorama radicalmente. Las computadoras se hicieron lo bastante
confiables como para poderse fabricar y vender a clientes comerciales con la
expectativa de que seguirían funcionando el tiempo suficiente para realizar
algo de trabajo útil. Por primera vez, había una separación clara entre
diseñadores, constructores, operadores, programadores y personal de
mantenimiento.
Estas máquinas se encerraban en cuartos de computadora con
acondicionamiento de aire especial, con equipos de operadores profesionales
para operarlas. Sólo las grandes empresas, o las principales dependencias del
gobierno o universidades, podían solventar el costo de muchos millones de
dólares. Para ejecutar un trabajo (es decir, un programa o serie de programas),
un programador escribía primero el programa en papel (en FORTRAN o ensamblador)
y luego lo perforaba en tarjetas. Después, llevaba el grupo de tarjetas al
cuarto de entrada y lo entregaba a uno de los operadores.
Cuando la computadora terminaba el trabajo que estaba
ejecutando en ese momento, un operador acudía a la impresora, separaba la
salida impresa y la llevaba al cuarto de salida donde el programador podía recogerla
después. Luego, el operador tomaba uno de los grupos de tarjetas traídos del
cuarto de entrada y lo introducía en el lector. Si se requería el compilador de
FORTRAN, el operador tenía que traerlo de un archivero e introducirlo en el
lector. Gran parte del tiempo de computadora se desperdiciaba mientras los operadores
iban de un lugar a otro, en el cuarto de la máquina.
Dado el alto costo del equipo, no es sorprendente que la
gente pronto buscara formas de reducir el desperdicio de tiempo. La solución
que se adoptó generalmente fue el sistema por lotes. El principio de este modo
de operación consistía en juntar una serie de trabajos en el cuarto de entrada,
leerlos y grabarlos en una cinta magnética usando una computadora pequeña y (relativamente)
económica, como una IBM
Después de cerca de una hora de reunir un lote de trabajos,
la cinta se rebobinaba y se llevaba al cuarto de la máquina, donde se montaba
en una unidad de cinta. El operador cargaba entonces un programa especial (el
antepasado del sistema operativo actual), que leía el primer trabajo de la cinta
y lo ejecutaba. La salida se escribía en una segunda cinta, en lugar de
imprimirse. Cada vez que terminaba un trabajo, el sistema operativo leía
automáticamente el siguiente trabajo de la cinta y comenzaba a ejecutarlo. Una
vez que estaba listo todo el lote, el operador desmontaba las cintas de entrada
y salida, montaba la cinta de entrada del siguiente lote, y llevaba la cinta de
salida a una 1401 para la impresión fuera de línea (o sea, no conectada a la
computadora principal).
El trabajo comenzaba con una tarjeta
$JOB, que especificaba el tiempo de ejecución máximo en
minutos, el número de cuenta al que se debía cobrar el trabajo, y el nombre del
programador. Luego venía una tarjeta $FORTRAN, que ordenaba al sistema
operativo leer el compilador de FORTRAN de la cinta de sistema. Esta tarjeta iba
seguida del programa por compilar y por una tarjeta $LOAD, que ordenaba al
sistema operativo cargar el programa objeto recién compilado. (Los programas
compilados a menudo se escribían en cintas temporales y tenían que cargarse
explícitamente.) Luego venía la tarjeta $RUN, que ordenaba al sistema operativo
ejecutar el programa con los datos que le seguían. Por último, la tarjeta $END
marcaba el final del trabajo. Estas tarjetas de control primitivas eran los
precursores de los lenguajes de control de trabajos e intérpretes de comandos
modernos.
Las computadoras grandes de la segunda generación se usaban
primordialmente para cálculos científicos y de ingeniería, como la resolución
de ecuaciones diferenciales parciales. Estas máquinas generalmente se programaban
en FORTRAN y lenguaje ensamblador. Los sistemas operativos típicos eran FMS (el
Fortran Monitor System) e IBSYS, el sistema operativo de IBM para la 7094.
La tercera generación (1965-1980):
Circuitos integrados y
multiprogramación A principios de la década de 1960, la mayoría de los
fabricantes de computadoras tenían dos líneas de producto distintas y totalmente
incompatibles. Por un lado estaban las computadoras científicas a gran escala,
orientadas hacia las palabras, como la 7094, que se usaban para cálculos
numéricos en ciencias e ingeniería. Por el otro, estaban las computadoras
comerciales orientadas hacia los caracteres, como la 1401, que los bancos y las
compañías de seguros utilizaban ampliamente para ordenar e imprimir desde cinta.
La creación y mantenimiento de dos líneas de producto totalmente distintas era
una situación costosa para los fabricantes. Además, muchos clientes de
computadoras nuevas necesitaban inicialmente una máquina pequeña que más
adelante les resultaba insuficiente, de modo que querían una máquina más grande
que ejecutara todos sus viejos programas, pero más rápidamente. IBM trató de
resolver simultáneamente ambos problemas introduciendo la System/360. La 360
era una serie de máquinas de software compatible que iban desde tamaños
comparables a la 1401 hasta computadoras mucho más potentes que la 7094. Las
máquinas diferían sólo en el precio y el rendimiento (memoria máxima, velocidad
del procesador, número de dispositivos de E/S permitidos, etc.). Puesto que
todas las máquinas tenían la misma arquitectura y conjunto de instrucciones, los
programas escritos para una máquina podían ejecutarse en todas las demás, al
menos en teoría. Además, la 360 estaba diseñada para manejar computación tanto
científica como comercial. Así, una sola familia de máquinas podía satisfacer
las necesidades de todos los clientes. En años subsecuentes IBM produjo sucesoras
comparables a la línea 360, usando tecnología más moderna, conocidas como
series 370, 4300, 3080 y 3090. La 360 fue la primera línea importante de
computadoras en usar (a pequeña escala) circuitos integrados (IC), ofreciendo
así una ventaja de precio/rendimiento considerable respecto a las máquinas de
la segunda generación, que se armaban con transistores individuales. Esta línea
fue un éxito inmediato, y la idea de una familia de computadoras compatibles
pronto fue adoptada por todos los demás fabricantes importantes. Los
descendientes de estas máquinas todavía se emplean en uno que otro centro de
cómputo en la actualidad, pero su uso está en rápido declive. La gran ventaja
de la idea de “una familia” fue también su gran debilidad. La intención era que
todo el software, incluido el sistema operativo, funcionara en todos los
modelos. El software tenía que funcionar en sistemas pequeños, que en muchos
casos simplemente sustituían a la 1401 para copiar tarjetas en cinta, y en
sistemas muy grandes, que con frecuencia sustituían a las 7094 para realizar pronósticos
del tiempo y otros trabajos de computación pesada. El software tenía que ser bueno
en sistemas con pocos y con muchos periféricos; tenía que funcionar en entornos
comerciales y. científicos y, sobre todo, tenía que ser eficiente para todos
estos usos distintos. Era imposible que IBM (o alguien más) pudiera escribir un
programa que satisficiera todos esos requisitos opuestos. El resultado fue un
sistema operativo enorme, extraordinariamente complejo, tal vez dos o tres órdenes
de magnitud mayor que FMS. Este sistema consistía en millones de líneas de
lenguaje ensamblador escrito por miles de programadores, y contenía miles y
miles de errores, requiriéndose un flujo continuo de nuevas versiones en un
intento por corregirlos. Cada versión nueva corregía algunos errores e introducía
otros nuevos, de modo que es probable que el número de errores se mantuviera
constante con el tiempo. Uno de los diseñadores de OS/360, Fred Brooks,
escribió después un ingenioso e incisivo libro (Brooks, 1975) describiendo sus
experiencias con el OS/360. Aunque sería imposible resumir aquí ese libro,
baste con decir que la portada muestra una manada de bestias prehistóricas
atascadas en un foso de brea. La portada del libro de Silberschatz y Galvin
(1994) es una alusión similar. A pesar de su enorme tamaño y de sus problemas,
OS/360 y los sistemas operativos de tercera generación parecidos a él
producidos por otros fabricantes de computadoras lograron satisfacer a sus
clientes en un grado razonable, y también popularizaron varias técnicas clave
que no existían en los sistemas operativos de la segunda generación. Tal vez la
más importante de ellas haya sido la multiprogramación. En la 7094, cuando el
trabajo actual hacía una pausa para esperar que se completara una operación de
cinta u otra operación de E/S, la CPU simplemente permanecía ociosa hasta que
la E/S terminaba. En los cálculos científicos, con gran uso de CPU, la E/S es
poco frecuente, así que el tiempo desperdiciado no es significativo. En el
procesamiento de datos comerciales, el tiempo de espera por E/S puede ser el 80
o 90% del tiempo total, de modo que algo debía hacerse para evitar que la CPU
estuviera ociosa tanto tiempo.
La solución a la que se llegó fue dividir la memoria en
varias secciones, con un trabajo distinto en cada partición, como se muestra en
la Fig. 1-4. Mientras un trabajo estaba esperando que terminara su E/S, otro podía
estar usando la CPU. Si se podían tener en la memoria principal suficientes
trabajos a la vez, la CPU podía mantenerse ocupada casi todo el tiempo. Tener
múltiples trabajos en la memoria a la vez requiere hardware especial para
proteger cada trabajo contra espionaje por parte de los demás, pero la 360 y
otros sistemas de tercera generación estaban equipados con este hardware. Otra
característica importante presente en los sistemas operativos de la tercera
generación era la capacidad de leer trabajos de las tarjetas al disco tan
pronto como se llevaban al cuarto de computadoras. Luego, cada vez que un
trabajo terminaba su ejecución, el sistema operativo podía cargar uno nuevo del
disco en la partición que había quedado vacía y ejecutarlo. Esta técnica se
llama spooling (de “operación simultánea de periféricos en línea”) y también se
usaba para la salida. Con spooling, las 1401 ya no eran necesarias, y desapareció
una buena parte del transporte de cintas. Aunque los sistemas operativos de la
tercera generación se adaptaban bien a cálculos científicos extensos y sesiones
masivas de procesamiento de datos comerciales, seguían siendo básicamente
sistemas por lotes. Muchos programadores añoraban los días de la primera
generación cuando tenían toda la máquina para ellos solos durante unas cuantas
horas, lo que les permitía depurar sus programas rápidamente. Con los sistemas
de la tercera generación, el tiempo entre la presentación de un trabajo y la
obtención de las salidas a menudo era de varias horas, y una sola coma mal
colocada podía causar el fracaso de una compilación y que el programador
desperdiciara medio día. Este deseo de respuesta rápida preparó el camino para
el tiempo compartido, una variante de la multiprogramación, en la que cada
usuario tiene una terminal en línea. En un sistema de tiempo compartido, si 20
usuarios ingresan en el sistema y 17 de ellos están pensando, hablando o
tomando café, la CPU puede asignarse por turno a los tres trabajos que
requieren servicio. Puesto que las personas que están depurando programas
usualmente emiten comandos cortos (p. ej., compilar un procedimiento de cinco páginas)
en vez de largos (p. ej., ordenar un archivo de un millón de registros), la
computadora puede proporcionar servicio rápido interactivo a varios usuarios y
tal vez también trabajar con trabajos de lote grandes en segundo plano cuando
la CPU está ociosa. Aunque el primer sistema serio de tiempo compartido (CTSS)
fue creado en el M.I.T. en una 7094 especialmente modificada (Corbato et al.,
1962), el tiempo compartido no se popularizó realmente hasta que se generalizó
el uso del hardware de protección necesario durante la tercera generación. Después
del éxito del sistema CTSS, MIT, Bell Labs y General Electric (por ese entonces
un fabricante importante de computadoras) decidieron emprender el desarrollo de
un “servicio de computadora” una máquina que diera apoyo a cientos de usuarios
de tiempo compartido simultáneos. Su modelo fue el sistema de distribución de
electricidad: cuando usted necesita potencia eléctrica, simplemente enchufa una
clavija en la pared y, dentro de límites razonables, obtendrá tanta
electricidad como necesite. Los diseñadores de este sistema, llamado MULTICS
(servicio de información y computación multiplexado), contemplaban una enorme
máquina que proporcionara potencia de cómputo a todos los usuarios de Boston. La
idea de que máquinas mucho más potentes que su GE-645 se vendieran como
computadoras personales por unos cuantos miles de dólares sólo 30 años después
no era sino ciencia ficción en ese entonces. Para resumir un poco la historia,
MULTICS introdujo muchas ideas seminales en la literatura de computación, pero
su construcción fue mucho más difícil de lo que nadie había imaginado. Bell
Labs abandonó el proyecto, y General Electric dejó el negocio de las computadoras
por completo. Finalmente, MULTICS funcionó lo bastante bien como para usarse en
un entorno de producción de MIT y en docenas de otros sitios, pero el concepto
de un servicio de computadora se hizo obsoleto al desplomarse los precios de las
computadoras. No obstante, MULTICS tuvo una influencia enorme sobre los
sistemas subsecuentes; se le describe en (Corbato et al., 1972; Corbato y
Vyssotsky, 1965; Daley y Dennis, 1968; Organick, 1972;
Saltzer,
1974). Otro avance importante durante la tercera generación fue el crecimiento
fenomenal de las minicomputadoras, comenzando con la DEC PDP- 1 en 1961. La
PDP-1 sólo tenía 4K de palabras de 18 bits, pero a $120 000 por máquina (menos
del 5% del precio de una 7094), se vendieron como pan caliente. Para ciertos
tipos de trabajos no numéricos, la PDP-1 era casi tan rápida como la 7094, e
hizo nacer una industria totalmente nueva. A esta máquina pronto siguió una
serie de otras PDP (todas incompatibles, a diferencia de la familia IBM),
culminando en la PDP-11. Uno de los computólogos de BelI Labs que había
trabajado en el proyecto MULTICS, Ken Thompson, encontró subsecuentemente una
pequeña minicomputadora PDP-7 que nadie estaba usando y se propuso escribir una
versión de MULTICS reducida al mínimo, para un solo usuario. Este trabajo
posteriormente evolucionó para convertirse en el sistema operativo UNIX®, que
se popularizó en el mundo académico, las dependencias del gobierno y muchas
compañías. La historia de UNIX se cuenta en otras obras (p. ej., Salus, 1994).
Baste con decir que, dado que casi todo mundo podía obtener el código fuente,
diversas organizaciones desarrollaron sus propias versiones (incompatibles), lo
que condujo al caos. Con objeto de que fuera posible escribir programas
susceptibles de ejecución en cualquier sistema UNIX, el IEEE creó un estándar
para UNIX, llamado Posix, que casi todas las versiones actuales de UNIX
reconocen. POSIX define una interfaz mínima de llamadas al sistema que los
sistemas UNIX deben reconocer. De hecho, algunos otros sistemas de programación
ya reconocen la interfaz POSIX.
Cuarta generación (1980-????)
Un interesante desarrollo que comenzó a llevarse a cabo a
mediados de la década de los ochenta ha sido el crecimiento de las redes de
computadoras personales, con sistemas operativos de red y sistemas operativos
distribuidos.
En los sistemas operativos de red, los usuarios están
conscientes de la existencia de varias computadoras y pueden conectarse con máquinas
remotas y copiar archivos de una maquina a otra. Cada máquina ejecuta su propio
sistema operativo local y tiene su propio usuario.
Por el contrario, un sistema operativo distribuido es aquel
que aparece ante sus usuarios como un sistema tradicional de un solo
procesador, aun cuando está compuesto por varios procesadores. En un sistema
distribuido verdadero, los usuarios no deben ser conscientes del lugar donde su
programa se ejecute o de lugar donde se encuentren sus archivos; eso debe ser
manejado en forma automática y eficaz por el sistema operativo.
Ver mejor: https://www.examtime.com/es-ES/p/2288948
Ver mejor: https://www.examtime.com/es-ES/p/2288948
Clasificación sistemas operativos
Los sistemas operativos se pueden clasificar atendiendo a:
- ADMINISTRACIÓN DE TAREAS:
- MONOTAREA: los que permiten sólo ejecutar un programa a la vez
- MULTITAREA: los que permiten ejecutar varias tareas o programas al mismo tiempo
- ADMINISTRACIÓN DE USUARIOS
- MONOUSUARIO: aquellos que sólo permiten trabajar a un usuario, como es el caso de los ordenadores personales
- MULTIUSUARIO: los que permiten que varios usuarios ejecuten sus programas a la vez.
- ORGANIZACIÓN INTERNA O ESTRUCTURA
- Monolítico
- Jerárquico
- Cliente-servidor
- MANEJO DE RECURSOS O ACCESO A SERVICIOS
- CENTRALIZADOS: si permite utilizar los recursos de un solo ordenador
- DISTRIBUIDOS: si permite utilizar los recursos (CPU, memoria, periféricos...) de más de un ordenador al mismo tiempo 2 Llamadas al sistema
Ver mejor: https://www.examtime.com/es-ES/p/2289633
Estructura: niveles o estratos de diseño
El núcleo o kernel se divide en 5 capas o niveles:
Nivel 1. Gestión de Memoria:
Proporciona las facilidades de bajo nivel para la gestión de memoria secundaria
necesaria para la ejecución de procesos.
Nivel 2. Procesador: Se
encarga de activar los cuantums de tiempo para cada uno de los procesos,
creando interrupciones de hardware cuando no son respetadas.
Nivel 3. Entrada/Salida: Proporciona
las facilidades para poder utilizar los dispositivos de E/S requeridos por los
procesos.
Nivel 4. Información o Aplicación
o Intérprete de Lenguajes: Facilita la comunicación con los
lenguajes y el sistema operativo para aceptar las órdenes en cada una de las
aplicaciones. Ejecutando un programa el software de este nivel crea el ambiente
de trabajo e invoca a los procesos correspondientes.
Nivel 5. Control de Archivos: Proporciona
la facilidad para el almacenamiento a largo plazo y manipulación de archivos
con nombre, va asignando espacio y acceso de datos en memoria.
El núcleo o kernel realiza diferentes funciones tales como:- Manejo de interrupciones.
- Creación y destrucción de procesos.
- Cambio de estado de los procesos.
- Despacho
- Suspensión y reanudación de procesos.
- Sincronización de procesos.
- Comunicación entre procesos.
- Manipulación de los bloques de control de procesos.
- Apoyo para las actividades de entrada/salida.
- Apoyo para asignación y liberación de memoria.
- Apoyo para el sistema de archivos.
- Apoyo para el mecanismo de llamada y retorno de un procedimiento.
- Apoyo para ciertas funciones de contabilidad del sistema.
- Definicion y concepto de proceso.
- El Bloque de Control de Proceso (PCB) como imagen donde el sistema operativo ve el estado del proceso.
- Estados por los que pasa un proceso a lo largo de su existencia en la computadora.
- Operaciones que se pueden realizar sobre un proceso.
- Clasificacion de los procesos segun su forma de ejecucion, de carga, etc.
Ver mejor: https://www.examtime.com/es-ES/p/2289761
Núcleo
El Kernel consiste en la parte
principal del código del sistema operativo, el cual se encargan de controlar y
administrar los servicios y peticiones de recursos y de hardware con respecto a
uno o varios procesos, en otras palabras, el kernel es el corazón del sistema
operativo.
Cada sistema operativo tiene
un tipo distinto de kernel: así los Unix más tradicionales como FreeBSD usan un
kernel " monolítico" en el que está todo compilado dentro, otros usan
los llamados "microkernels" como el Darwin, Hurd e incluso Windows
(krnl32.dll). GNU/Linux usa un kernel "modular" (vmlinuz); un núcleo
bastante grande comparado con un microkernel, pero que es capaz de delegar
funciones en los llamados " módulos”, partes independientes del núcleo que
pueden ser incorporadas dinámicamente si hacen falta y luego descargadas si
molestan. Así se pueden cargar "drivers" para hardware, firewall o
funciones especiales de red (PPP, RDSI, etc.) cuando se necesiten y cuando por
ejemplo, se cierre la conexión a internet, liberar la memoria que usaba ese
modulo.
Interrupciones FHLI
Una interrupcion es un evento que altera la secuencia en que el procesador ejecuta las instrucciones. La interrupcion es generada por el hardware del sistema de computo.
Cuando ocurre una interrupcion:
- El sistema operativo toma el control (es decir, el hardware pasa el control al sistema operativo).
- El sistema operativo guarda el estado del proceso interrumpido. En muchos sistemas esta informacion se guarda en el bloque de control de proceso interrumpido.
- El sistema operativo analiza la interrupcion y transfiere el control a la rutina apropiada para atenderla; en muchos sistemas actuales el hardware se encarga de esto automaticamente.
- La rutina del manejador de interrupciones procesa la interrupcion.
- Se restablece el estado del proceso interrumpido (o del “siguiente proceso”).
- Se ejecuta el proceso interrumpido (o el “siguiente proceso”).
Una interrupcion puede ser iniciada especificamente por un proceso en ejecucion (en cuyo caso se suele denominar trampa (trap), y se dice que esta sincronizada con la operacion del proceso) o puede ser causada por algun evento que puede estar relacionado o no con el proceso en ejecucion (en cuyo caso se dice que es asincrona con la operacion del proceso). Los sistemas orientados hacia las interrupciones pueden sobrecargarse. Si estas llegan con mucha frecuencia, el sistema no sera capaz de atenderlas. En algunos sistemas orientados hacia el teclado, cada tecla presionada almacena en la memoria un codigo de un byte y genera un interrupcion para informar a la UCP que un caracter esta listo para ser procesado. Si la UCP no puede procesar el dato antes de que se presione la siguiente tecla, se pierde el primer caracter.
Despachador SCHEDULER
Tras una interrupcion externa ha cambiado el estado de un proceso.
Despues de que un extracodigo provoque imposibilidad de seguir la ejecucion de un proceso.
Tras una senal de error se ha suspendido el proceso hasta que no se haya tratado este.
Se utilizara una cola ordenada de modo que en cabeza de la cola este el proceso mas adecuado, asi la mision del dispatcher es la de ejecutar el primer proceso de la cola que no este siendo ejecutado.
Se puede tener en lugar de una cola, mas de una. Por ejemplo tres. Una para aquellos procesos a los que se les permiten dos segundos consecutivos de CPU. Otra para los que se les permiten 0,25 y otra para los que se les permite solo 0,02 segundos.
Cada cola se sirve con el criterio de "el primero en llegar es el primero en ser servido". Las colas con menor tiempo tienen mayor prioridad. Los procesos se colocan inicialmente en la cola de menor tiempo. Si consume todo el tiempo asignado se transfiere a la siguiente cola en prioridad, asi sucesivamente.
Se consigue asi que los procesos que consumen menos tiempo de procesador, reciban un proceso rapido, mientras que las tareas habituales uno mas largo.
Tras una interrupcion externa ha cambiado el estado de un proceso.
Despues de que un extracodigo provoque imposibilidad de seguir la ejecucion de un proceso.
Tras una senal de error se ha suspendido el proceso hasta que no se haya tratado este.
1. | Es el proceso en curso el mas apropiado para ser ejecutado sobre este procesador? (por las razones que sean, prioridad, recursos, etc). Si es asi, devolver el control a la posicion de memoria senalada por el contador de programa (continuar). En otro caso ir a 2. |
| 2. | Salvar el entorno volatil del proceso en curso. |
| 3. | Sacar del registro del proceso aquel cuyo entorno volatil es el mas adecuado para ser ejecutado. |
| 4. | Transferir el control a la posicion de memoria indicada por el contador de programa asociado al nuevo proceso. |
Se puede tener en lugar de una cola, mas de una. Por ejemplo tres. Una para aquellos procesos a los que se les permiten dos segundos consecutivos de CPU. Otra para los que se les permiten 0,25 y otra para los que se les permite solo 0,02 segundos.
Cada cola se sirve con el criterio de "el primero en llegar es el primero en ser servido". Las colas con menor tiempo tienen mayor prioridad. Los procesos se colocan inicialmente en la cola de menor tiempo. Si consume todo el tiempo asignado se transfiere a la siguiente cola en prioridad, asi sucesivamente.
Se consigue asi que los procesos que consumen menos tiempo de procesador, reciban un proceso rapido, mientras que las tareas habituales uno mas largo.
Su mision es asignar los procesadores centrales a los procesos. Es llamado cuando un proceso no puede seguir o puede emplearse mejor en otra parte. Se activa en las situaciones siguientes:
Estas son causas especiales de interrupcion, esto es, todas ellas consisten en interrupciones que alteran el estado de algun proceso. El funcionamiento del dispatcher es el siguiente:
Para determinar el proceso mas adecuado para ser ejecutado se ordenan los procesos ejecutables de acuerdo con algun criterio de prioridad. Las prioridades de los procesos vienen dadas y por tanto no son mision del dispatcher.
Administración de Procesos y del procesador.
La gestión de procesos es la tarea fundamental de cualquier
sistema operativo moderno. El sistema operativo debe asignar recursos a los
procesos, permitir el intercambio de información entre los mismos, proteger los
recursos de un proceso del resto y facilitar la sincronización de procesos. Para
alcanzar estos objetivos, el sistema operativo mantiene una estructura de datos
para cada proceso que describe su estado y los recursos que posee y que permite
al sistema operativo imponer un control sobre los procesos (PCB Bloque de
Control de Proceso).
En un monoprocesador multiprogramado, debe intercalarse en
el tiempo, la ejecución de múltiples procesos.
En un multiprocesador, no sólo puede intercalarse la
ejecución sino que los procesos se pueden ejecutar simultáneamente. Ambos,
intercalación y ejecución simultánea, son formas de concurrencia y llevan a una
multitud de problemas complejos, tanto para el programador de aplicaciones como
para el sistema operativo.
El sistema operativo debe llevar a cabo la función de
planificar y ofrecer mecanismos para compartir y sincronizar procesos.
Concepto de proceso.
Programas.- Colección de instrucciones que el procesador
interpreta y ejecuta, se almacenan en sistemas no volátiles necesitando ser
cargados en memoria principal para poder ser ejecutados, se considera un ente
estático.
Procesos.-Programa en ejecución, el sistema operativo les
asigna recursos, Se consideran un ente dinámico. El proceso es una abstracción
creada por el SO, que se compone de:
- Código de Programa: sección texto
- Contexto de Ejecución: PC, registros del procesador y una pila para invocación de procedimientos
- Sección de Datos, que contiene variables globales
- Recursos del sistema.
Características
- Permite modularizar y aislar errores de programas durante su ejecución
- Soporta concurrencia de actividades, lo que permite un mejor aprovechamiento de los recursos
- Denominaremos como procesos tanto a los trabajos (jobs) en sistemas de lotes, como a las tareas (task) en sistemas de tiempo compartido
Modelo
La diferencia entre un programa (conjunto de instrucciones)
y un proceso (instrucciones ejecutándose) es obvia y crucial para entender el
funcionamiento de los SO.
Imaginemos un mecánico de autos en un taller donde se
reparan carros con averías complejas en las que se hace necesario consultar el
manual de cada modelo, que contiene las instrucciones para reparar cada posible
avería. Además, se permiten reparaciones rápidas a las que se les da mayor
prioridad. Existe un almacén de refacciones y herramientas suficientes para las
reparaciones. Comparando esta situación con un sistema de cómputo se pueden
establecer las siguientes analogías:
- El mecánico sería el CPU (procesador) que realizará el trabajo.
- El manual de cada reparación sería el programa.
- Las herramientas serían los recursos disponibles
- Las refacciones serían los datos.
- La actividad de usar las herramientas para desmontar las piezas defectuosas sustituyéndolas por otras nuevas siguiendo las instrucciones del manual equivaldría al proceso.
Suponiendo que en un momento dado el mecánico está
realizando una reparación compleja (de las que llevan tiempo) y aparece un
carro que solicita una reparación de las rápidas (ha aparecido una
interrupción). El mecánico suspende momentáneamente la reparación compleja
anotando en qué situación se queda dicha reparación y qué operación estaba
realizando en ese momento (guarda el estado del proceso). Asimismo, sustituye
el manual que estaba realizando por el de la nueva reparación que se dispone a
realizar (cambio de programa). Comienza la nueva reparación (cambio de
proceso), en la que las herramientas no serán las mismas que antes (distintos
recursos); las indicaciones del usuario, las refacciones (datos) y las
indicaciones del manual (programa) llevarán a feliz término la reparación para
que el mecánico regrese a la reparación inicial.
Con este ejemplo se resalta que un proceso es una actividad
que se apoya en datos, recursos, un estado en cada momento y un programa.
Estados y transiciones de los procesos
Los PCB’s se almacenan en listas, una para cada posible
estado:
Los estados se pueden dividir en: Activos e inactivos
Activos los que compiten por el procesador. Tipos:
Ejecución.- Cuando el proceso tiene el control del cpu
Preparado (Listo).- Tienen las condiciones para ser
ejecutados pero no están en ejecución por alguna causa.
Bloqueado.- No pueden
ejecutarse porque necesitan algún recurso no disponible
Inactivos.- No pueden competir por el cpu
Los 3 estados principales pueden no ser suficientes
Justificación:
Si todos los procesos están en bloqueados esperando un
suceso y no hay memoria disponible para nuevos procesos, el procesador estará
desocupado, sin uso. La Solución: procesos suspendidos:
• Permitir la ejecución de más procesos
• Ampliar la memoria principal
• Intercambio de procesos entre memoria y disco (swapping)
Surgen 2 nuevos estados de un proceso:
suspendido listo: el proceso está suspendido, pero se encuentra
listo para ejecutarse
suspendido bloqueado: el proceso está suspendido y además
está esperando que suceda un evento
• El sistema operativo puede poner en suspendido un proceso
y transferirlo a disco
• El espacio liberado en la memoria principal es usado para
traer otro proceso
¿Qué proceso elegir para cargar en memoria?
Uno nuevo
Uno previamente suspendido (debemos elegir los que se
encuentran en suspendido listo y no en
suspendido bloqueado)
Otras razones por las que un proceso puede pasar a estado
suspendido:
• El sistema está en riesgo de fallo. El sistema suspende
todos los procesos activos para poder corregir errores
y volver a activarlos cuando el sistema funcione
correctamente
• Un proceso sospechoso de mal funcionamiento puede ser
suspendido hasta verificar su correcto
funcionamiento
• El planificador puede suspender los procesos de baja
prioridad en momento de carga excesiva del sistema
Control de procesos
PCB (Bloque de control de procesos)
Conjunto de datos donde se incluye el estado de un proceso en
cada momento, los recursos usados, registros, etc.
Objetivos
Que el sistema operativo localice la información sobre el
proceso
Mantener registrados los datos del proceso en caso de
suspensión o reanudación de la ejecución
Información contenida:
Estado del proceso.-
Contenido del contador de programa, estado del cpu en cuanto
a prioridad del proceso, modo de ejecución, etc. y estado de los registros
internos de la computadora.
Estadísticas de tiempo y ocupación de recursos.-
Planificación del CPU
Ocupación de memoria interna y externa.- Swapping
Recursos en uso
Archivos en uso
Privilegios
SCB (Bloque de control del sistema).- Objetivos globales
similares al PCB, además enlaza los PCB’s de los procesos existentes
Cambio de un proceso a otro suponiendo un solo
cpu, una tarea en ejecución a la vez y 2 procesos activos (A
y B) compitiendo por el cpu, ambos en memoria principal
Cambio de A por B
1. Deja de ejecutar el proceso en curso (A)
2. Se salva el estado del proceso A para su regreso al punto
de interrupción
3. Cede el control al
kernel
4. Cambio de contexto (de modo usuario a modo supervisor)
5. El kernel estudia si el proceso B está preparado para su ejecución
6. Si si, cambio de contexto (de modo supervisor a modo
usuario)
7. Repone el estado de B (si es que se había interrumpido
antes)
8. Pone en ejecución a B
Procesos ligeros: Hilos o hebras.
Un hilo de ejecución, en sistemas operativos, es similar a un proceso en que ambos representan una secuencia
simple de instrucciones ejecutada en paralelo con otras secuencias. Los hilos permiten dividir un programa en
dos o más tareas que corren simultáneamente, por medio de la multiprogramación. En realidad, este método
permite incrementar el rendimiento de un procesador de manera considerable. En todos los sistemas de hoy en
día los hilos son utilizados para simplificar la estructura de un programa que lleva a cabo diferentes funciones.
Todos los hilos de un proceso comparten los recursos del proceso. Residen en el mismo espacio de
direcciones y tienen acceso a los mismos datos. Cuando un hilo modifica un dato en la memoria, los otros
hilos utilizan el resultado cuando acceden al dato. Cada hilo tiene su propio estado, su propio contador, su
propia pila y su propia copia de los registros de la CPU. Los valores comunes se guardan en el bloque de
control de proceso (PCB), y los valores propios en el bloque de control de hilo (TCB).
Un ejemplo de la utilización de hilos es tener un hilo atento a la interfaz gráfica (iconos, botones, ventanas),
mientras otro hilo hace una larga operación internamente. De esta manera el programa responde más
ágilmente a la interacción con el usuario.
Diferencias entre hilos y procesos
Los hilos se distinguen de los tradicionales procesos en que los procesos son generalmente independientes,
llevan bastante información de estados, e interactúan sólo a través de mecanismos de comunicación dados por
programa
excepción
gestor
Terminación
normal
programa
excepción
gestor
Terminación
anormal
inicio
inicio
6
el sistema. Por otra parte, muchos hilos generalmente comparten otros recursos directamente. En sistemas
operativos que proveen facilidades para los hilos, es más rápido cambiar de un hilo a otro dentro del mismo
proceso, que cambiar de un proceso a otro. Este fenómeno se debe a que los hilos comparten datos y espacios
de direcciones, mientras que los procesos al ser independientes no lo hacen. Al cambiar de un proceso a otro
el sistema operativo (mediante el dispatcher) genera lo que se conoce como overhead, que es tiempo
desperdiciado por el procesador para realizar un cambio de modo (mode switch), en este caso pasar del estado
de Running al estado de Waiting o Bloqueado y colocar el nuevo proceso en Running. En los hilos como
pertenecen a un mismo proceso al realizar un cambio de hilo este overhead es casi despreciable.
Concurrencia y secuencialidad.
La concurrencia comprende un gran número de cuestiones de
diseño, incluyendo la comunicación entre procesos, competencia por los
recursos, sincronización de la ejecución de varios procesos y asignación del tiempo
de procesador a los procesos y es fundamental para que existan diseños como
Multiprogramación,
Multiproceso y Proceso distribuido
Los procesos son concurrentes si existen simultáneamente 2 o
más y llegan al mismo tiempo a ejecutarse.
La concurrencia puede presentarse en tres contextos
diferentes:
• Varias aplicaciones: (multiprogramación) para permitir que
el cpu sea compartido entre varios trabajos
• Aplicaciones estructuradas: Como ampliación del diseño
modular y la programación estructurada, algunas aplicaciones pueden
implementarse eficazmente como un conjunto de procesos concurrentes.
• Estructura del sistema operativo: Las mismas ventajas de
estructuración son aplicables a los sistemas operativos que están implementados
como un conjunto de procesos.
Tipos de computadora en los que puede haber concurrencia:
• Multiprogramación con un CPU. El sistema operativo se
encarga de repartir el CPU entre los procesos, intercalando su ejecución para
dar una apariencia de ejecución simultánea.
• Multiprocesador. Máquina formada por más de un CPU que
comparten memoria principal. Los procesos no sólo intercalan su ejecución sino
también la superponer.
• Multicomputadora. Es una máquina de memoria distribuida
formada por una serie de computadoras, es posible la ejecución simultánea de
los procesos en los diferentes CPU’s.
La concurrencia será aparente siempre que el número de
procesos sea mayor que el de procesadores disponibles y será real cuando haya
un proceso por procesador (Paralelismo).
Pros:
• Facilita la programación de aplicaciones: permite que se
estructuren como un conjunto de procesos que cooperan entre sí para alcanzar un
objetivo común.
•Acelera los cálculos: Dividiendo una tarea en varios
procesos, ejecutándolos en “paralelo”.
• Posibilita el uso interactivo a múltiples usuarios que
trabajan de forma simultánea.
• Permite un mejor aprovechamiento de los recursos, en
especial del CPU, ya que pueden aprovechar las fases de entrada-salida de unos
procesos para realizar las fases de procesamiento de otros.
Contras:
• Inanición e interrupción de procesos
• Ocurrencia de bloqueos
• Que 2 o más procesos
requieran el mismo recurso
Niveles objetivos y criterios de planificación.
Niveles de planificación.
Planificación de largo plazo.- (Planificación de trabajos),
determina a qué trabajos se les permite entrar al sistema, cuál es el próximo
trabajo que se va a ejecutar. Existe en los sistemas por lotes donde la decisión
se basa en las necesidades de recursos y su disponibilidad. En los sistemas de
tiempo compartido tiene como misión cargar los programas que se desea ejecutar
en memoria, es por tanto el encargado de crear los procesos.
Planificación de mediano plazo.- (Planificación de
Swapping), determina a qué proceso se le permite competir por el CPU. Suspende
y/o activa temporalmente procesos para mantener una operación uniforme en el
sistema y ayuda a realizar algunas funciones para optimizar el rendimiento del
sistema.
Planificación de corto plazo.- (Planificación de CPU),
determina a qué proceso deberá asignarse el CPU (despachar). Esta operación se
realiza muchas veces por segundo, por lo que el despachador debe estar permanente
en memoria.
Objetivos de la planificación
Justicia.- Sin favorecer o perjudicar procesos
Máxima capacidad de ejecución.- Realizar los trabajos lo más
rápido posible. Minimizar los cambios de procesos
Máximo número de usuarios interactivos.- Simultáneos
Predecibilidad.- Saber en todo momento cómo será la
ejecución.
Mínima sobrecarga.- A menor sobrecarga mayor velocidad.
Minimizar los cambios de contexto
Equilibrio en el uso de recursos.- Que estén ocupados
equitativamente el mayor tiempo posible
Seguridad de las prioridades.- Ejecutar más pronto los de
más alta prioridad
Muchos de estos objetivos están en conflicto unos con otros,
esto hace que la planificación sea un problema complejo.
Criterios de planificación.
Tiempo de respuesta.- Velocidad con que la computadora
responde a una petición, depende mucho de la velocidad de los dispositivos E/S.
Tiempo de servicio.- Tiempo que tarda en ejecutarse un
proceso, desde su carga en memoria, espera en la lista de listos, ejecución en
CPU y operaciones e/s.
Tiempo de ejecución.- Tiempo de servicio menos la espera en
la lista de listos, o sea, el tiempo teórico que necesitaría el proceso para
ejecutarse si fuera el único.
Tiempo de CPU.- Tiempo que un proceso usa el CPU sin contar
el tiempo de bloqueado.
Tiempo de espera.- Tiempo en que el proceso está activo pero
sin ser ejecutado (listas)
Eficiencia.- Que el cpu siempre esté ocupado para lograr un
buen rendimiento.
Rendimiento.- Número de procesos realizados por unidad de
tiempo, mientras mayor, mejor.
Medidas
t.- Tiempo que un proceso P necesita estar en ejecución para
hacer su tarea.
ti.- Instante en que el usuario da la orden de ejecución del
proceso
tf.- Instante en que el proceso termina la ejecución
Tiempo de servicio (T): T=tf-ti Tiempo de espera (E): E=T-t
t=20 ti=1 tf=30 T=30-1=29 E=29-20=9
Índice de servicio.- relación para evaluar la actuación de
la política establecida. Representa la relación de tiempo de ejecución y tiempo
de vida
I=t/T I=20/29=0.68
Si es un solo proceso, cuando I tiende a 1 el proceso está
limitado por cpu, si tiende a 0 está limitado por e/s. Si son varios procesos
deben sacarse valores promedio:
Tiempo medio de servicio, de espera y eficiencia (índice
medio de servicio)
Tiempo del núcleo.- Tiempo consumido por el kernel para
tomar decisiones del planificador de procesos, incluido el tiempo de cambio de
contexto y proceso
Tiempo de inactividad (Idle).- Tiempo consumido cuando la
lista de listos está vacía.
Técnicas de administración del planificador.
Planificación del CPU
Ciclo de ráfaga del CPU y de E/S.
El éxito de la planificación del CPU depende de la siguiente
prioridad observada de los procesos: la ejecución de un proceso consiste en un
ciclo de ejecución del CPU y de E/S, y los procesos se alternan entre estos dos
estados. La ejecución del proceso se hace alternando una ráfaga de CPU y una ráfaga
de E/S. La última ráfaga de CPU terminará con una solicitud al sistema para que
concluya la ejecución.
Planificador del CPU.
Siempre que el CPU queda inactivo, el sistema operativo debe
seleccionar para su ejecución uno de sus procesos de la lista de listos. La
selección es revisada por el planificador a corto plazo,
Estructura de planificación.
Las decisiones de planificación del CPU pueden efectuarse
cuando un proceso cambia:
De ejecución a bloqueado
De ejecución a listo
De bloqueado a listo
Cuando termina.
Algoritmos de planificación
Los procesos que se asignan al cpu son tomados de la lista
de listos. Esta lista se alimenta de 2 puntos:
Cuando un usuario inicia la ejecución de un programa, el
planificador a largo plazo recibe la orden de ejecución, crea el proceso y lo
pasa al planificador a corto plazo.
Cuando un proceso deja de estar en ejecución y no hay causas
de bloqueo, o deja de estar bloqueado.
Políticas de planificación:
Apropiativas.- Producen un cambio de proceso con cada cambio
de contexto; el proceso que usa el cpu puede ser suspendido y permitir el
acceso al cpu a otro proceso. (Tiempo compartido y tiempo real)
No apropiativas.- Un proceso no abandona nunca el procesador
desde su comienzo hasta su fin. (Por lotes).
