BOLIVARIANA DE VENEZUELA MINISTERIO DEL
PODER POPULAR PARA LA EDUCACIÓN
UNIVERSITARA
UNIVERSIDAD NACIONAL EXPERIMENTAL MARITIMA DEL CARIBE SISTEMAS
OPERATIVOS I
SOP-I 513 SECCIÓN: A
UNIDAD II
Nombre del archivo
Integrantes Equipo Pino,
Angelo / 28.404.765
Profesor:
Lic. Padilla P, Juan Vicente
Catia La Mar, 8 de mayo 2025
ÍNDICE GENERAL
1. CONCURRENCIA
1.1. Importancia de la Concurrencia
1.2. Mecanismos de Concurrencia en Sistemas Operativos
1.2.1. Procesos e Hilos
1.2.2. Planificación (Scheduling)
1.2.3. Sincronización
1.3. Problemas Comunes en Concurrencia
1.4. Ejemplo Práctico
2. TIPOS DE COMUNICACIÓN ENTRE PROCESOS
2.1. Comunicación Directa
2.1.1. Características Principales
2.1.2. Mecanismos de Implementación
2.1.3. Ventajas y Desventajas
2.1.4. Ejemplo Práctico
2.2. Comunicación Indirecta
2.2.1. Definición y Características
2.2.2. Mecanismos de Implementación
2.2.3. Ventajas y Desventajas
2.2.4. Ejemplo en Sistemas Operativos
3. MECANISMOS DE HARDWARE
3.1. Deshabilitar Interrupciones
3.1.1. Concepto y Funcionamiento
3.1.2. Ventajas y Limitaciones
3.1.3. Uso en Sistemas Operativos
3.2. Instrucción TEST-AND-SET
3.2.1. Definición y Propiedades
3.2.2. Uso en Exclusión Mutua
3.2.3. Implementación en Procesadores
3.3. Locks
3.3.1. Tipos de Locks
3.3.2. Implementación y Problemas Común
4. PROBLEMAS CLÁSICOS DE SINCRONIZACIÓN
4.1. Problema del Buffer Limitado
4.1.1. Definición y Solución con Semáforos
4.1.2. Aplicaciones en Sistemas Operativos
4.2. Problema de los Lectores y Escritores
4.2.1. Variantes y Soluciones
4.2.2. Desafíos y Aplicaciones
5. SECUENCIABILIDAD
5.1. Definición y Fundamentos
5.2. Mecanismos de Implementación
5.3. Importancia en Sistemas de Archivos
6. CRITERIOS DE PLANIFICACIÓN
6.1. Relativos al Rendimiento del Sistema
6.1.1. Utilización del CPU
6.1.2. Throughput y Tiempo de Retorno
6.1.3. Tiempo de Espera y Respuesta
7. DISCIPLINA DE PLANIFICACIÓN
7.1. Planificación Apropiativa
7.1.1. Características y Algoritmos
7.1.2. Ventajas y Desventajas
1.Concurrencia
La concurrencia es la capacidad de un sistema operativo para manejar múltiples tareas o procesos que
parecen ejecutarse simultáneamente, incluso si el sistema tiene un solo procesador. En realidad, en
sistemas con un único núcleo, el sistema operativo alterna rápidamente entre procesos (mediante
planificación o scheduling), dando la ilusión de ejecución paralela.
En sistemas con múltiples núcleos o procesadores, la concurrencia puede lograrse mediante ejecución
paralela real.
Importancia de la Concurrencia
Mejora el rendimiento: Permite que varias aplicaciones se ejecuten sin bloquear el sistema.
Maximiza el uso del CPU: Evita que el procesador permanezca inactivo mientras espera operaciones de
E/S.
Facilita la programación multitarea: Permite a los desarrolladores diseñar aplicaciones que realicen
múltiples operaciones en "paralelo".
Mecanismos de Concurrencia en Sistemas Operativos
Los sistemas operativos implementan concurrencia mediante:
a) Procesos e Hilos
Procesos: Unidades independientes de ejecución con su propio espacio de memoria.
Hilos (threads): Subprocesos dentro de un proceso que comparten memoria, permitiendo mayor
eficiencia.
b) Planificación (Scheduling)
El scheduler del SO decide qué proceso/hilo se ejecuta en un momento dado. Algoritmos comunes:
Round Robin (turnos equitativos).
Prioridades (tareas críticas primero).
c) Sincronización
Mecanismos para evitar condiciones de carrera (race conditions) y garantizar coherencia:
Semáforos (contadores que controlan acceso).
Mutexes (bloqueos exclusivos).
Monitores (estructuras de alto nivel para sincronización).
Problemas Comunes en Concurrencia
Race Conditions: Ocurre cuando dos procesos acceden a un recurso compartido sin sincronización.
Deadlocks: Bloqueo mutuo donde dos procesos esperan indefinidamente por recursos.
Inanición (Starvation): Un proceso no obtiene recursos suficientes para ejecutarse.
Ejemplo Práctico
En un servidor web:
Múltiples hilos manejan solicitudes HTTP concurrentes.
Sincronización con mutexes evita que dos hilos modifiquen la misma caché al mismo tiempo.
2.Tipos de Comunicación entre procesos
2.1.Comunicación Directa
La comunicación directa ocurre cuando dos procesos se comunican explícitamente mencionando el
nombre o identificador del otro. Es decir, el proceso emisor y el proceso receptor deben conocerse
mutuamente para establecer la comunicación. Este tipo de IPC requiere un enlace directo entre los
procesos, lo que facilita una comunicación más estructurada pero menos flexible en comparación con la
comunicación indirecta.
Características Principales
Identificación Explícita:
El proceso emisor especifica directamente el destino (send(P, mensaje)).
El proceso receptor indica de quién espera recibir (receive(Q, mensaje)).
Enlace Automático:
Se establece un canal de comunicación dedicado entre los dos procesos.
Simetría o Asimetría:
Simétrica: Ambos procesos deben nombrarse mutuamente (ej: send(P, mensaje) y receive(Q, mensaje)).
Asimétrica: Solo el emisor nombra al receptor, pero el receptor puede aceptar mensajes de cualquier
proceso.
Acoplamiento Fuerte:
Los procesos dependen directamente uno del otro. Si uno falla, la comunicación se interrumpe.
Mecanismos de Comunicación Directa
Algunos métodos comunes para implementar comunicación directa incluyen:
Tuberías con Nombre (Named Pipes):
A diferencia de las tuberías anónimas, las tuberías con nombre permiten comunicación bidireccional
entre procesos no relacionados.
Sockets (En un Solo Sistema):
Los sockets pueden usarse para comunicación local entre procesos en la misma máquina.
Señales (Signals):
Un proceso puede enviar una señal directamente a otro usando su PID (Process ID).
Llamadas al Sistema Específicas:
Algunos sistemas operativos proporcionan llamadas como send() y receive() para comunicación directa.
Ventajas y Desventajas
Ventajas
Comunicación clara y estructurada.
Bajo overhead en comparación con métodos indirectos.
Útil para aplicaciones con procesos bien definidos.
Desventajas
Menos flexible (requiere conocer el PID o nombre).
Si un proceso termina, la comunicación se pierde.
No escala bien en sistemas con muchos procesos.
Ejemplo Práctico
Supongamos dos procesos, A y B, donde A envía un mensaje a B:
// Proceso A (Emisor)
send(B, "Hola, proceso B");
// Proceso B (Receptor)
receive(A, buffer);
En este caso, A y B deben conocer sus identificadores para comunicarse.
2.2.Indirecta.
Definición de Comunicación Indirecta
La comunicación indirecta es un método en el que los procesos no se refieren explícitamente al receptor
o emisor, sino que utilizan una estructura compartida (como un buzón o cola de mensajes) para enviar y
recibir datos. A diferencia de la comunicación directa, donde los procesos deben conocer el identificador
(PID) del otro, aquí la interacción se realiza a través de un canal común.
Características Principales
Desacoplamiento entre procesos:
Los procesos no necesitan conocer la identidad del otro.
El emisor y el receptor solo interactúan con el buzón intermedio.
Sincronización flexible:
Puede ser bloqueante (el proceso espera hasta recibir/respuesta) o no bloqueante (continúa su
ejecución).
Persistencia de los mensajes:
Algunas implementaciones permiten que los mensajes permanezcan en el buzón incluso después de
que el proceso receptor los lea.
Unidireccional o bidireccional:
Dependiendo del diseño, un buzón puede permitir comunicación en uno o ambos sentidos.
Mecanismos de Comunicación Indirecta
Buzones (Mailboxes)
Son objetos del kernel que almacenan mensajes temporalmente.
Cada buzón tiene un identificador único.
Ejemplo: En sistemas UNIX, se pueden implementar con pipes con nombre (FIFOs).
Colas de Mensajes (Message Queues)
Permiten el almacenamiento estructurado de mensajes con prioridades.
Usadas en sistemas como POSIX Message Queues o en Windows (MSMQ).
Puertos (Ports)
Utilizados en sistemas distribuidos (ej: sockets en TCP/IP).
Un proceso escucha en un puerto y otro envía datos a ese puerto.
Ventajas
Mayor flexibilidad: Un mismo buzón puede ser usado por múltiples procesos.
Escalabilidad: Ideal para sistemas distribuidos donde los procesos están en diferentes máquinas.
Reducción de acoplamiento: Los procesos no dependen directamente unos de otros.
Desventajas
Overhead adicional: El uso de intermediarios puede ralentizar la comunicación.
Posibles cuellos de botella: Si muchos procesos acceden al mismo buzón.
Complejidad en la gestión: Requiere mecanismos para evitar condiciones de carrera.
Ejemplo Práctico en Sistemas Operativos
En Linux, la comunicación indirecta se puede lograr con:
Pipes con nombre (mkfifo):
bash
mkfifo /tmp/mi_buzon
Un proceso escribe en el pipe y otro lee desde él.
Message Queues (System V o POSIX):
msgget(key, IPC_CREAT); // Crear una cola de mensajes
msgsnd(); // Enviar mensaje
msgrcv(); // Recibir mensaje
3.0.Mecanismo de Hardware.
En los sistemas operativos, los mecanismos de hardware son fundamentales para garantizar la exclusión
mutua y la sincronización entre procesos. Estos mecanismos permiten que el sistema operativo o los
procesos en ejecución realicen operaciones críticas sin interferencias, evitando condiciones de carrera y
asegurando la consistencia de los datos.
Uno de los mecanismos más básicos para lograr la exclusión mutua es deshabilitar interrupciones, el cual
evita que el procesador sea interrumpido durante la ejecución de una sección crítica. Sin embargo, este
enfoque tiene limitaciones y riesgos, por lo que su uso está restringido principalmente al núcleo del
sistema operativo.
3.1.Deshabilitar Interrupciones
3.1. Deshabilitar Interrupciones
Concepto
Deshabilitar interrupciones es una técnica utilizada en sistemas operativos para garantizar que
un proceso o hilo ejecute una sección crítica sin ser interrumpido por eventos externos. Cuando
las interrupciones están desactivadas, el procesador no responde a señales de hardware
(como las de dispositivos de E/S) ni a interrupciones de software (como las llamadas al
sistema), lo que evita cambios de contexto no deseados durante la ejecución de código crítico.
Funcionamiento
Antes de entrar a la sección crítica, el sistema operativo desactiva todas las interrupciones
mediante instrucciones de hardware específicas (por ejemplo, la instrucción CLI en x86).
Se ejecuta el código crítico sin riesgo de que otro proceso o una rutina de interrupción
modifique los datos compartidos.
Al salir de la sección crítica, se reactivan las interrupciones (con una instrucción como STI en
x86), permitiendo que el sistema continúe su ejecución normal.
Ventajas
Sencillez: Es fácil de implementar en sistemas con un solo núcleo.
Eficacia: Garantiza que ninguna interrupción afecte la ejecución de la sección crítica.
Desventajas y Limitaciones
Inviable en sistemas multiprocesador: Solo funciona en sistemas con un único núcleo, ya que
otros procesadores pueden acceder a la sección crítica incluso con interrupciones
deshabilitadas en uno de ellos.
Peligro de inanición (starvation): Si un proceso no libera el procesador (por un bucle infinito o
error), el sistema puede quedar bloqueado.
Degradación del rendimiento: Desactivar interrupciones por mucho tiempo afecta la
capacidad de respuesta del sistema a eventos importantes.
Uso en Sistemas Operativos
Este mecanismo se emplea principalmente en el núcleo del sistema operativo para proteger
estructuras de datos críticas durante períodos muy cortos. Por ejemplo:
Durante la manipulación de colas de planificación.
Al actualizar estructuras de memoria compartida.
Sin embargo, debido a sus riesgos, no se recomienda para programación a nivel de usuario. En
su lugar, se utilizan mecanismos más avanzados como semáforos, mutex o instrucciones
atómicas (e.g., test-and-set, compare-and-swap).
3.2.Instrucción TEST-AND-SET.
La instrucción TEST-AND-SET (TAS) es una operación atómica proporcionada por muchos
procesadores para soportar la sincronización en sistemas multiprocesador o multihilo. Su
función principal es leer el valor de una variable en memoria, modificarla y devolver su valor
original, todo en una única operación indivisible.
Definición y Funcionamiento
La operación se puede definir en pseudocódigo de la siguiente manera:
function TestAndSet(boolean *lock) {
boolean original = *lock; // Guarda el valor actual
*lock = true; // Establece el lock en verdadero
return original; // Retorna el valor original
Propiedades clave:
Atómica: No puede ser interrumpida durante su ejecución.
Modificación condicional: Cambia el valor del lock solo si está disponible.
Retorno del estado anterior: Indica si el lock estaba libre (false) o ocupado (true).
Uso en Exclusión Mutua
Esta instrucción se utiliza para implementar cerraduras (spinlocks), donde un proceso espera
activamente (busy-waiting) hasta que el lock se libera:
while (TestAndSet(&lock)) {
// Espera activa (spinlock)
// Sección crítica
lock = false; // Libera el lock
Ventajas y Desventajas
Ventajas:
Simple y eficiente en sistemas con soporte hardware.
Garantiza exclusión mutua sin intervención del sistema operativo.
Desventajas:
Busy-waiting: Consume CPU mientras espera (ineficiente en sistemas monoprocesador).
Puede causar inanición (starvation) si no se maneja adecuadamente.
Implementación en Procesadores Modernos
Muchas arquitecturas incluyen instrucciones similares:
x86: XCHG (intercambio atómico) o LOCK prefix.
ARM: LDREX/STREX (Load-Exclusive/Store-Exclusive).
3.3.LOCK.
Los locks son estructuras de sincronización que permiten a los procesos o hilos acceder a
recursos compartidos de manera exclusiva, evitando conflictos. Cuando un proceso adquiere
un lock, ningún otro puede acceder al recurso hasta que sea liberado.
3.3.1. Tipos de Locks
Spinlock (Bloqueo por espera activa)
El proceso que espera el lock permanece en un bucle (spin) verificando continuamente su
disponibilidad.
Eficiente en sistemas multiprocesador cuando la espera es corta.
Consume CPU mientras espera.
Sleep Lock (Bloqueo por suspensión)
Si el lock no está disponible, el proceso se suspende y se coloca en una cola de espera.
Más eficiente en sistemas monoprocesador o cuando la espera es larga.
Read-Write Locks (Cerrojos de Lectura-Escritura)
Permiten múltiples lecturas simultáneas, pero solo una escritura exclusiva.
Mejora el rendimiento en sistemas con muchas operaciones de lectura.
3.3.2. Implementación de Locks
Los locks se implementan usando instrucciones atómicas proporcionadas por el hardware. Por
ejemplo, un spinlock puede usar Test-and-Set:
void spinlock_acquire(int *lock) {
while (test_and_set(lock) == 1); // Espera activa
}
void spinlock_release(int *lock) {
*lock = 0; // Libera el lock
Deadlock: Ocurre cuando dos o más procesos se bloquean mutuamente esperando un lock.
Inanición (Starvation): Un proceso nunca obtiene el lock debido a la prioridad de otros.
Overhead: El uso excesivo de locks puede reducir el rendimiento del sistema.
3.3.4. Alternativas Modernas
Algunos sistemas utilizan técnicas como:
Transacciones de Memoria (Hardware Transactional Memory - HTM): Permite ejecutar
secuencias críticas de manera atómica sin locks.
RCU (Read-Copy-Update): Técnica de sincronización sin bloqueo para estructuras de datos.
4.0.Problemas clásicos de sincronización.
En los sistemas operativos, la sincronización de procesos es fundamental para garantizar la
correcta ejecución de programas que comparten recursos. Los problemas clásicos de
sincronización son escenarios recurrentes que ilustran las dificultades que surgen cuando
múltiples procesos o hilos acceden concurrentemente a datos compartidos. Estos problemas
incluyen:
El problema del buffer limitado (Productor-Consumidor)
El problema de los lectores y escritores
El problema de los filósofos cenando
Estos modelos ayudan a entender y resolver conflictos como condiciones de carrera,
interbloqueos (deadlocks) e inanición (starvation). A continuación, se detallará el problema del
buffer limitado.
4.1.El problema del buffer limitado.
Definición
El problema del buffer limitado, también conocido como problema del productor-consumidor, es
un escenario clásico de sincronización donde dos tipos de procesos (productores y
consumidores) comparten un buffer de tamaño fijo.
Productor: Genera datos y los coloca en el buffer.
Consumidor: Extrae y procesa los datos del buffer.
El desafío radica en coordinar ambos procesos para evitar:
Acceso simultáneo al buffer (condiciones de carrera).
Desbordamiento (overflow) si el productor escribe en un buffer lleno.
Subdesbordamiento (underflow) si el consumidor lee un buffer vacío.
Solución con semáforos
La solución clásica, propuesta por Edsger Dijkstra, utiliza semáforos para garantizar la
exclusión mutua y sincronización:
Semáforo mutex (inicializado en 1): Controla el acceso exclusivo al buffer.
Semáforo lleno (inicializado en 0): Cuenta los espacios ocupados en el buffer.
Semáforo vacío (inicializado en N): Cuenta los espacios disponibles.
Código de ejemplo (pseudocódigo):
python
# Inicialización
mutex = Semáforo(1)
lleno = Semáforo(0)
vacío = Semáforo(N)
# Productor
def productor():
while True:
dato = producir_dato()
vacío.wait() # Espera si no hay espacio
mutex.wait() # Entra en la sección crítica
buffer.agregar(dato)
mutex.signal() # Sale de la sección crítica
lleno.signal() # Avisa que hay un dato más
# Consumidor
def consumidor():
while True:
lleno.wait() # Espera si no hay datos
mutex.wait() # Entra en la sección crítica
dato = buffer.extraer()
mutex.signal() # Sale de la sección crítica
vacío.signal() # Libera un espacio
procesar(dato)
Posibles errores y consideraciones
Deadlock: Si se altera el orden de los semáforos (ej. mutex antes que vacío).
Inanición: Si un proceso no logra acceder al buffer (poco probable con semáforos justos).
Implementaciones modernas: Se usan monitores (en Java) o colas concurrentes (en Python
con Queue).
Aplicaciones en sistemas operativos
Este modelo se aplica en:
Buffers de impresión (spooling).
Pipes en shells de Unix.
Streaming de datos (ej.: reproducción de video en búfer).
4.2.El problema de los lectores y escritores
Definición
El problema de los lectores y escritores modela el acceso a un recurso compartido (ej: un
archivo o base de datos) donde:
Lectores: Procesos que solo leen el recurso (pueden acceder simultáneamente).
Escritores: Procesos que modifican el recurso (requieren acceso exclusivo).
El desafío es garantizar que:
Múltiples lectores puedan acceder al mismo tiempo.
Solo un escritor acceda en exclusiva, sin lectores u otros escritores concurrentes.
Variantes del problema
Primera variante (favorece a lectores): Si un lector espera, puede entrar incluso si hay un
escritor en espera (riesgo de inanición para escritores).
Segunda variante (favorece a escritores): Los escritores tienen prioridad, evitando inanición
pero pudiendo retrasar lectores.
Solución con semáforos
Una implementación clásica (primera variante) usa:
Semáforo mutex: Protege la variable lectores (contador de lectores activos).
Semáforo escritura: Garantiza exclusión para escritores.
Pseudocódigo (para lectores):
wait(mutex);
lectores++;
if (lectores == 1) wait(escritura); // Primer lector bloquea escritores
signal(mutex);
// Leer recurso compartido
wait(mutex);
lectores--;
if (lectores == 0) signal(escritura); // Último lector libera escritores
signal(mutex);
Para escritores:
wait(escritura);
// Escribir en el recurso
signal(escritura);
Desafíos
Inanición: En la primera variante, escritores pueden quedar indefinidamente bloqueados si
hay flujo constante de lectores.
Justicia: Soluciones como colas FIFO o semáforos con prioridad equilibran el acceso.
Aplicaciones en sistemas operativos
Este modelo se usa en:
Sistemas de archivos: Múltiples procesos leen, pero las escrituras son exclusivas.
Bases de datos: Transacciones concurrentes con locks de lectura/escritura.
5.0.Secuenciabilidad.
Definición y Fundamentos
La secuenciabilidad se define como la propiedad que asegura que el resultado de ejecutar
concurrentemente un conjunto de transacciones (o procesos) sea equivalente al resultado de
ejecutarlas en algún orden secuencial. Esto implica que, aunque las operaciones se intercalen,
el efecto final debe ser el mismo que si se hubieran realizado en serie.
Según Silberschatz, Galvin y Gagne en "Operating System Concepts", la secuenciabilidad es
crucial para mantener la consistencia de los datos en entornos multiusuario o multiproceso,
donde múltiples accesos a archivos o recursos pueden generar conflictos.
Ejemplo Práctico
Supongamos dos procesos que acceden a un archivo:
Proceso A: Escribe "ABC" en el archivo.
Proceso B: Escribe "123" en el archivo.
Sin control de secuenciabilidad, el resultado podría ser inconsistente (ej. "A1B23C"). Un
sistema secuenciable garantiza que el resultado sea "ABC123" o "123ABC", pero no una
mezcla arbitraria.
Mecanismos de Implementación
Para lograr secuenciabilidad, los sistemas operativos emplean:
Cerrojos (Locks): Bloquean recursos para acceso exclusivo.
Semáforos: Sincronizan procesos para evitar condiciones de carrera.
Protocolos de Two-Phase Locking (2PL): Aseguran que las transacciones adquieran y liberen
locks en fases bien definidas.
Timestamp Ordering: Asigna marcas de tiempo para ordenar operaciones.
Importancia en Sistemas de Archivos
En el manejo de archivos, la secuenciabilidad evita corrupción de datos cuando múltiples
procesos modifican un mismo archivo. Por ejemplo, en sistemas como NTFS (Windows) o ext4
(Linux), se utilizan mecanismos de bloqueo para garantizar coherencia.
6.0.Criterios de Planificación.
La planificación de procesos es una función fundamental del sistema operativo, encargada de
decidir qué proceso en estado de listo debe ser ejecutado por el CPU. Para ello, se utilizan
diversos criterios que garantizan un equilibrio entre el rendimiento del sistema, la equidad y la
eficiencia. Estos criterios se dividen en dos categorías principales:
Relativos al rendimiento del sistema (objetivos globales del sistema operativo).
Relativos al usuario (tiempo de respuesta, equidad, plazo de finalización, etc.).
A continuación, se detallan los criterios relativos al rendimiento del sistema
6.1.Relativos al rendimiento del Sistema.
Estos criterios buscan optimizar el uso de los recursos del sistema, como el CPU, la memoria y
los dispositivos de E/S, para lograr un funcionamiento eficiente. Entre los principales
indicadores se encuentran:
1. Utilización del CPU
Definición: Porcentaje de tiempo en que el CPU está ocupado ejecutando procesos.
Objetivo: Maximizar su uso para evitar tiempos de inactividad (idle).
Relevancia: Un CPU subutilizado indica ineficiencia, mientras que una sobrecarga puede
generar cuellos de botella.
Ejemplo: En sistemas por lotes (batch), se busca mantener una utilización cercana al 100%.
2. Rendimiento (Throughput)
Definición: Número de procesos completados por unidad de tiempo (ej. procesos/segundo).
Objetivo: Aumentar la cantidad de trabajos procesados sin degradar otros criterios.
Relevancia: Es clave en entornos de alto volumen, como servidores y centros de datos.
Ejemplo: Un sistema con un throughput alto puede manejar múltiples solicitudes web
simultáneamente.
3. Tiempo de Retorno (Turnaround Time)
Definición: Tiempo total desde que un proceso se envía al sistema hasta que finaliza (incluye
espera, ejecución y E/S).
Objetivo: Minimizarlo para acelerar la finalización de tareas.
Relevancia: Importante en sistemas por lotes y computación científica.
Fórmula:
Turnaround Time=Tiempo de Finalizacioˊn−Tiempo de Llegada
Turnaround Time=Tiempo de Finalizacioˊn−Tiempo de Llegada
4. Tiempo de Espera (Waiting Time)
Definición: Tiempo total que un proceso pasa en la cola de listos antes de ejecutarse.
Objetivo: Reducirlo para evitar el envejecimiento (starvation).
Relevancia: Afecta directamente la percepción de eficiencia del sistema.
Fórmula:
Waiting Time=Turnaround Time−Tiempo de Ejecucioˊn (Burst Time)
Waiting Time=Turnaround Time−Tiempo de Ejecucioˊn (Burst Time)
5. Tiempo de Respuesta (Response Time)
Definición: Tiempo transcurrido desde que se envía una solicitud hasta que se produce la
primera respuesta (no necesariamente la finalización).
Objetivo: Minimizarlo en sistemas interactivos (ej. terminales, interfaces gráficas).
Relevancia: Crítico para la experiencia del usuario en tiempo real.
6. Equidad (Fairness)
Definición: Distribución justa del tiempo de CPU entre todos los procesos.
Objetivo: Evitar que algunos procesos monopolizen el CPU.
Relevancia: Importante en sistemas multiusuario y servidores.
7.0.Como debe ser una disciplina de Planificación.
La planificación de procesos en un sistema operativo es fundamental para garantizar un uso
eficiente de los recursos del sistema, como el procesador (CPU), la memoria y los dispositivos
de entrada/salida (E/S). Una buena disciplina de planificación debe cumplir con los siguientes
criterios:
Equidad (Fairness): Todos los procesos deben tener acceso justo a la CPU, evitando que
algunos monopolizen los recursos en perjuicio de otros.
Eficiencia (Efficiency): El planificador debe minimizar el tiempo ocioso de la CPU y maximizar
su utilización.
Tiempo de respuesta (Response Time): En sistemas interactivos, los procesos deben recibir
atención rápida para garantizar una buena experiencia de usuario.
Tiempo de retorno (Turnaround Time): En sistemas por lotes, se debe minimizar el tiempo
total que tarda un proceso en ejecutarse desde su llegada hasta su finalización.
Previsibilidad (Predictability): El comportamiento del planificador debe ser consistente para
que los usuarios puedan estimar el rendimiento del sistema.
Escalabilidad (Scalability): El algoritmo debe funcionar eficientemente incluso con un gran
número de procesos.
Además, el planificador debe adaptarse al tipo de sistema (tiempo real, interactivo o por lotes) y
equilibrar las necesidades de los procesos de corta duración (I/O-bound) y los de larga
duración (CPU-bound).
7.1.Planificación Apropiativa.
La planificación apropiativa es una técnica en la que el sistema operativo puede interrumpir un
proceso en ejecución para asignar la CPU a otro proceso de mayor prioridad. A diferencia de la
planificación no apropiativa (donde un proceso mantiene la CPU hasta que finaliza o se
bloquea), este método permite una mejor distribución de los recursos y una mayor capacidad
de respuesta.
Características de la Planificación Apropiativa
Interrupción de procesos: El planificador puede detener un proceso en cualquier momento
(no solo cuando espera E/S o finaliza).
Prioridades dinámicas: Los procesos pueden cambiar de prioridad durante su ejecución,
permitiendo que el sistema reaccione a eventos importantes.
Respuesta rápida: Ideal para sistemas interactivos y de tiempo real, donde ciertas tareas
requieren atención inmediata.
Ventajas
✔ Mayor equidad: Evita que un proceso monopolice la CPU.
✔ Mejor tiempo de respuesta: Los procesos críticos pueden ejecutarse rápidamente.
✔ Adaptabilidad: Permite manejar procesos interactivos y de tiempo real de manera eficiente.
Desventajas
✖ Overhead (sobrecarga): Cambiar entre procesos requiere guardar y restaurar estados
(context switching), lo que consume recursos.
✖ Riesgo de inanición (starvation): Si no se manejan bien las prioridades, algunos procesos
pueden quedar indefinidamente en espera.
Algoritmos que usan Planificación Apropiativa
Round Robin (RR): Asigna un quantum de tiempo a cada proceso y lo interrumpe cuando se
agota.
Prioridades con apropiación: Si llega un proceso de mayor prioridad, el actual es
interrumpido.
Shortest Remaining Time First (SRTF): Se ejecuta el proceso con el menor tiempo restante,
apropiando la CPU si llega uno aún más corto.
fuentes bibbliograficas
1.0 y 1.1
Tanenbaum, A. S. y Bos, H. (2015). Modern Operating Systems (4ª ed.). Pearson.
Silberschatz, A., Galvin, P. B. y Gagne, G. (2018). Operating System Concepts (10ª ed.). Wiley.
Stallings, W. (2018). Operating Systems: Internals and Design Principles (9ª ed.). Pearson
2.0 y 2.1
anenbaum, A. S. (2015). Modern Operating Systems. Pearson.
Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating System Concepts. Wiley.
2.2
Tanenbaum, A. (2015). Modern operating systems (4ª ed.). Pearson.
Silberschatz, A., Galvin, P. y Gagne, G. (2018). Operating system concepts (10ª ed.). Wiley.
3.0 y 3.1
Tanenbaum, A. S. (2015). Modern Operating Systems. Pearson.
Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating System Concepts. Wiley.
Arquitectura x86: Instrucciones CLI y STI (Intel Manuals).
3.2
Tanenbaum, A. (2015). Modern Operating Systems. Pearson.
Silberschatz, A. (2018). Operating System Concepts. Wiley.
Intel® 64 and IA-32 Architectures Software Developer’s Manual.
3.3
Tanenbaum, A. S. (2015). Modern Operating Systems. Pearson.
Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating System Concepts. Wiley.
Arquitecturas x86/ARM: Manuales de instrucciones atómicas (CAS, TAS).
4.0 y 4.1
Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating System Concepts (10th ed.).
Wiley.
Tanenbaum, A. S., & Bos, H. (2015). Modern Operating Systems (4th ed.). Pearson.
Dijkstra, E. W. (1965). Cooperating Sequential Processes. Technological University Eindhoven
4.2
Silberschatz, A., Galvin, P., & Gagne, G. (2018). Operating System Concepts (10th ed.).
Wiley.
Tanenbaum, A. S. (2015). Modern Operating Systems (4th ed.). Pearson.
5.0
Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating System Concepts. Wiley.
Tanenbaum, A. S., & Bos, H. (2015). Modern Operating Systems. Pearson.
Artículos técnicos sobre sistemas de archivos y concurrencia en IEEE Xplore
6.0 y 6.1
Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating System Concepts (10th ed.).
Wiley.
Tanenbaum, A. S., & Bos, H. (2015). Modern Operating Systems (4th ed.). Pearson.
Stallings, W. (2018). Operating Systems: Internals and Design Principles (9th ed.). Pearson.
