Capítulo 3: Concepto de Proceso

Capítulo 3: Procesos

• Un sistema operativo ejecuta varios programas que se ejecutan como un proceso.
• Un proceso es un programa en ejecución y debe progresar de forma secuencial.
• No hay ejecución paralela de instrucciones de un único proceso.

Concepto de Proceso

• Múltiples partes componen un proceso.
• El código de programa también se llama sección de texto.
• Contador de programa y registros de procesador son parte de la actividad actual.
• Stack que contiene datos temporales como parámetros de función, direcciones de retorno y variables locales.
• La sección de datos contiene variables globales.
• Heap contiene memoria asignada dinámicamente durante el tiempo de ejecución.
• Un programa es una entidad pasiva almacenada en el disco (archivo ejecutable), el proceso está activo.
• Un programa se convierte en proceso cuando se carga un archivo ejecutable en la memoria.
• La ejecución del programa se inicia haciendo clic con el ratón en la GUI, introduciendo su nombre en la línea de comandos, etc.
• Un programa puede ser varios procesos considerando múltiples usuarios que ejecutan el mismo programa.

Estado del Proceso

• A medida que un proceso se ejecuta, cambia de estado:
• Nuevo: Se está creando el proceso.
• Ejecutando: Se están ejecutando las instrucciones.
• Esperando: El proceso está esperando que ocurra algún evento.
• Listo: El proceso está esperando a que se le asigne un procesador.
• Terminado: El proceso ha finalizado su ejecución.

Bloque de Control de Proceso (PCB)

• La información asociada a cada proceso, también llamada bloque de control de tarea.
• Estado del proceso: en ejecución, en espera, etc.
• Contador de programa: ubicación de la instrucción a ejecutar a continuación.
• Registros de la CPU: contenidos de todos los registros centrados en el proceso.
• Información de planificación de la CPU: prioridades, punteros de la cola de planificación.
• Información de gestión de la memoria: memoria asignada al proceso.
• Información de contabilidad: CPU utilizada, tiempo de reloj transcurrido desde el inicio, límites de tiempo.
• Información de estado de E/S: dispositivos de E/S asignados al proceso, lista de archivos abiertos.

Hilos

• Hasta ahora, el proceso tiene un solo hilo de ejecución.
• Se considera tener múltiples contadores de programa por proceso donde múltiples ubicaciones se ejecutan a la vez.
• Múltiples hilos de control forman hilos.
• Debe entonces tener almacenamiento para los detalles del hilo, múltiples contadores de programa en PCB.

Representación de Proceso en Linux

• Representado por la estructura C task_struct:
• pid t_pid /* identificador del proceso */
• long state /* estado del proceso */
• unsigned int time_slice /* información de planificación */
• struct task_struct parent / padre de este proceso */
• struct list_head children /* hijos de este proceso */
• struct files_struct files / lista de archivos abiertos */
• struct mm_struct mm / espacio de direcciones de este proceso */

Planificación de Procesos

• El planificador de procesos selecciona entre los procesos disponibles para la siguiente ejecución en el núcleo de la CPU.
• El objetivo es maximizar el uso de la CPU, cambiar rápidamente los procesos al núcleo de la CPU.
• Se mantienen colas de planificación de procesos.
• La cola de preparados es un conjunto de todos los procesos que residen en la memoria principal, listos y esperando para ejecutarse.
• Las colas de espera es un conjunto de procesos que esperan un evento (es decir, E/S).
• Los procesos migran entre las distintas colas.

Cambio de Contexto

• Se produce un cambio de contexto cuando la CPU cambia de un proceso a otro.
• Cuando la CPU cambia a otro proceso, el sistema debe guardar el estado del antiguo proceso y cargar el estado guardado para el nuevo proceso a través de un cambio de contexto.
• El contexto de un proceso está representado en el PCB.
• El tiempo de cambio de contexto es una sobrecarga pura; el sistema no realiza ningún trabajo útil mientras conmuta.
• Cuanto más complejo sea el SO y el PCB, más largo será el cambio de contexto.
• El tiempo depende del soporte del hardware.
• Algunos hardware proporcionan múltiples conjuntos de registros por CPU, múltiples contextos cargados a la vez.

Multitarea en Sistemas Móviles

• Algunos sistemas móviles (por ejemplo, la versión temprana de iOS) permiten que sólo se ejecute un proceso y que otros se suspendan.
• Debido al espacio real de la pantalla, la interfaz de usuario limita el iOS proporciona para un único proceso en primer plano controlado a través de la interfaz de usuario.
• Múltiples procesos en segundo plano: en la memoria, en ejecución, pero no en la pantalla, y con límites.
• Los límites incluyen una sola tarea corta, la recepción de la notificación de eventos, tareas específicas de larga duración como la reproducción de audio.
• Android ejecuta el primer plano y el segundo plano, con menos límites.
• El proceso en segundo plano utiliza un servicio para realizar tareas.
• El servicio puede seguir ejecutándose incluso si el proceso en segundo plano está suspendido.
• El servicio no tiene interfaz de usuario, utiliza poca memoria.

Operaciones en los Procesos

• El sistema debe proporcionar mecanismos para:
• Creación de procesos
• Terminación de procesos

Creación de Procesos

• El proceso padre crea procesos hijos, que a su vez crean otros procesos, formando un árbol de procesos.
• Generalmente, el proceso se identifica y se gestiona a través de un identificador de proceso (pid).
• Opciones para compartir recursos:
  • El padre y los hijos comparten todos los recursos.
  • Los hijos comparten un subconjunto de recursos del padre.
  • El padre y el hijo no comparten recursos.
• Opciones de ejecución:
  • El padre y los hijos se ejecutan concurrentemente.
  • El padre espera hasta que los hijos terminen.

Creación de Procesos (Cont.)

• Espacio de direcciones:
  • Hijo duplicado del padre
  • El hijo tiene un programa cargado en él
• Ejemplos de UNIX:
  • la llamada al sistema fork() crea un nuevo proceso
  • la llamada al sistema exec() se utiliza después de una fork() para reemplazar el espacio de memoria del proceso con un nuevo programa
  • El proceso padre llama a wait() esperando a que el hijo finalice

Terminación de Procesos

• El proceso ejecuta la última sentencia y luego solicita al sistema operativo que lo elimine usando la llamada al sistema exit().
  • Devuelve los datos de estado del hijo al padre (vía wait()).
  • Los recursos del proceso son desasignados por el sistema operativo.
• El padre puede terminar la ejecución de los procesos hijos usando la llamada al sistema abort(). Algunas razones para hacerlo:
  • El hijo ha excedido los recursos asignados.
  • La tarea asignada al hijo ya no es necesaria.
  • El padre está saliendo, y el sistema operativo no permite que un hijo continúe si su padre termina.
• Algunos sistemas operativos no permiten que el hijo exista si su padre ha terminado. Si un proceso termina, entonces todos sus hijos también deben ser terminados por terminación en cascada.
• La terminación es iniciada por el sistema operativo.
• El proceso padre puede esperar a la terminación de un proceso hijo utilizando la llamada al sistema wait(). La llamada devuelve la información de estado y el pid del proceso terminado.
• Si ningún padre está esperando (no invirtió wait()), el proceso es un zombie.
• Si el padre terminó sin invocar wait(), el proceso es un huérfano.

Jerarquía de Importancia del Proceso Android

• Los sistemas operativos móviles a menudo tienen que terminar los procesos para reclamar los recursos del sistema como la memoria. Desde el más importante hasta el menos importante:
  • Proceso en primer plano
  • Proceso visible
  • Proceso de servicio
  • Proceso en segundo plano
  • Proceso vacío
• Android comenzará a terminar los procesos que son menos importantes.

Arquitectura Multiproceso – Navegador Chrome

• Muchos navegadores web se ejecutan como un solo proceso (algunos todavía lo hacen).
• Si un sitio web causa problemas, todo el navegador puede colgarse o fallar.
• Google Chrome Browser es multiproceso con 3 tipos diferentes de procesos:
  • El proceso del navegador gestiona la interfaz de usuario, el disco y la E/S de la red.
  • El proceso de renderizado renderiza las páginas web, se ocupa de HTML, Javascript. Se crea un nuevo renderizador para cada sitio web abierto.
    • Se ejecuta en el sandbox restringiendo el disco y la E/S de la red, minimizando el efecto de los exploits de seguridad.
  • Proceso de plug-in para cada tipo de plug-in.

Comunicación entre procesos

• Los procesos dentro de un sistema pueden ser independientes o cooperantes.
• El proceso cooperativo puede afectar o ser afectado por otros procesos, incluyendo el intercambio de datos.
• Razones para los procesos de cooperación:
  • Compartir información
  • Aceleración de la computación
  • Modularidad
  • Conveniencia
• Los procesos cooperantes necesitan comunicación entre procesos (IPC).
• Dos modelos de IPC:
  • Memoria compartida
  • Paso de mensajes

Problema del Productor-Consumidor

• Paradigma para los procesos cooperativos:
  • El proceso de producción produce información que es consumida por un proceso de consumo
• Dos variaciones:
  • El unbounded-buffer no pone ningún límite práctico al tamaño del buffer:
    • El productor nunca espera.
    • El consumidor espera si no hay buffer para consumir.
  • bounded-buffer asume que hay un tamaño de buffer fijo:
    • El productor debe esperar si todos los buffers están llenos.
    • El consumidor espera si no hay buffer para consumir.

IPC – Memoria Compartida

• Una zona de memoria compartida entre los procesos que desean comunicarse.
• La comunicación está bajo el control de los procesos de los usuarios, no del sistema operativo.
• Los principales problemas son proporcionar un mecanismo que permita a los procesos de los usuarios sincronizar sus acciones cuando acceden a la memoria compartida.
• La sincronización se discute con gran detalle en los capítulos 6 y 7.

IPC – Paso de Mensajes

• Los procesos se comunican entre sí sin recurrir a variables compartidas.
• El la facilidad IPC proporciona dos operaciones:
  • send(message)
  • receive(message)
• El tamaño del mensaje es fijo o variable.
• Si los procesos P y Q desean comunicarse, necesitan:
  • Establecer un enlace de comunicación entre ellos.
  • Intercambiar mensajes a través de send/receive.
• Problemas de implementación:
  • ¿Cómo se establecen los enlaces?
  • ¿Puede un enlace ser asociado con más de dos procesos?
  • ¿Cuántos enlaces puede haber entre cada par de procesos de comunicación?
  • ¿Cuál es la capacidad de un enlace?
  • ¿Es el tamaño de un mensaje que el enlace puede acomodar fijo o variable?
  • ¿Es un enlace unidireccional o bidireccional?

Implementación del Enlace de Comunicación

• Físico:
  • Memoria compartida
  • Bus de hardware
  • Red
• Lógico:
  • Directo o indirecto
  • Síncrono o asíncrono
  • Buffer automático o explícito

Comunicación Directa

• Los procesos deben nombrarse explícitamente: send(P, mensaje) – envía un mensaje al proceso P receive(Q, mensaje) – recibe un mensaje del proceso Q
• Propiedades del enlace de comunicación
  • Los enlaces se establecen automáticamente.
  • Un enlace se asocia con exactamente un par de procesos de comunicación.
  • Entre cada par existe exactamente un enlace.
  • El enlace puede ser unidireccional, pero normalmente es bidireccional.

Comunicación Indirecta

• Los mensajes se dirigen y se reciben desde buzones (también conocidos como puertos).
  • Cada buzón tiene un ID único
  • Los procesos pueden comunicarse sólo si comparten un buzón
• Propiedades del enlace de comunicación
  • El enlace se establece sólo si los procesos comparten un buzón común.
  • Un enlace puede estar asociado a muchos procesos.
  • Cada par de procesos puede compartir varios enlaces de comunicación.
  • El enlace puede ser unidireccional o bidireccional.
• Operaciones:
  • Crear un nuevo buzón (puerto)
  • Enviar y recibir mensajes a través del buzón
  • Borrar un buzón
• Las primitivas se definen como:
  • send(A, mensaje) – envía un mensaje al buzón A
  • receive(A, mensaje) – recibe un mensaje del buzón A.

Comunicación Indirecta (Cont.)

• Compartir buzones
  • P1, P2 y P3 comparten el buzón A
  • P₁, envía; P2 y P3 reciben
  • ¿Quién recibe el mensaje?
• Soluciones
  • Permitir que un enlace se asocie con como máximo dos procesos
  • Permitir que sólo un proceso a la vez ejecute una operación de recepción
  • Permitir que el sistema seleccione arbitrariamente el receptor. El remitente es notificado de quién era el receptor.

Sincronización

• El paso de mensajes puede ser bloqueante o no bloqueante
• El bloqueo se considera síncrono.
  • Envío bloqueante: el remitente se bloquea hasta que se recibe el mensaje.
  • Recepción bloqueante: el receptor se bloquea hasta que haya un mensaje disponible.
• El desbloqueo se considera asíncrono.
  • Envío no bloqueante: el remitente envía el mensaje y continúa.
  • Recepción no bloqueante: el receptor recibe:
    • Un mensaje válido, o
    • Mensaje nulo
• Diferentes combinaciones posibles:
  • Si tanto el envío como la recepción son de bloqueo, tenemos un punto de encuentro.

Almacenamiento en búfer

• Cola de mensajes adjunta al enlace.
• Implementado de una de tres maneras:
• Capacidad cero - no hay mensajes en cola en un enlace.
  • El remitente debe esperar al receptor (cita).
• Capacidad limitada: longitud finita de n mensajes.
  • El remitente debe esperar si el enlace está lleno.
• Capacidad ilimitada - longitud infinita.
  • El remitente nunca espera

Ejemplos de Sistemas IPC - POSIX

• Memoria compartida POSIX:
  • El proceso primero crea un segmento de memoria compartida: shm_fd = shm_open(name, O CREAT | O RDWR, 0666);
  • También se utiliza para abrir un segmento existente.
  • Establecer el tamaño del objeto: ftruncate(shm_fd, 4096);
  • Usar mmap() para mapear la memoria de un puntero de archivo al objeto de memoria compartida.
  • La lectura y escritura de la memoria compartida se realiza utilizando el puntero devuelto por mmap().

Sistemas IPC - Mach

• La comunicación Mach se basa en mensajes:
  • Incluso las llamadas al sistema son mensajes.
  • Cada tarea obtiene dos puertos en la creación: Kernel y Notify.
  • Los mensajes son enviados y recibidos usando la función mach_msg().
  • Puertos necesarios para la comunicación, creados vía mach_port_allocate()
  • El envío y la recepción son flexibles; por ejemplo, cuatro opciones si el buzón está lleno:
    • Esperar indefinidamente
    • Esperar como máximo n milisegundos
    • Devolver inmediatamente
    • Almacenar en caché temporalmente un mensaje

Sistemas IPC - Windows

• Mensajes centrados a través de facilidades de llamadas a procedimientos locales avanzadas (LPC):
  • Sólo funciona entre procesos en el mismo sistema
  • Utiliza puertos (como buzones) para establecer y mantener los canales de comunicación
  • La comunicación funciona de la siguiente manera:
    • El cliente abre un identificador para el objeto de puerto de conexión del subsistema.
    • El cliente envía una solicitud de conexión.
    • El servidor crea dos puertos comunicación privados y devuelve el identificador a uno de ellos al cliente.
    • El cliente y el servidor utilizan el identificador de puerto correspondiente para enviar mensajes o devoluciones de llamada y para escuchar las respuestas.

Sockets

• Un socket se define como un punto final para la comunicación.
• La concatenación de la dirección IP y el puerto, es un número incluido al inicio del paquete de mensajes, se diferencia los servicios de red en un host.
• El socket 161.25.19.8:1625 se refiere al puerto 1625 en el host 161.25.19.8.
• La comunicación consiste entre un par de sockets.
• Todos los puertos por debajo de 1024 son bien conocidos, utilizados para los servicios estándar.
• La dirección IP especial 127.0.0.1 (loopback) se refiere al sistema en el que se está ejecutando el proceso.

Sockets en Java

• Tres tipos de sockets:
  • Orientado a la conexión (TCP)
  • Sin conexión (UDP)
  • La clase MulticastSocket: los datos pueden ser enviados a múltiples destinatarios

Llamadas a Procedimientos Remotos

• La llamada a procedimiento remoto (RPC) abstrae las llamadas a procedimiento entre procesos en sistemas en red.
  • Utiliza de nuevo los puertos para la diferenciación de servicios.
  • Stubs - proxy del lado del cliente para el procedimiento real en el servidor.
  • El stub del lado del cliente localiza el servidor y marshals los parámetros.
  • El stub del lado del servidor recibe este mensaje, desempaqueta los parámetros emparejados y realiza el procedimiento en el servidor.
  • En Windows, el código del stub se compila a partir de la especificación escrita en el Lenguaje de Definición de la Interfaz de Microsoft (MIDL).
  • La representación de datos se maneja a través del formato de Representación Externa de Datos (XDL) para tener en cuenta las diferentes arquitecturas.
    • Big-endian y little-endian.
  • La comunicación remota tiene más escenarios de fallo que la local : Los mensajes pueden ser entregados exactamente una vez en lugar de como máximo una vez.
  • OS típicamente proporciona un servicio de rendezvous (o matchmaker) para conectar el cliente y el servidor.

Tuberías

• Actúa como un conducto que permite que dos procesos se comuniquen
• Cuestiones:
  • ¿Es la comunicación unidireccional o bidireccional?
  • En el caso de la comunicación bidireccional, ¿es semi o full-duplex?
  • ¿Debe existir una relación (es decir, padre-hijo) entre los procesos de comunicación?
  • ¿Se pueden utilizar las tuberías a través de una red?
  • Las tuberías ordinarias: no se puede acceder desde fuera del proceso que lo creó. Típicamente, un proceso padre crea una tubería y la usa para comunicarse con un proceso hijo que creó.
  • Tuberías nombradas: se puede acceder sin una relación padre-hijo.

Tuberías Ordinarias

• Las tuberías ordinarias permiten la comunicación al estilo estándar productor-consumidor.
  • El productor escribe en un extremo (el write-end de la tubería)
  • El consumidor lee desde el otro extremo (el read-end de la tubería)
  • Por lo tanto, las tuberías ordinarias son unidireccionales Proceso padre debe ser requerido para la comunicación.
• Windows llama a estas tuberías anónimas.

Tuberías Nombradas

• Las tuberías nombradas son más poderosas que las tuberías ordinarias
• La comunicación es bidireccional
• No es necesaria ninguna relación paterno-filial entre los procesos de comunicación
• Varios procesos pueden utilizar la tubería nombrada para la comunicación
• Se proporciona tanto en los sistemas UNIX como en los de Windows.