INGENIERÍA

EN
SISTEMAS COMPUTACIONALES

ASIGNATURA
SISTEMASOPERATIVOS
IMPARTIDA POR EL PROFESOR
M. C. ROGELIO FERNANDO ROGELIO MIRANDA

A C T I V I D A D
UNIDAD I. INTRODUCCION A LOS
SISTEMAS OPERATIVOS

PRESENTADO POR LA ESTUDIANTE

García Moreno Freddy Jhonatan

NÚMERO DE CONTROL: 22520244.

CHILPANCINGO GRO.19 DE FEBRERO 2024

 INTRODUCCIÓN

Un ordenador es una máquina que permite procesar la información de

forma rápida y automática. Sin embargo, la utilización de un ordenador
no es una tarea sencilla, ya que el modo en que podemos
comunicarnos con él, es decir, su interfaz, es extraña y compleja al
pensamiento humano. Se entiende por interfaz de un objeto la parte
del objeto accesible desde su exterior, que nos permite utilizarlo y
consultar su estado interno. Por ejemplo, un reloj digital presenta una
interfaz constituida por una serie de botones que posibilitan modificar
su comportamiento, cambiando la hora o programando una alarma, y
una pantalla y un dispositivo sonoro por el que se puede consultar su
estado actual (consultar la hora u oír la expiración de una alarma).
Para usar un reloj digital no es preciso conocer su funcionamiento
interno, sólo hay que saber utilizar su interfaz. La interfaz de un
ordenador viene determinada por un conjunto, normalmente pequeño,
de instrucciones máquina que permiten utilizar los dispositivos físicos o
hardware (CPU, memoria y periféricos) de los que se compone. Si los
usuarios de un ordenador tuvieran que utilizar el hardware a través de
sus instrucciones máquina se escribirían muy pocos programas, y
estos no podrían resolver tareas excesivamente complejas, pues el
uso directo de los dispositivos físicos del ordenador mediante estas
instrucciones es complejo, tedioso, y está lleno de detalles.
La solución que se ha ido adoptando con el tiempo para salvar esta
complejidad es la de escribir capas o niveles de software. Una capa de
software de nivel i es un conjunto de programas que trabajan
directamente con la interfaz de su nivel inferior (i - 1), y presentan a su
nivel superior (i + 1) una interfaz que permite utilizar el nivel i -1 de una
forma más sencilla. Se dice que una capa software abstrae a su nivel
superior de los detalles del nivel inferior, siendo, por tanto, un
mecanismo de abstracción. Una capa de nivel i puede permitir a su
capa superior utilizar las interfaces de sus niveles inferiores (i -1, i -
2, ...), o puede obligar a utilizar solamente la interfaz de la capa i,
asegurándose así la utilización directa del nivel inferior. El sistema
operativo es una de las capas de software más importantes de un
sistema informático.

1.1 Definición de sistema operativo [STAL95] [TANE93] [BIC88]

Se puede definir un sistema operativo como un conjunto de programas

que controlan directamente los recursos hardware o físicos de un
ordenador ( CPU, memoria principal y periféricos ) proporcionando una
máquina virtual más fácil de utilizar que el hardware subyacente. El
sistema operativo es la capa de software más baja de un ordenador,
como se refleja en la figura 1.1.
En esta figura se observa cómo el sistema operativo es la única capa
que trabaja directamente con el hardware. Por encima del sistema
operativo se encuentra un nivel formado por traductores, editores de
texto e intérpretes de órdenes. Los dos primeros tipos de programas,
junto con enlazadores y depuradores, son útiles para crear un nivel de
abstracción cómodo para el desarrollo de programas, la utilidad de los
intérpretes de órdenes se verá en un apartado posterior. La unión de
los programas de las dos capas intermedias de la figura conforma el
software de sistemas de un ordenador. Por último, está el nivel
constituido por los programas de aplicación, estos programas no dan
servicio a otros programas, su finalidad es resolver problemas
concretos. Son los programas que suele ejecutar un usuario no
informático. Pertenecen a esta capa los procesadores de texto, hojas
de cálculo, agendas electrónicas, juegos, etc.

En general, puede decirse que los sistemas operativos realizan dos

funciones:
 1. Constitución de una máquina virtual o extendida

El sistema operativo pone al servicio del usuario una máquina virtual

cuyas características son distintas (y más fáciles de abordar) que las
de la máquina real subyacente. Algunas áreas en las que es frecuente
que la máquina virtual difiera de la máquina real que la soporta son:

Entrada/salida (E/S).

La capacidad de E/S de un hardware básico puede que sea

extremadamente compleja y que requiera sofisticados programas para
su utilización. Un sistema operativo evita al usuario el problema de
tener que comprender el funcionamiento de este hardware, poniendo a
su alcance una máquina virtual mucho más sencilla de usar.

Memoria.

Muchos sistemas operativos presentan la imagen de una máquina

virtual cuya memoria difiere en tamaño de la de la máquina real
subyacente. Así, por ejemplo, un sistema operativo puede emplear
memoria secundaria (discos magnéticos) para crear la ilusión de una
memoria principal mucho más extensa de la que se dispone en
realidad. Alternativamente, puede repartir la memoria principal entre
varios usuarios, de forma que cada uno de ellos "vea" una máquina
virtual cuya memoria sea menor que la de la máquina real.

Sistema de ficheros.

La mayoría de las máquinas virtuales incluyen un sistema de ficheros

para el almacenamiento a largo plazo tanto de programas como de
datos. El sistema de ficheros está basado en la capacidad de
almacenamiento sobre cinta o disco de la máquina real. El sistema
operativo, sin embargo, permite al usuario acceder a la información
almacenada a través de nombres simbólicos en lugar de hacerlo a
través de su posición física en el medio de almacenamiento.

Protección y tratamiento de errores.

Desde el momento en que la mayoría de los ordenadores son

compartidos por un determinado número de usuarios, es esencial que
cada uno de ellos esté protegido de los efectos de los errores o de la
mala fe de los demás. Los ordenadores varían considerablemente por
lo que respecta al grado de protección que proporciona su hardware
básico, siendo misión del sistema operativo el constituir una máquina
virtual en la que ningún usuario pueda afectar de manera negativa al
trabajo de los demás.

Interacción a nivel de programa.Una máquina virtual puede posibilitar

la interacción entre distintos programas de los usuarios de forma que,
por ejemplo, la salida de uno de ellos se emplee como entrada de otro.

La naturaleza concreta de una máquina virtual dependerá de la

aplicación particular a la que se dedique. Así, por ejemplo, las
características de una máquina virtual que controle un sistema de
tiempo real serán distintas de las de una máquina virtual que se utilice
para el desarrollo de programas.
 2. Utilización compartida de recursos

Un sistema operativo debe lograr que se compartan los recursos de un

ordenador entre un cierto número de usuarios que trabajen de forma
simultánea. La finalidad de esto está en incrementar la disponibilidad
del ordenador con respecto a sus usuarios y, al mismo tiempo,
maximizar la utilización de recursos tales como procesadores
centrales, memoria y dispositivos de E/S. La importancia de la
utilización eficiente de estos recursos depende de su coste.

TEMA 2. DEFINICIÓN Y CONTROL DE PROCESOS

Los sistemas operativos multiprogramados necesitan del concepto de
proceso. El sistema operativo debe entremezclar la ejecución de un
número de procesos para maximizar la utilización de los recursos del
ordenador. Al mismo tiempo, los sistemas de tiempo compartido deben
proporcionar un tiempo de respuesta razonable. El sistema operativo
debe asignar recursos a los procesos de acuerdo a una política
específica (ciertas funciones o aplicaciones son de mayor prioridad),
mientras impide los interbloqueos. Por último, el sistema operativo
debe ofrecer un soporte para llevar a cabo la comunicación entre
procesos.

El concepto de proceso es clave en los sistemas operativos modernos.

La gestión del procesador mediante multiprogramación, revolucionó la
concepción de los sistemas operativos, e introdujo el término proceso
como elemento necesario para realizar dicha gestión. Por lo demás,
este tema trata sobre la definición de proceso, el estudio de sus
propiedades, y la gestión que realiza el sistema operativo para crear la
abstracción de proceso, aunque esto último se completará en el tema
de planificación. Por último, descubriremos que el concepto de
proceso encierra, en realidad, dos características potencialmente
independientes: por un lado, es una unidad a la que se le asigna y
posee recursos y, por otro, es una unidad planificable. Basándonos en
esta distinción emprenderemos el estudio de los threads (hebra o hilo),
o también llamados procesos ligeros .

2.1 ¿ Qué es un proceso ? [DEIT93] [LIST86] [TANE93]

Hasta ahora hemos utilizado siempre el término programa. A partir de

ahora distinguiremos entre programa y proceso. Un programa es una
secuencia de instrucciones escrita en un lenguaje dado. Un proceso
es una instancia de ejecución de un programa, caracterizado por su
contador de programa, su palabra de estado, sus registros del
procesador, su segmento de texto, pila y datos, etc. Un programa es
un concepto estático, mientras que un proceso es un concepto
dinámico. Es posible que un programa sea ejecutado por varios
usuarios en un sistema multiusuario, por cada una de estas
ejecuciones existirá un proceso, con su contador de programa,
registros, etc. El sistema operativo necesita el concepto de proceso
para poder gestionar el procesador mediante la técnica de
multiprogramación o de tiempo compartido, de hecho, el proceso es la
unidad planificable, o de asignación de la CPU.

2.2 Estados de un proceso y Transiciones de estado de los procesos

[DEIT93] [TANE93] [SILB94][STAL95]

Durante su vida, un proceso puede pasar por una serie de estados

discretos, algunos de ellos son:

En ejecución: El proceso ocupa la CPU actualmente, es decir, se está

ejecutando.

Listo o preparado: El proceso dispone de todos los recursos para su

ejecución, sólo le falta la CPU.

Bloqueado: Al proceso le falta algún recurso para poder seguir

ejecutándose, además de la CPU. Por recurso se pueden entender un
dispositivo, un dato, etc. El proceso necesita que ocurra algún evento
que le permita poder proseguir su ejecución.
Hay otros estados de los procesos, pero en la presente exposición se
tratarán estos tres. Por sencillez, se considera un sistema con una
sola CPU, aunque no es difícil la extensión a múltiples procesadores.
Solamente puede haber un proceso en ejecución a la vez, pero
pueden existir varios listos y varios pueden estar bloqueados. Así
pues, se forman una lista de procesos listos y otra de procesos
bloqueados. La lista de procesos listos se ordena por prioridad, de
manera que el siguiente proceso que reciba la CPU será el primero de
la lista. La lista de procesos bloqueados normalmente no está
ordenada; los procesos no se desbloquean (es decir, no pasan a ser
procesos listos) en orden de prioridad, sino que lo hacen en el orden
de ocurrencia de los eventos que están esperando. Como se verá más
adelante, hay situaciones en las cuales varios procesos pueden
bloquearse esperando la ocurrencia del mismo evento; en tales casos
es común asignar prioridades a los procesos que esperan.

Transiciones de estado de los procesos

A continuación se dan ejemplos de eventos que pueden provocar

transiciones de estado en un proceso en este modelo de tres estados
(ver figura 2.1). La mayoría de estos eventos se discutirán con
profundidad a lo largo del curso:
De ejecución á Bloqueado: al iniciar una operación de E/S, al realizar
una operación WAIT sobre un semáforo a cero (en el tema de
procesos concurrentes se estudiarán los semáforos).

De ejecución á Listo: por ejemplo, en un sistema de tiempo

compartido, cuando el proceso que ocupa la CPU lleva demasiado
tiempo ejecutándose continuamente (agota su cuanto) el sistema
operativo decide que otro proceso ocupe la CPU, pasando el proceso
que ocupaba la CPU a estado listo.

De Listo á en ejecución: cuando lo requiere el planificador de la CPU

(veremos el planificador de la CPU en el tema de planificación de
procesos).

De Bloqueado á Listo: se dispone del recurso por el que se había

bloqueado el proceso. Por ejemplo, termina la operación de E/S, o se
produce una operación SIGNAL sobre el semáforo en que se bloqueó
el proceso, no habiendo otros procesos bloqueados en el semáforo.

Obsérvese que de las cuatro transiciones de estado posibles, la única

iniciada por el proceso de usuario es el bloqueo, las otras tres son
iniciadas por entidades externas al proceso.

Figura 2.1 Transiciones de estado de los procesos.

Interpretación de la figura. Como podemos observar en esta figura
tenemos una serie de transiciones posibles entre estados de proceso,
representados a partir mediante una gama de colores. Estos colores
hay que interpretarlos de forma que, el color del borde de los estados
representa a dichos estados, los colores dentro de los circulos nos
dicen las posibles alternativas de acceso hacia otro estado, y los
colores de las flechas nos representan hacia que estado nos dirigimos
si seguimos la misma.

TEMA 3. PLANIFICACIÓN DE PROCESOS

Durante este capítulo analizaremos todos los aspectos relacionados
con el problema de cuándo asignar un procesador(CPU) y a qué
proceso. Distinguiremos entre tres niveles o tipos de planificación (a
largo, medio y corto plazo).

A partir de aquí nos centraremos en la planificación a corto plazo o de

la CPU. Discutiremos los principales objetivos y criterios a tener en
cuenta a la hora de decidirnos por una determinada política de
planificación. A continuación realizaremos una clasificación de estos
criterios agrupándolos en apropiativos y no apropiativos. Hablaremos
del reloj de interrupciones, con la intención de aclarar cómo es posible
la intervención del sistema operativo para evitar la monopolización de
la CPU por parte de los usuarios. Dedicaremos especial atención al
mecanismo de planificación basado en prioridades. Terminaremos
haciendo un estudio y evaluación cualitativo de los algoritmos de
planificaciónque se pueden emplear. Durante este repaso haremos
una reflexión sobre las repercusiones en cuanto a eficiencia y tiempo
de respuesta del parámetro tamaño de cuanto.

3.1 Niveles de Planificación [DEIT93] [MILE94] [STAL95]

La planificación de la CPU, en el sentido de conmutarla entre los

distintos procesos, es una de las funciones del sistema operativo. Este
despacho es llevado a cabo por un pequeño programa llamado
planificador a corto plazo o dispatcher (despachador). La misión del
dispatcher consiste en asignar la CPU a uno de los procesos
ejecutables del sistema, para ello sigue un determinado algoritmo. En
secciones posteriores estudiaremos algunos algoritmos posibles. Para
que el dispatcher conmute el procesador entre dos procesos es
necesario realizar un cambio de proceso.

Los acontecimientos que pueden provocar la llamada al dispatcher

dependen del sistema (son un subconjunto de las interrupciones), pero
son alguno de estos:
 El proceso en ejecución acaba su ejecución o no puede seguir
ejecutándose (por una E/S, operación WAIT, etc).

Un elemento del sistema operativo ordena el bloqueo del proceso en

ejecución (ver estados de un proceso).

El proceso en ejecución agota su cuantum o cuanto de estancia en la

CPU.

Un proceso pasa a estado listo.

Hay que destacar el hecho de que cuanto menos se llame al

dispatcher menos tiempo ocupa la CPU un programa del sistema
operativo, y, por tanto, se dedica más tiempo a los procesos del
usuario (un cambio de proceso lleva bastante tiempo).

Así, si sólo se activa el dispatcher como consecuencia de los 2

primeros acontecimientos se estará haciendo un buen uso del
procesador. Este criterio es acertado en sistemas por lotes en los que
los programas no son interactivos. Sin embargo, en un sistema de
tiempo compartido no es adecuado, pues un proceso que se dedicara
a realizar cálculos, y no realizara E/S, monopolizaría el uso de la CPU.
En estos sistemas hay que tener en cuenta el conjunto de todos los
procesos, activándose el dispatcher con la circunstancia tercera y,
posiblemente, la cuarta. Los sistema operativos en que las dos
siguientes circunstancias no provocan la activación del dispatcher
muestran preferencia por el proceso en ejecución, si no ocurre esto se
tiene más en cuenta el conjunto de todos los procesos.

Se puede definir el scheduling -algunas veces traducido como -

planificación- como el conjunto de políticas y mecanismos construidos
dentro del sistema operativo que gobiernan la forma de conseguir que
los procesos a ejecutar lleguen a ejecutarse.

El scheduling está asociado a las cuestiones de:

Cuándo introducir un nuevo proceso en el Sistema.

Determinar el orden de ejecución de los procesos del sistema.

El scheduling está muy relacionado con la gestión de los recursos.
Existen tres niveles de scheduling, como se ilustra en la figura 1.1,
estos niveles son:

Planificador de la CPU o a corto plazo.

Planificador a medio plazo.

Planificador a largo plazo.

Ya hemos hablado del planificador de la CPU, y en los subapartados

posteriores se comentan los dos restantes:

3.1.1 Planificación a largo plazo

Este planificador está presente en algunos sistemas que admiten

además de procesos interactivos trabajos por lotes. Usualmente , se
les asigna una prioridad baja a los trabajos por lotes, utilizándose
estos para mantener ocupados a los recursos del sistema durante
períodos de baja actividad de los procesos interactivos. Normalmente,
los trabajos por lotes realizan tareas rutinarias como el cálculo de
nóminas; en este tipo de tareas el programador puede estimar su
gasto en recursos, indicándoselo al sistema. Esto facilita el
funcionamiento del planificador a largo plazo.

El objetivo primordial del planificador a largo plazo es el de dar al

planificador de la CPU una mezcla equilibrada de trabajos, tales como
los limitados por la CPU (utilizan mucho la CPU) o la E/S. Así, por
ejemplo, cuando la utilización de la CPU es baja, el planificador puede
admitir más trabajos para aumentar el número de procesos listos y,
con ello, la probabilidad de tener algún trabajo útil en espera de que se
le asigne la CPU. A la inversa, cuando la utilización de la CPU llega a
ser alta, y el tiempo de respuesta comienza a reflejarlo, el planificador
a largo plazo puede optar por reducir la frecuencia de admisión de
trabajos.

Normalmente, se invoca al planificador a largo plazo siempre que un

proceso termina. La frecuencia de invocación depende, pues, de la
carga del sistema, pero generalmente es mucho menor que la de los
otros dos planificadores. Esta baja frecuencia de uso hace que este
planificador pueda permitirse utilizar algoritmos complejos, basados en
las estimaciones de los nuevos trabajos.

3.1.2 Planificación a Medio Plazo

En los sistemas de multiprogramación y tiempo compartido varios
procesos residen en la memoria principal. El tamaño limitado de ésta
hace que el número de procesos que residen en ella sea finito. Puede
ocurrir que todos los procesos en memoria estén bloqueados,
desperdiciándose así la CPU. En algunos sistemas se intercambian
procesos enteros (swap) entre memoria principal y memoria
secundaria (normalmente discos), con esto se aumenta el número de
procesos, y, por tanto, la probabilidad de una mayor utilización de la
CPU.

El planificador a medio plazo es el encargado de regir las transiciones

de procesos entre memoria principal y secundaria, actúa intentando
maximizar la utilización de los recursos. Por ejemplo, transfiriendo
siempre a memoria secundaria procesos bloqueados, o transfiriendo a
memoria principal procesos bloqueados únicamente por no tener
memoria.

TEMA 4. CONCURRENCIA: EXCLUSIÓN MUTUA Y

SINCRONIZACIÓN

4.1 Comunicación y Sincronización de Procesos [BENA82] [LIST86]

[STAL95] [TANE93] [FINK90]
Puede verse la concurrencia de procesos como la ejecución
simultánea de varios procesos. Si tenemos un multiprocesador o un
sistema distribuido(tema 1) la concurrencia parece clara, en un
momento dado cada procesador ejecuta un proceso. Se puede ampliar
el concepto de concurrencia si entendemos por procesado concurrente
(o procesado paralelo) la circunstancia en la que de tomar una
instantánea del sistema en conjunto, varios procesos se vean en un
estado intermedio entre su estado inicial y final. Esta última definición
incluye los sistemas multiprogramados de un único procesador que
estudiamos en los temas anteriores.

Los distintos procesos dentro de un ordenador no actúan de forma

aislada. Por un lado, algunos procesos cooperan para lograr un
objetivo común. Por otro lado, los procesos compiten por el uso de
unos recursos limitados, como el procesador, la memoria o los
ficheros. Estas dos actividades de cooperación y competición llevan
asociada la necesidad de algún tipo de comunicación entre los
procesos. Parte de este tema lo dedicaremos a estudiar mecanismos
de comunicación entre los procesos.

Para aclarar un poco todo esto, supongamos que en un entorno UNIX

se ejecuta la orden
 cat tema1 tema2 tema3 | wc -l

Esta orden va a provocar que el intérprete de órdenes cree dos

procesos concurrentes, el primero ejecutará el programa cat, que
concatenará el contenido de los ficheros de texto tema1, tema2 y
tema3. El segundo ejecutará el programa wc, que contará el número
de líneas de la salida producida por cat. Estos dos procesos cooperan,
y será preciso algún tipo de sincronización entre ellos, concretamente
hasta que cat no produzca alguna salida wc debería bloquearse.

4.1.1 Cooperación entre Procesos

La velocidad de un proceso con respecto a otro es impredecible ya

que depende de la frecuencia de la interrupción asociada a cada uno
de ellos y cuán a menudo y de por cuánto tiempo tiene asignado cada
proceso un procesador. Diremos, pues, que un proceso se ejecuta
asíncronamente con respecto a otro, es decir, sus ejecuciones son
independientes. Sin embargo, hay ciertos instantes en lo que los
procesos deben sincronizar sus actividades. Son estos puntos a partir
de los cuales un proceso no puede progresar hasta que otro haya
completado algún tipo de actividad.

Los procesos también necesitan comunicarse entre sí. Por ejemplo,

para leer de un fichero, los procesos de usuario deben decir al proceso
que gestiona los ficheros lo que desean. Este, a su vez, debe pedirle
al proceso de disco que lea los bloques necesarios. Cuando el shell
conecta dos procesos con un tubo, los datos de salida del primer
proceso se transfieren al segundo. Se necesita que los procesos se
comuniquen entre sí, con un mecanismo bien estructurado y no por
medio de interrupciones.

4.1.2 Competencia entre los procesos

Los recursos de un sistema pueden clasificarse como compartibles, lo

que significa que pueden ser utilizados por varios procesos de forma
concurrente, o no compartibles, lo que equivale a que su uso se
restrinja a un sólo proceso a la vez. El hecho de que un recurso no sea
compartible deriva de una de las dos razones siguientes:
La naturaleza física del recurso hace que sea imposible compartirlo.
Un ejemplo lo constituye una impresora, si una impresora fuera
utilizada por varios procesos simultáneamente sus salidas se
entremezclarían en el papel.

El recurso es tal que si es usado por varios procesos de forma

concurrente la acción de uno de ellos puede interferir con la de otro.
Un ejemplo común lo constituye un fichero que contiene unos datos
accesibles desde más de un proceso, y modificables al menos por uno
de ellos. Por ejemplo, supongamos un fichero que contiene registros
con la siguiente información sobre una cuenta bancaria:

CLAVE

SALDO

Supongamos también dos procesos que se ejecutan

concurrentemente y que actualizan una misma cuenta, el proceso P1
añade al saldo el valor de la nómina y el proceso P2 descuenta del
saldo una factura domiciliada. El código de los procesos es el
siguiente:
 El resultado final de la ejecución de los dos procesos debería
actualizar el saldo añadiéndole la nómina, y descontándole la factura.
Sin embargo, la secuencia de ejecución en el procesador de las
instrucciones a1b1b2b3a2a3, que puede darse debido a un cambio de
proceso, hace que no se descuente la factura.

Dentro de la categoría de recursos no compartibles se incluirán la

mayoría de los periféricos (los discos no), los ficheros de escritura y
las zonas de memoria sujetas a modificación. Los recursos
compartibles incluirán la CPU (en los temas previos vimos cómo
compartir la CPU entre los procesos introduciendo el concepto de
PCB), los ficheros de lectura, y las zonas de memoria que contengan
rutinas puras o bien datos que no están sujetos a modificación.

4.1.3 Requisitos para la Exclusión Mutua

Los recursos no compartibles, ya sean periféricos, ficheros, o datos en

memoria, pueden protegerse del acceso simultáneo por parte de
varios procesos evitando que éstos ejecuten de forma concurrente sus
fragmentos de código a través de los cuales llevan a cabo este
acceso. Estos trozos de código reciben el nombre de secciones o
regiones críticas, pudiéndose asimilar el concepto de exclusión mutua
en el uso de estos recursos a la idea de exclusión mutua en la
ejecución de las secciones críticas. Así, por ejemplo, puede
implementarse la exclusión mutua de varios procesos en el acceso a
una tabla de datos mediante el recurso de que todas las rutinas que
lean o actualicen la tabla se escriban como secciones críticas, de
forma que sólo pueda ejecutarse una de ellas a la vez. En el ejemplo
previo de la cuenta bancaria los fragmentos de código a1a2a3 y
b1b2b3 constituyen dos secciones críticas mutuamente excluyentes,
esto significa que una vez que se ha comenzado la ejecución de una
sección crítica, no se puede entrar en otra sección crítica mutuamente
excluyente.

Idear soluciones que garanticen la exclusión mutua es uno de los

problemas fundamentales de la programación concurrente. Muchas
son las alternativas y tipos de mecanismos que se pueden adoptar. A
lo largo de este tema veremos diferentes soluciones software y alguna
hardware ; unas serán sencillas y otras complejas, algunas requieren
la cooperación voluntaria de los procesos y otras que exigen un
estricto ajuste a rígidos protocolos. La selección de las operaciones
primitivas adecuadas para garantizar la exclusión mutua de las
secciones críticas es una decisión primordial en el diseño de un
sistema operativo. Al menos, una solución apropiada debería cumplir
las cuatro condiciones siguientes:
 1. Que no haya en ningún momento dos procesos dentro de sus
respectivas secciones críticas.

2. Que no hagan suposiciones a priori sobre las velocidades relativas

de los procesos o el número de procesadores disponibles.

3. Que ningún proceso que esté fuera de su sección crítica pueda

bloquear a otros.

4. Que ningún proceso tenga que esperar un intervalo de tiempo

arbitrariamente grande para entrar en su sección crítica.

Tema 5. INTERBLOQUEOS
5.1 Definiciones Previas [DEIT93] [BIC88]

Cuando un proceso de un sistema de multiprogramación espera en

balde a que se presente un evento específico, se dice que se
encuentra en un estado de interbloqueo o bloqueo mutuo. Los
procesos que pueden encontrase en esta situación pueden ser uno o
varios.
En los sistemas de multiprogramación, compartir recursos es uno de
los principales objetivos del sistema operativo. Cuando se comparten
recursos entre una población de usuarios o procesos, cada uno de los
cuales mantiene un control exclusivo sobre ciertos recursos asignados
a él, es posible que se produzcan bloqueos mutuos que impedirán la
terminación de algunos de los procesos del sistema.

Todos los interbloqueos suponen demandas contradictorias de

recursos por parte de dos o más procesos. La figura 5.1 ilustra este
conflicto de forma abstracta en el caso de dos procesos y dos
recursos. Los dos ejes del diagrama representan el avance de los dos
procesos en términos de instrucciones ejecutadas. El avance conjunto
de los dos procesos se representa entonces con una secuencia
discreta de puntos en el espacio. Las líneas horizontales o verticales
representan el intervalo de tiempo en el que sólo uno de los procesos
está ejecutándose (intercalado); una línea diagonal significa ejecución
simultánea (solapamiento). Supóngase que existe un punto en la
ejecución de cada proceso en el que se requiere el uso exclusivo de
ambos recursos, R1 y R2, para continuar. En el ejemplo, llega un
punto en el que el proceso P1 ha adquirido el recurso R1 y el proceso
P2 ha adquirido el recurso R2, y cada proceso necesita el otro recurso.
Este es el punto de interbloqueo.
 En este tema se analizará el problema del interbloqueo y las distintas
alternativas de solución que se pueden adoptar clasificadas en las
siguientes cuatro áreas : prevención, evitación, detección y
recuperación del bloqueo mutuo. Para cada una de las estrategias
adoptadas, se analizará el equilibrio entre la sobrecarga debida a los
mecanismos de corrección del interbloqueo y los beneficios que
reportan. En algunos casos es excesivo el precio (gasto extra) que hay
que pagar para conseguir a toda costa que no se produzcan
interbloqueos. Sin embargo, en algunos casos, como en los sistemas
de tiempo real, no hay más alternativa que pagar el precio, ya que
puede resultar catastrófico permitir la posibilidad de un bloqueo mutuo.

Un problema afín : el aplazamiento indefinido

En cualquier sistema que mantenga los procesos en espera mientras

se les asigna un recurso o se toman decisiones de planificación, la
programación de un proceso puede postergarse indefinidamente
mientras otro recibe la atención del sistema. Tal situación se conoce
con varios nombres, entre los que se incluyen aplazamiento indefinido,
bloqueo indefinido e inanición, y puede resultar tan peligrosa como el
interbloqueo.

El aplazamiento indefinido puede ocurrir debido a predisposiciones en

las políticas de planificación de recursos del sistema. Cuando los
recursos se planifican por prioridad, es posible que un proceso dado
espere de forma indefinida un recurso porque siguen llegando otros
procesos con mayor prioridad. Los sistemas deben diseñarse para
administrar los procesos en espera de manera justa además de
eficiente. En algunos sistemas, el aplazamiento indefinido se evita
aumentando la prioridad del proceso mientras espera (técnica de
envejecimiento). En algún momento la prioridad de ese proceso
superará la prioridad de los entrantes y el proceso en espera será
atendido.

5.2 Casos de Interbloqueos [STAL95]

El caso más simple de interbloqueo sería el de un sólo proceso que

espera la ocurrencia de un evento y, sin embargo, el sistema no
incluye la posibilidad de señalar dicha ocurrencia. Es muy difícil
detectar los bloqueos mutuos de esta naturaleza. La mayor parte de
los bloqueos mutuos implican una competencia entre varios procesos
por varios recursos.
Holt (1972) utilizó grafos dirigidos para representar situaciones de
interbloqueo. Estos grafos tienen dos tipos de nodos : procesos, que
se representan con círculos, y recursos, representados por cuadrados.
Si in proceso está utilizando un recurso, previamente solicitado y
concedido, se traza un arco desde el nodo del recurso (cuadrado)
hasta el proceso (círculo). En la figura 2, el recurso R está en ese
momento asignado al proceso A. En b), el proceso B está solicitando
el recurso s. Por último en c) se representa un situación de
interbloqueo : el proceso C está a la espera del recurso T, que está
asignado al proceso D. El proceso D no ha dejado T, porque está
esperando a que quede libre el recurso U, que, a su vez, está siendo
utilizado por C. Ambos esperarán indefinidamente.

El siguiente ejemplo servirá para ilustrar el empleo de grafos de

recursos. Supongamos que tenemos tres procesos, A, B y C, y tres
recursos, R, S, y T. La figura 5.2 representa las secuencias de petición
y liberación que realizan los tres procesos. El sistema operativo tiene
en todo momento completa libertad para ejecutar cualquiera de los
procesos que no estén bloqueados, así que, por ejemplo, podría
decidirse a ejecutar A hasta que éste terminara su trabajo, después B
hasta que acabe y, finalmente C.

Este secuenciamiento no produce interbloqueo, ( ya que no se compite

por los recursos), pero suprime completamente el paralelismo. Además
de pedir y liberar recursos, los procesos también realizan E/S y
procesamiento de datos. Si se ejecutan uno tras otro, se elimina
completamente la posibilidad de que, mientras uno de ellos está
esperando que acabe una E/S, otro pueda utilizar el procesador.

Supongamos, sin embargo, que los procesos realizan tanto E/S como
procesamiento de datos, de forma que la planificación por turno
rotatorio es la más adecuada. En este caso, la secuencia de petición
de recursos podría ser la representada en la figura 3 (d). Si las seis
peticiones se llevan a cabo en ese orden, se producirían los seis
grafos de los casos (e)-(j). Después de la petición 4, A está bloqueado
en espera de captar S, como se muestra en (h). Los procesos B y C se
bloquean en las dos etapas siguientes, lo que conduce finalmente a un
bucle cerrado y al correspondiente interbloqueo representado en (j).
Figura 5.3 Ejemplo de Interbloqueo y como evitarlo.

El sistema operativo no está obligado a ejecutar los procesos en

ningún orden en particular. En concreto, si la concesión de un recurso
a un proceso determinado puede provocar interbloqueo, el sistema
operativo es muy libre de suspender al proceso y no atender su
petición hasta que esté seguro de que esto no conduce a una
situación problemática. En la figura 5.3, por ejemplo, si el sistema
operativo supiera que se avecinaba un interbloqueo, podría decidir
suspender al proceso B antes de concederle el recurso S. La
ejecución sólo de los procesos A y C produciría las secuencias de
petición y liberación de la figura 5.3 (k), en lugar de las de la figura 5.3
(d). Esta secuencia de ejecución produce los grafos de recursos (l)-(q),
y no produce interbloqueo.

Después de la etapa (q), no hay ningún problema en conceder S a B,

ya que A ha terminado y C tiene todo lo que necesita. Aunque B se
bloqueara al solicitar T, no se produciría interbloqueo; B simplemente
esperaría hasta que terminara C.

TEMA 6. ADMISTRACIÓN DE LA MEMORIA [YRAO94]

Durante este nuevo tema nos enfrentaremos con el problema de la
gestión de la memoria. Haremos un breve estudio preliminar de las
posibles alternativas y variantes a la hora de organizar y administrar el
espacio de direcciones de un sistema. Esta primera toma de contacto
nos servirá de excusa para introducir algunos conceptos generales,
que se irán desarrollando luego.

Empezaremos por el tipo de gestión más básico, el de los sistemas de

monoprogramación que apenas necesitan de ninguna organización. La
irrupción de los sistemas multiprogramados hace necesario tomar
decisiones sobre aspectos tan diversos como cuánto espacio se
dedica a cada proceso, de qué modo se le asigna, en qué lugar se
ubica, durante cuánto tiempo permanece en memoria, qué sucede si
no existe suficiente espacio o cómo se protege frente a accesos
ajenos. Todos estos factores serán valorados primero para técnicas de
asignación contigua(particiones estáticasy dinámicas) y para métodos
de asignación no contigua (paginación, segmentacióny segmentación
paginada). También se discutirá el soporte hardware, y el grado de
protección y compartición que es posible con cada uno de los
esquemas. Dentro del segundo paquete de estrategias de
administración de la memoria tendrán un particular interés los
esquemas de traducción de direcciones, por su repercusión en el
tiempo efectivo de acceso a memoria y, por tanto, en el rendimiento
del sistema.
6.1 La organización y gestión de la memoria. Conceptos generales
[DEIT93][LIST86][MILE94][STAL95]

Para que un proceso pueda ejecutarse debe estar ubicado en la

memoria principal del ordenador. Una parte del sistema operativo se
va a encargar de gestionar la memoria principal, de forma que los
procesos puedan residir en la memoria sin conflictos. La gestión de la
memoria implica varias tareas, una de ellas es llevar un registro de qué
zonas están libres (es decir, no están siendo utilizadas por ningún
proceso), y qué zonas están ocupadas por qué procesos. Otra tarea
importante surge en sistemas en los que no todos los procesos, o no
todo el código y datos de un proceso, se ubican en la memoria
principal. En estos sistemas, a menudo se debe pasar parte, o la
totalidad del código y datos de un proceso, de memoria a disco, o
viceversa; siendo el sistema operativo responsable de esta tarea. De
esta forma se libera al usuario de realizar estas transferencias de
información, de las cuales no es consciente.

Otros dos temas importantes en la gestión de la memoria son el de la

carga de los programas de disco a memoria y el de la protección.
Desde el momento en que varios procesos deben compartir la
memoria del ordenador surge el problema de la protección. En
general, se pretende que un proceso no pueda modificar las
direcciones de memoria en las que no reside. Esto es así ya que en
las direcciones de memoria donde no está ubicado el proceso pueden
residir otros procesos, o código o estructuras de datos del S.O. Si un
proceso puede modificar indiscriminadamente la memoria, podría, por
ejemplo, cambiar el valor de una dirección de memoria donde residiera
una variable de otro proceso, con la consecuente ejecución incorrecta
del proceso propietario de la variable. Algunos sistemas ni siquiera
permiten que un proceso pueda leer las direcciones de memoria en las
que no reside, con esto se consigue privacidad sobre el código y datos
de los procesos. Conforme avance este tema y el siguiente se
profundizará en todos estos aspectos.

Existen varias formas de gestionar la memoria. Por lo común, la forma

de gestión dependerá de la máquina virtual que se quiera proporcionar
y del hardware subyacente. Con independencia de la forma de gestión
es necesario decidir qué estrategias se deben utilizar para obtener un
rendimiento óptimo. Las estrategias de administración de la memoria
determinan el comportamiento de una organización de memoria
determinada cuando se siguen diferentes políticas: ¿ Cuándo se coge
un nuevo programa para colocarlo en la memoria ? ¿ Se coge el
programa cuando el sistema lo necesita, o se intenta anticiparse a las
peticiones del sistema ? ¿ En qué lugar de la memoria principal se
coloca el siguiente programa por ejecutar ? ¿ Se colocan los
programas lo más cerca posible unos de otros en los espacios
disponibles de la memoria principal para reducir al mínimo el
desperdicio de espacio, o se colocan lo más rápido posible para
reducir el tiempo empleado en tomar la decisión ?
Los sistemas actuales son en su mayor parte sistemas con
almacenamiento virtual, muchas de la formas de gestión estudiadas en
este tema tienen principalmente valor histórico, pero sientan las bases
de los sistemas actuales.

Jerarquía de la memoria

Los programas y datos necesitan estar en la memoria principal para

ser ejecutados, o para poder ser referenciados. Los programas o datos
que no se necesitan de inmediato pueden guardarse en la memoria
secundaria hasta que se necesiten, y en ese momento se transfieren a
la memoria principal para ser ejecutados o referenciados. Los soportes
de memoria secundaria, como cintas o discos, son en general menos
caros que la memoria principal, y su capacidad es mucho mayor.
Normalmente, es mucho más rápido el acceso a la memoria principal
que a la secundaria.

En los sistemas con varios niveles de memoria hay muchas

transferencias constantes de programas y datos entre los distintos
niveles. Estas transferencias consumen recursos del sistema, como
tiempo de la CPU, que de otro modo podrían utilizarse
provechosamente.

En los años sesenta se hizo evidente que la jerarquía de la memoria

podía extenderse un nivel más, con una clara mejora del rendimiento.
Este nivel adicional, la memoria caché, es una memoria de alta
velocidad, mucho más rápida que la memoria principal. La memoria
caché es extremadamente cara, si se compara con la principal, por lo
que sólo se utilizan memorias caché relativamente pequeñas. La figura
6.1 muestra la relación que existe entre la memoria caché, la principal
y la secundaria.

La memoria caché introduce un nivel adicional de transferencia de

información en el sistema. Los programas en memoria principal se
pasan a la memoria caché antes de ejecutarse. En la memoria caché
se pueden ejecutar mucho más rápido que en la principal. La
esperanza de los diseñadores es que el trabajo extra requerido por la
transferencia de programas sea mucho menor que el incremento del
rendimiento obtenido por la ejecución más rápida en la caché.
6.2 Gestión de la memoria en los sistemas monoprogramados
[MILE94] [TANE93]

En los sistemas de monoprogramación sólo existe un proceso de

usuario, que disfruta de todos los recursos del ordenador. Esto va a
simplificar notablemente la gestión de la memoria, ya que ésta sólo
debe ser compartida por los programas del sistema operativo, y por el
único proceso de usuario existente. Esto se muestra en la figura 6.2.
Dependiendo de detalles de diseño, el sistema operativo ocupará la
parte baja de la memoria RAM, como se muestra en la figura 6.2 (a); o
la parte alta de la memoria ROM, como se muestra en la figura 6.2 (b).
El PC de IBM ubica parte del sistema operativo en RAM, y los
gestores de dispositivos en ROM; a esta última parte se le llama BIOS
(Basic Input/Output System, sistema básico de entrada/salida), esto
último se ilustra en la figura 6.2 (c).

Si el usuario conoce la ubicación en la memoria del sistema operativo,

entonces puede escribir programas en términos de direcciones
absolutas de memoria. Una dirección absoluta de memoria es una
dirección física (es decir, real) de la memoria. En contraposición se
tienen las direcciones relativas. Un programa está escrito en término
de direcciones relativas cuando se escribe suponiendo que empieza a
cargarse en la dirección cero de la memoria. Por lo general, los
usuarios escriben programas en lenguajes de alto nivel, por lo que son
los traductores los encargados de generar las direcciones que ocupan
las variables, procedimientos, etc, en la memoria. Los compiladores no
generan direcciones absolutas de memoria, pues no saben dónde se
almacenarán los procesos.

Por lo común, los sistemas operativos monousuario de

monoprogramación (muy comunes en las microcomputadoras) no
tienen protección de la memoria. Por lo tanto, el único proceso de
usuario que existe en la memoria, puede modificar posiciones de
memoria pertenecientes al sistema operativo, esto provocaría errores
al ejecutarse la zona modificada. La protección se puede realizar
mediante un registro de límite integrado en la CPU. Si se tiene un
esquema como el de la figura 6.2 (b) el registro de límite contendrá la
dirección de inicio de carga del S.O. El hardware, en tiempo de
ejecución, verifica que las direcciones generadas por el proceso de
usuario no son superiores al valor del registro de límite. En caso de ser
superior, el proceso de usuario intenta acceder al S.O., esto provoca
una interrupción hardware que gestiona el S.O., normalmente
eliminando al proceso.

TEMA 7: MEMORIA VIRTUAL

En el tema anterior sólo se ha considerado la posibilidad de mantener
la totalidad del proceso en memoria para poderlo ejecutar. Ahora
veremos que las técnicas de asignación no-contigua de memoria
abren una nueva posibilidad de gestión de memoria: la memoria
virtual. Hablaremos de los motivos y ventajas que nos reporta la
ejecución de un programa parcialmente cargado en memoria.

A partir de aquí, nos dedicaremos a examinar el tipo de actuaciones

que deberán incorporar los sistemas operativos para la gestión de la
memoria virtual, con el fin de minimizar la proporción de fallos de
páginas que pueden ocurrir. La paginación bajo demanda

A continuación consideraremos la posibilidad de que no exista ningún

marco de página libre donde ubicar una nueva página. Esta decisión
traerá consigo una ramificación de cuestiones, tales como la
repercusión otra vez en el tiempo de acceso, y el desarrollo de
algoritmos de reemplazo de páginasy de asignación de marcos. Para
cada uno de estos algoritmos se realizará una reflexión sobre su
funcionamiento, y valoración de su rendimiento.

Una revisión más profunda sobre las situaciones que provocan

reemplazo, y el número de marcos dedicados a cada proceso, nos
conducirán al peligro que entraña la altísima tasa de fallos de página
denominada hiperpaginación. Estudiaremos sus causas y cómo se
puede paliar esta molesta problemática, por ejemplo a través del
conjunto de trabajo. Será necesario acudir al concepto de localidad,
por ser el principio en el que se basa esta estrategia. Concluiremos
nuestro estudio sobre la hiperpaginación proponiendo una
aproximación más simple que tan sólo considera la frecuencia de
fallos de página. Vistos todos los aspectos, estrategias y políticas
relativas a la gestión de la memoria estaremos en condiciones para
realizar una valoración sobre el parámetro tamaño de página.

7.1 Motivaciones y Ventajas [SILB94] [BIC88]

En el tema anterior sólo hemos considerado la posibilidad de que la

totalidad del espacio de direcciones lógicas de un proceso se
encuentre en memoria física antes de que el proceso se pueda
ejecutar. Esta restricción parece necesaria y razonable, pero es
lamentable, ya que limita el tamaño de un programa al tamaño de la
memoria física.

De hecho, al examinar programas reales nos percatamos de que, en

muchos casos, no se requiere el programa completo. Por ejemplo:
A menudo los programas contienen código para tratar condiciones de
error poco frecuentes. Como en la práctica estos errores rara vez
ocurren, o no se presentan, este código casi nunca se ejecuta.

A las matrices, listas y tablas frecuentemente se les asigna más

memoria de la que necesitan realmente. Pueden declararse matrices
de 100 por 100 elementos, aunque pocas veces sea mayor de 10 por
10 elementos. Una tabla de símbolos de un ensamblador puede tener
espacio para 3000 símbolos, aunque el programa típico tenga menos
de 200 símbolos.

Ciertas opciones y características de un programa rara vez se usan,

como la opción de un editor que convierte minúsculas en mayúsculas
todos los caracteres del texto marcado.
Incluso en aquellos casos donde se necesita todo el programa, es
probable que no se requiera todo al mismo tiempo. La capacidad de
ejecutar un programa que se encuentra parcialmente en memoria
tendría varias ventajas:

Un programa ya no estaría restringido por la cantidad de memoria

física disponible. Los usuarios podrían escribir programas para un
espacio de direcciones virtuales muy grande, simplificando las labores
de programación.

Como cada programa de usuario ocuparía menos memoria física,

podrían ejecutarse más programas al mismo tiempo, aumentando la
utilización de la CPU y la productividad, pero sin incrementar el tiempo
de respuesta.
Se requeriría menos E/S para cargar o intercambiarcada uno de los
programas de usuario, por lo que se ejecutarían más rápido.

De esta manera, un programa en ejecución que no se encuentre

totalmente en memoria beneficiaría tanto al usuario como al sistema.

La memoria virtual es la separación de la memoria lógica del usuario

de la memoria física. Esta separación permite proporcionar a los
programadores una gran memoria virtual cuando sólo se dispone de
una memoria física más pequeña. La memoria virtual facilita las tareas
de programación, ya que el programador no se tiene que preocupar
por la cantidad de memoria física disponible.

7.2 Estrategias de la Administración de Memoria Virtual [DEIT93]

[STAL95]
De las diversas organizaciones de memoria tratadas en el tema
anterior únicamente las que realizan una asignación no contigua
(paginación, segmentación y segmentación paginada) del
almacenamiento permiten implantar una administración virtual de la
memoria. Para cualquiera de las tres formas de organizar esta
memoria virtual habrá que determinar:

Estrategias de obtención. Determinan cuándo se debe transferir una

página o un segmento del almacenamiento secundaria al primario. Las
estrategias de obtención por demanda esperan a que un proceso en
ejecución haga referencia a una página o a un segmento antes de
traerla/lo. Los esquemas de obtención anticipada intentan determinar
por adelantado a qué páginas o segmentos hará referencia un
proceso. Si la probabilidad de una referencia es alta y hay espacio
disponible, entonces se trae al almacenamiento primario la página o
segmento antes de que se haga la referencia explícita

Estrategias de colocación. Determinan en qué lugar de la memoria

principal se debe colocar una página o un segmento entrante. Los
sistemas de paginación vuelven trivial la decisión de colocación,
porque una página entrante se puede ubicar en cualquier marco de
página disponible. Los sistemas con segmentación requieren
estrategias de colocación como las tratadas en el contexto de los
sistemas de multiprogramación con particiones dinámicas.

Estrategias de reemplazo. Sirven para decidir qué página o segmento

se debe desplazar para dejar espacio a una página o segmento
entrante cuando está completamente ocupada la memoria principal.

Fuentes:

https://lsi.vc.ehu.eus/pablogn/docencia/manuales/SO/
TemasSOuJaen/MEMORIAVIRTUAL/
1y2Motivaciones,ventajasyEstrategiasdeadministracion.htm

https://www.utm.mx/~merg/prope/pdfs/SistOp.pdf

http://www.lsi.us.es/docencia/get.php?id=2840

https://www.fing.edu.uy/tecnoinf/maldonado/cursos/so/material/teo/
so01-introduccion.pdf