capitulo 3: procesos · operating system concepts – 9th edition 3.3 silberschatz, galvin and...

Silberschatz, Galvin and Gagne ©2013Operating System Concepts – 9th Edition

Capitulo 3: Procesos

3.2 Silberschatz, Galvin and Gagne ©2013Operating System Concepts – 9th Edition

Capitulo 3: Procesos

Concepto Planificación de procesos Operaciones sobre procesos Comunicación entre procesos Ejemplos de Sistemas IPC La comunicación en los sistemas cliente-servidor


Objetivos

Introducir la noción de un proceso - un programa en ejecución, que constituye la base de todos los cálculos

Describir las diversas características de los procesos, incluyendo la programación, creación y terminación, y la comunicación

Explorar la comunicación entre procesos se utiliza la memoria compartida y paso mensaje Describir la comunicación en los sistemas cliente-servidor


Concepto

Un sistema operativo ejecuta una variedad de programas: Batch system – jobs Sistemas de tiempo compartido - programas de usuario o tareas

Libro de texto utiliza el trabajo y el proceso de términos casi intercambiables Proceso – un programa en ejecución, ejecución de procesos deben avanzar en forma secuencial múltiples partes

El código de programa, también llamado sección de texto Actividad actual incluyendo contador de programa, registros del procesador Pila contiene datos temporales

Parámetros de la función, las direcciones de retorno, variables locales Data section contiene las variables globales Heap contiene la memoría asignada dinámicamente durante la ejecución

Programa es una entidad pasiva almacenada en el disco (archivo ejecutable), el proceso está activo Un program se convierte en proceso cuando un archivo ejecutable es cargado en memoria.

La ejecución del programa se inicia via GUI ( a través de clics del ratón),entrada de línea de comandos por su nombre, etc

Un programa puede ser de varios procesos Considere la posibilidad de múltiples usuarios ejecutando el mismo programa


Proceso en Memoria


Estado del Proceso

Un proceso ejecutándose cambia de estado new running waiting ready terminated


Diagrama de estados de un proceso


Bloque de control de procesos (PCB)Información asociada a cada proceso(también llamado bloque de control de tarea) Estado del proceso - en ejecución, en espera,

etc Contador de programa - la ubicación de la

instrucción a ejecutar a continuación Registros del CPU - contenido de todos los

procesos - registros centricos Planificación de información del CPU - las

prioridades, la planificación de los punteros de cola

Administrador de información de memoria - la memoria asignada al proceso

La información contable - CPU usado, reloj de tiempo transcurrido desde el inicio, los límites de tiempo,

Información de estado de E / S - los dispositivos de E / S asignado al proceso, la lista de archivos abiertos


Cambio del CPU de un proceso a otro


Hilos

Hasta el momento, el proceso tiene un solo hilo de ejecución Consideremos la posibilidad de tener varios contadores de

programas por proceso Múltiples ubicaciones se pueden ejecutar al mismo

tiempo Múltiples hilos de control -> hilos

Entonces debe tener almacenamiento para obtener más información de hilo, contadores múltiples programas en PCB


Representación de un proceso en Linux

Representado por una estructura en Ctask_structpid t pid; /* process identifier */ long state; /* state of the process */ unsigned int time slice /* scheduling information */ struct task struct *parent; /* this process’s parent */ struct list head children; /* this process’s children */ struct files struct *files; /* list of open files */ struct mm struct *mm; /* address space of this process */


Cola de procesos listos y varias de colas de dispositivos de E / S


Representación de planificación de procesos

Diagrama de colas representan colas, recursos, flujos


Planificadores Planificador de largo plazo (o planificador de trabajos) - selecciona qué procesos

deben traerse de la cola de procesos listos Planificador de corto plazo (o planificador de CPU) - selecciona qué proceso debe

sera ejecutado y asigna CPU A veces el único planificador en un sistema

Planificador de corto plazo es invocado muy frecuentemente (milisegundos) => (debe ser rápido)

Planificador de largo plazo es invocado muy frecuentemente (segundos, minutos) => (puede ser lento)

El planificador a largo plazo controla el grado de multiprogramación

Los procesos se pueden describir como: I/O-bound process – pasa más tiempo haciendo operaciones de E / S que

cálculos, muchas ráfagas cortas de CPU CPU-bound process – más tiempo haciendo cálculos; pocas ráfagas de CPU

muy largas Planificador de largo plazo busca una buena "mezcla de procesos"


Incorporacion de un planificador de mediano plazo

Planificador de mediano plazo puede añadirse si el grado de programación múltiple debe disminuirse

Retira el proceso de la memoria, almacena en el disco, traer desde el disco para continuar la ejecución: swapping


Multitareas en sistemas móviles

Debido al espacio limitado de la pantalla, la interfaz de usuario de iOS prevé que :

Un proceso en primer plano individual es controlado a través de la interfaz de usuario

Multiples procesos en segundo plano, en memoria, ejecutanse, pero no en la pantalla, y con límites

Los límites incluyen solo una tarea, corta, recibir notificaciones de eventos específicos, tareas de larga duración como la reproducción de audio

Android se ejecuta en primer plano y el fondo, con menos límites Proceso en segundo plano utiliza un servicio para realizar tareas El servicio puede seguir funcionando incluso si el proceso de fondo se

suspende Servicio no tiene interfaz de usuario, el uso de memoria es pequeño


Cambio de contexto

Contexto de un proceso representado en el PCB

El tiempo de cambio de contexto es una sobrecarga; El sistema no realiza ninguna tarea durante la conmutación.

Cuanto más complejo sea el sistema operativo y el PCB -> mayor el cambio de contexto

El tiempo depende del soporte de hardware Algunos fabricantes de hardware ofrecen varios conjuntos de

registros por CPU -> múltiples contextos cargados a la vez


Operaciones de procesos

El sistema debe proveer mecanismos para crear procesos, terminarlos, etc


Creación de procesos

El proceso Padre crea procesos hijos, que a su vez crean otros procesos, formando un árbol de procesos

En general, el proceso se identifica y se administra a través de un identificador de proceso (pid)

Opciones de intercambio de recursos Padres e hijos comparten todos los recursos Los hijos comparten un subconjunto de los recursos del

proceso padre Padres e hijos no comparten recursos

Opciones de ejecución Padres e hijos se ejecutan concurrentemente El padre espera hasta que los hijos terminan


Un árbol de procesos en Linux

i ni tpi d = 1

sshdpi d = 3028

l ogi npi d = 8415

kthreaddpi d = 2

sshdpi d = 3610

pdfl ushpi d = 200

khel perpi d = 6

tcschpi d = 4005

emacspi d = 9204

bashpi d = 8416

pspi d = 9298


Creación de procesos (Cont.) Espacio de direcciones

El hijo es un duplicado de padre El hijo tiene un programa cargado

UNIX ejemplo fork() llamada de sistema que crea un nuevo proceso exec() llamada de sistema usada después de un fork() para reemplazar el espacio

de memoria con un nuevo programa


Programa en C creando 2 procesos separados


Creando un proceso separado vía Windows API


Terminación de un proceso El proceso ejecuta la última instrucción y solicita al S.O borrar (exit()) P

Los datos de salida desde un hijo a un padre (via wait()) Los recursos del proceso son reasignados por el S.O

El padre puede terminar la ejecución de los procesos de los hijos (abort()) El hijo ha superado los recursos asignados La tarea asignada al hijo ya no es necesaria Si el padre está terminando

Algunos sistemas operativos no permiten que el hijo continúe si su padre termina

– Todos los hijos terminan - terminación en cascada

Espera a la terminación, devuelve el pid:pid t pid; int status;

pid = wait(&status);

Si el padre no espera, entonces el proceso terminado es un zombie Si el padre terminó, los procesos son huérfanos


Arquitectura multiproceso – Chrome Browser Muchos navegadores web funcionaban como un solo proceso (algunos

todavía lo hacen) Si un sitio web causa problemas, el navegador completo se cuelga o falla

Google Chrome Browser es multiproceso con 3 categorías Proceso Browser gestiona la interfaz de usuario, disco y la E / S de la

red El proceso Renderer despliega las páginas web, se refiere a HTML,

Javascript, uno nuevo para cada sitio web abierto Se ejecuta en una sandbox , restringiendo el usos de disco, red y

minimizando las vulnerabilidades de seguridad El proceso Plug-in para cada tipo de plug-in


Comunicación entre procesos Los procesos dentro de un sistema pueden ser independentes o

cooperativos Los procesos cooperativos pueden afectar o ser afectados por

otros procesos, incluyendo los datos compartidos. Razones para procesos cooperativos:

El intercambio de información Aceleración de cálculos Modularidad Conveniencia

Procesos cooperativos necesitan comunicación entre procesos interprocess communication (IPC)

Dos modelos de IPC memoria compartida paso de mensajes


Modelos de comunicación


El problema del productor-consumidor

En el paradigma para los procesos cooperativos: el proceso productor produce información y esta es consumida por el proceso consumidor. Búfer ilimitado: no pone ningún límite práctico

en el tamaño del búfer Búfer ilimitado supone que hay un tamaño de

búfer fijo


Búfer limitado – Solución para memoria compartida Datos compartidos

#define BUFFER_SIZE 10

typedef struct {

. . .

} item;

item buffer[BUFFER_SIZE];

int in = 0;

int out = 0;

La solución es correcta, pero solo puede usarse BUFFER_SIZE-1 elementos


Búfer limitado – Productor

item next produced;

while (true) {

/* produce an item in next produced */

while (((in + 1) % BUFFER SIZE) == out)

; /* do nothing */

buffer[in] = next produced;

in = (in + 1) % BUFFER SIZE;

}


Bounded Buffer – Consumidor

item next consumed;

while (true) {while (in == out)

; /* do nothing */next consumed = buffer[out];

out = (out + 1) % BUFFER SIZE;

/* consume the item in next consumed */

}


Comunicación entre procesos – Paso de mensajes

Mecanismo para los procesos para comunicación y sincronización de acciones

Sistema de mensajes - comunicar procesos entre sí sin recurrir a variables compartidas

IPC proporciona dos operaciones: send(message) – tamaño del mensaje fijo o variable receive(message)

Si P y Q desean comunicarse, es necesario que: establecer un enlace de comunicación entre ellos intercambiar mensajes a través de send / receive

Implementación del enlace de comunicación físico (por ejemplo, bus de memoria compartida, hardware) lógica (por ejemplo, buffering, directa o indirecta, sincronizada o

desincronizada, automática o explícita)


Comunicación Directa

Los procesos deben llamarse entre si explícitamente: send (P, message) – mandar un mensaje al proceso P receive(Q, message) – recibe un mensaje del proceso Q

Propiedades de enlace de comunicación Los enlaces se establecen automáticamente Un enlace está asociada con exactamente un par de procesos

de comunicación Entre cada par existe exactamente un enlace El enlace puede ser unidireccional, pero usualmente es

bidireccional


Comunicación indirecta

Los mensajes son dirigidos y recibidos de 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 de un enlace de comunicación Un enlace se establece sólo si los procesos comparten un

buzón común Un enlace puede estar asociada con muchos procesos Cada par de procesos puede compartir varios enlaces de

comunicación Enlace puede ser unidireccional o bidireccional



Operaciones Crear un nuevo buzón Enviar y recibir mensajes a través de el buzón Destruir el buzón

Las primitivas se definen como:send(A, message) – mandar un mensaje al buzón de Areceive(A, message) – recibir un mensaje desde el buzón de A



Buzón compartido P1, P2, y P3 comparten buzón A P1, envia; P2 and P3 reciben ¿Quién obtiene el mensaje?

Soluciones Permitir que un enlace para estar asociado con más de dos

procesos Permitir sólo un proceso a la hora de ejecutar una operación de

recepción Deje que el sistema para seleccionar arbitrariamente el receptor.

El remitente es notificado sobre quien fue el receptor.


Sincronización

El paso de mensajes puede ser con bloqueo o sin bloqueo

El bloqueo se considera síncrono El bloqueo de envío, bloquea al remitente hasta que se recibe el

mensaje El bloqueo de recepción, bloque al receptor hasta que esté

disponible un mensaje

El no bloqueo se considera asíncrono El no bloqueo de envio permite al remitente envíar el mensaje y

continuar El no bloqueo de recepción, permite al receptor recibir un mensaje

valido o nulo


Sincronización (Cont.)

Distintas combinaciones son posibles Si el emisor y el receptor estan bloqueados, tenemos un

rendezvous El problema de productor consumidor se volverá trivial

message next produced;

while (true) { /* produce an item in next produced */

send(next produced);

} message next consumed;while (true) { receive(next consumed); /* consume the item in next consumed */}


Buffering

Cola de mensajes que acompañan al enlace; implementada en una de estas tres maneras

1. Capacidad Cero - 0 mensajesRemitente debe esperar al receptor (rendezvous)

2. Limitado Capacidad - longitud finita de n mensajesRemitente debe esperar si el link está completo

3. Capacidad Ilimitado - longitud infinitaRemitente nunca espera


Ejemplos de sistemas IPC - POSIX

POSIX Shared Memory El proceso primero crea un segmento de memoria compartidashm_fd = shm_open(name, O CREAT | O RDRW, 0666);

También usado para abrir un segmento existente y compartirlo Estableces el tamaño del objetoftruncate(shm fd, 4096);

Ahora el proceso puede escribir en la memoria compartidasprintf(shared memory, "Writing to shared memory");


IPC POSIX Productor


IPC POSIX Consumidor


Ejemplos de sistemas IPC - Mach

La comunicación en Mach está basada en mensajes Incluso las llamadas al sistema son mensajes Cada tarea tiene dos buzones de correo - Kernel y Notify Sólo tres llamadas de sistema son necesarias para la transferencia

de mensajesmsg_send(), msg_receive(), msg_rpc()

Los buzones necesesarios para la comunicación, son creados víaport_allocate()

Enviar y recibir son operaciones flexibles, por ejemplo, cuatro opciones en caso de un buzón lleno: Esperar indefinidamente Esperar a lo más de n milisegundos Retornar inmediatamente Temporalmente alamacenar en caché el mensaje


Ejemplos de sistemas IPC – Windows

Paso de mensajes centralizado vía advanced local procedure call (LPC)

Sólo funciona entre procesos en el mismo sistema Utiliza puertos (como buzones) para establecer y mantener

canales de comunicación La comunicación funciona de la siguiente manera:

El cliente abre un subsistema manejador de conexion del puerto

El cliente envía una petición de conexión. El servidor crea dos puertos de comunicación privados y

devuelve el identificador de uno de ellos para el cliente. El cliente y el servidor utilizan el manejador correspondiente

al puerto y envian mensajes o callbacks y escuchan las respuestas.


Llamadas a procedimientos locales en Windows XP


Comunicaciones en sistemas cliente - servidor

Sockets

Remote Procedure Calls

Pipes

Remote Method Invocation (Java)


Sockets

Un socket es definido como un punto final para la comunicación

La concatenación de la dirección IP y un puerto – un número incluido al inicio del paquete del mensaje para diferenciar los servicios de la red en un host

El socket 161.25.19.8:1625 refiere al puerto 1625 en el host 161.25.19.8

La comunicación se establece entre un par de sockets

Todos los puertos por debajo de 1024 son conocidos, se utilizan para servicios estándar

La dirección special 127.0.0.1 (loopback) hace referencia al sistema en el cual el sistema se está ejecutando


Comunicación de Sockets


Sockets en Java

3 tipos de sockets Connection-oriented

(TCP) Connectionless (UDP) MulticastSocket class–

los datos pueden ser enviados a múltiples receptores

Considerar este server “Date” :


Llamadas a procedimientos remotos Llamada a procedimiento remoto (RPC) abstrae las llamadas a procedimientos entre

los procesos de los sistemas en red Utiliza los puertos para la diferenciación de servicios

Stubs – client-side proxy para el procedimiento actual en el servidor El client-side stub localiza al servidor y a los parámetros de los marshalls t El server-side stub recibe el mensaje, desempaca los parámetros y ejecuta el

procedimiento en el servidor En Windows, el código del stub code compila desde una especificación escrita en

Microsoft Interface Definition Language (MIDL) La representación de datos es manejada vía External Data Representation (XDL),

que es un formato que toma en cuenta diferentes arquitecturas. Big-endian y little-endian

La comunicación remota tiene más escenarios de falla que la local Los mensajes se pueden entregar exactamente una vez en lugar de a lo sumo

una vez S.O tipicamente proporciona un servicio rendezvous (o matchmaker) para conectar

el cliente y el servidor


Ejecución de RPC


Pipes (tuberias)

Actúa como un conducto, permite a 2 procesos comunicarse

Problemas ¿Es la comunicación unidireccional o bidireccional? En el caso de la comunicación de dos vías, es un half o full-dúplex ? ¿Existe una relación (es decir, padres e hijos) entre los procesos de

comunicación? ¿Pueden las tuberias utilizarse en una red?


Pipes ordinarias Permiten la comunicación en el estándar productor-consumidor Productor escribe en un extremo (el extremo de escritura de la

tubería) Consumidor lee desde el otro extremo (la lectura final de la tubería) Tubos ordinarios son, por tanto unidireccional Requieren relación padre-hijo entre los procesos de comunicación

Windows llama a estas canalizaciones anónimas Tarea: buscar ejemplos en Linux de pipes


Named Pipes

Named Pipes son más poderosas que las tuberías ordinarias

La comunicación es bidireccional

Ninguna relación entre padres e hijos es necesaria entre los procesos de comunicación

Varios procesos pueden utilizar la conexión con nombre para la comunicación

Proporcionan en ambos sistemas UNIX y Windows

capitulo 3: procesos · operating system concepts – 9th edition 3.3 silberschatz, galvin and...

Documents