El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D....

69
El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007

Transcript of El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D....

Page 1: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

El sistema operativo UNIX Gestión de Procesos

Expositor: José Luis Oropeza Rodríguez

México D. F., a 06 de agosto 2007

Page 2: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

OBJETIVO

• Presentar al alumno los elementos básicos que comprende la gestión de procesos dentro del sistema operativo UNIX.

BOSQUEJO DE LA PRESENTACIÓN

• Introducción• Procesos• Estados de un proceso• Algoritmos de planificación

Page 3: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

ESTRUCTURA DE UN PROGRAMA EN LENGUAJE C

La estructura de un programa en lenguaje C está formada por los siguientes elementos:

Bloque de declaración de archivos de cabecera y otras directivas. Debe declararse un archivo de cabecera por cada biblioteca a utilizar.

Bloque de declaración de variables globales y definición de funciones del programa.

La función main() de aparición obligatoria.EJEMPLO:

/* Bloque de declaración de archivosde cabecera y otras directivas */#include <stdio.h>/* Bloque de declaración de variables globales y definición de funciones del programa */int a;/* Función main */main() {printf(“C para UNIX\n");}

Page 4: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

TIPOS DE ARCHIVOS EJECUTABLES

SHELL SCRIPT CAMBIANDO LOS ATRIBUTOSDE UN ARCHIVO

ARCHIVOS EJECUTABLES

Un programa puede verse además de una colección de instrucciones y de datos que se encuentran almacenados en un archivo ordinario, que contiene en su i-nodo un atributo que lo identifica como ejecutable.

Crear archivo de

texto Tratarlos con un Shell

PROGRAMASEN C

Page 5: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

ARQUITECTURA INTERNA DE UN PROCESADOR Y LA EJECUCIÓN DE UN

PROGRAMASegmentode código

Segmentode datos

Segmentode pila

Segmentoextra

Page 6: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

MULTIPROGRAMACIÓN

Un proceso no es más que un programa en ejecución, e incluye los valores actuales del contador de programa, los registros y las variables. En realidad, la verdadera CPU conmuta de un proceso a otro, dicha conmutación se denomina multiprogramación.

En la figura se observa la forma de trabajar de un conjunto de programas que llevan a cabo el esquema de multiprogramación. Todos los procesos avanzan pero sólo un proceso se está ejecutando realmente.

Page 7: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PROCESSES

Processes are, however, more than just the executing program code (often called the text section in Unix).They also include a set of resources such as open files and pending signals, internal kernel data, processor state, a memory address space with one or more memory mappings, one or more threads of execution, and a data section containing global variables.

On modern operating systems, processes provide two virtualizations: a virtualized processor and virtual memory. The virtual processor gives the process the illusion that it alone monopolizes the system, despite possibly sharing the processor among hundreds of other processes.Virtual memory lets the

process allocate and manage memory as if it alone owned all the memory in the system.

Page 8: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PROCESSES

A program itself is not a process; a process is an active program and related resources. Indeed, two or more processes can exist that are executing the same program. In fact, two or more processes can exist that share various resources, such as open files or an address space.

Often, immediately after a fork it is desirable to execute a new, different program. The exec() family of function calls creates a new address space and loads a new program into it. In contemporary Linux kernels, fork() is actually implemented via the clone() system call, which is discussed in a following section.

Page 9: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

The kernel stores the list of processes in a circular doubly linked list called the task list.2. Each element in the task list is a process descriptor of the type struct task_struct, which is defined in <linux/sched.h>.The process descriptor contains all the information about a specific process.

The task_struct is a relatively large data structure, at around 1.7 kilobytes on a 32-bit machine.This size, however, is quite small considering that the structure contains all the information that the kernel has and needs about a process.

The process descriptor contains the data that describes the executing program—open files, the process’s address space, pending signals, the process’s state, and much more

Page 10: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Para poder planificar procesos, tenemos que saber qué es un "proceso". En todo sistema operativo un proceso está representado por una estructura de datos donde se guarda toda la información relevante de éste, el PCB (Process Control Block). En Linux, el PCB es la estructura struct task_struct [include/linux/sched.h#L281]. En esta estructura aparece todo tipo de información sobre un proceso.

Page 11: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Prior to the 2.6 kernel series, struct task_struct was stored at the end of the kernel stack of each process. This allowed architectures with few registers, such as x86, to calculate the location of the process descriptor via the stack pointer without using an extra register to store the location.

With the process descriptor now dynamically created via the slab allocator, a new structure, struct thread_info, was created that again lives at the bottom of the stack (for stacks that grow down) and at the top of the stack (for stacks that grow up).

The thread_info structure is defined on x86 in <asm/thread_info.h> as

struct thread_info {struct task_struct *task;struct exec_domain *exec_domain;__u32 flags;__u32 status;__u32 cpu;int preempt_count;mm_segment_t addr_limit;struct restart_block restart_block;void *sysenter_return;int uaccess_err;};

http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/arch/ia64/include/asm/thread_info.h?v=linux-3.12.6#L24

Each task’s thread_info structure is allocated at the end of its stack.The task element of the structure is a pointer to the task’s actual task_struct.

Page 12: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Storing the Process Descriptor

Because of backward compatibility with earlier Unix and Linux versions, however, the default maximum value is only 32,768 (that of a short int), although the value optionally can be increased as high as four million (this is controlled in <linux/threads.h>. The kernelstores this value as pid inside each process descriptor.

This maximum value is important because it is essentially the maximum number of processes that may exist concurrently on the system.Although 32,768 might be sufficient for a desktop systemIf the system is willing to break compatibility with old applications, the administrator may increase the maximum value via /proc/sys/kernel/pid_max.

Page 13: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

architectures, such as x86 (which has few registers to waste), make use of the fact that struct thread_info is stored on the kernel stack to calculate the location of thread_info and subsequently the task_struct. On x86, current is calculated by masking out the 13 least-significant bits of the stack pointer to obtain the thread_info structure.This is done by the current_thread_info() function.The assembly is shown here:

movl $-8192, %eaxandl %esp, %eax

This assumes that the stack size is 8KB.When 4KB stacks are enabled, 4096 is used in lieu of 8192.

Finally, current dereferences the task member of thread_info to return the task_struct: current_thread_info()->task; Contrast this approach with that taken by PowerPC (IBM’s modern RISC-based microprocessor), which stores the current task_struct in a register.

Page 14: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

EL PROCESO

Esencialmente, un proceso cuenta con su contador de programa y los contenidos de los registros del procesador para su ejecución, su stack, una sección de datos, puede incluir un heap (para la memoria dinámica), como se ilustra en la siguiente figura.

Es importante enfatizar que un programa por sí mismo no es un proceso; un programa es una entidad pasiva, tal como un archivo que contiene una lista de instrucciones almacenadas en un archivo de disco (comúnmente llamado archivo ejecutable), mientras que un proceso es una entidad activa, con un contador de programa que específica la siguiente instrucción a ejecutarse y un conjunto de recursos asociados.

stack

heap

data

text0

max

Page 15: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

MODOS DE EJECUCIÓN DE UN PROCESO

MODOUSUARIO

MODOKERNEL

Argumentos, Variables locales

y otros datos relativos a las

funciones que en modo usuario seestén manejando

Pila modo

usuario

Marcos de la pilade las llamadas

al sistema

Pila modo kernel

Desde un punto de vista funcional, un proceso en UNIX es una entidad creada tras la llamada a fork(). Todos los procesos, excepto el primero – proceso número 0 -, son creados mediante una llamada a fork(). El proceso que llama a fork se conoce como proceso padre y el proceso creado es el proceso hijo.

Page 17: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

ESTADOS DE UN PROCESO

El tiempo de vida de un proceso se puede dividir en un conjunto de estados, cada uno con unas características determinadas.

No puede proseguir su ejecución porque espera que se complete una operación de entrada/salida

El proceso se encuentra listo para ser ejecutado.

Page 18: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

SISTEMAS MONOUSUARIO, MONOPROCESADOR, MULTIUSUARIO Y

MULTIPROCESADOR

MSDOS (Sistema Monousuario y mono procesador) sólo un proceso se ejecuta a la vez. En los modos de ejecución, usuario y supervisor sólo existe un proceso en cada estado.

Page 20: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Un proceso migra entre varias colas de planificación a lo largo de su tiempo de vida. El sistema operativo debe de seleccionar, para propósitos de planificación, los procesos que entrarán en estas colas.

Planificador de tiempo largo. Selecciona los procesos de un repositorio (por lo regular del disco, gestionados por archivos batch), cargándolos dentro de la memoria para su ejecución. No disponibles en LINUX o WINDOWS

Planificador de corto tiempo o planificador de la CPU. Se encarga de seleccionar de entre todos los procesos que están listos para ejecutarse, cuál de ellos ocupará la CPU.

TIPOS DE PLANIFICADORES

La diferencia primaria entre estos dos tipos de planificadores es el tiempo de ejecución, el planificador de tiempo corto se ejecuta cada 100 milisegundos. El de tiempo largo depende del tiempo de ejecución entre un proceso y otro, además controla el grado de multiprogramación (que es el número de procesos en la memoria).

Page 21: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

ESTADOS DE UN PROCESO REAL

El proceso ya no existe pero deja para su proceso padre un registro que contiene el código de salida y algunos datos estadísticos

El proceso está durmiendo cargado en memoria

El proceso está durmiendo y el intercambiador ha descargado el proceso hacia una memoria secundaria – área de intercambio de disco – para crear espacio en memoria principal para cargar otros procesos.

Page 22: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

ESTADOS DE UN PROCESO REAL

El proceso está volviendo del modo supervisor al modo usuario, pero el núcleo se apropia del proceso y hace un cambio de contexto, pasando otro proceso a ejecutarse en modo usuario.

El proceso está listo para ejecutarse, pero el intercambiador – proceso 0 – debe cargar el proceso en memoria antes de que el planificador pueda ordenar que pueda pasar a ejecutarse.

El proceso acaba de ser creado y está en un estado de transición; el proceso existe, pero ni está preparado para ejecutarse, ni durmiendo. Este es el estado inicial de todos los procesos.

El proceso está durmiendo y el intercambiador ha descargado el proceso hacia una memoria secundaria – área de intercambio de disco – para crear el espacio en la memoria principal donde poder cargar otros procesos.

Page 23: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Process StateTASK_RUNNING—The process is runnable; it is either currently running or on a runqueue waiting to run. This is the only possible state for a process executing in user-space; it can also apply to a process in kernel-space that is actively running.

TASK_INTERRUPTIBLE—The process is sleeping (that is, it is blocked), waiting forsome condition to exist. When this condition exists, the kernel sets the process’s state to TASK_RUNNING. The process also awakes prematurely and becomes runnableif it receives a signal.

Page 24: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

__TASK_TRACED—The process is being traced by another process, such as a debugger, via ptrace.

TASK_UNINTERRUPTIBLE—This state is identical to TASK_INTERRUPTIBLE except that it does not wake up and become runnable if it receives a signal. This is used in situations where the process must wait without interruption or when the event is expected to occur quite quickly. Because the task does not respond to signals in this state, TASK_UNINTERRUPTIBLE is less often used than TASK_INTERRUPTIBLE.

__TASK_STOPPED—Process execution has stopped; the task is not running nor is it eligible to run. This occurs if the task receives the SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal or if it receives any signal while it is being debugged.

Page 25: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Kernel code often needs to change a process’s state.The preferred mechanism is using

set_task_state(task, state); /* set task ‘task’ to state ‘state’ */

This function sets the given task to the given state. If applicable, it also provides a memory barrier to force ordering on other processors. (This is only needed on SMP systems.)

Otherwise, it is equivalent to

task->state = state;

The method set_current_state(state) is synonymous to set_task_state(current, state). See <linux/sched.h> for the implementation of these and related functions.

Page 26: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Schedpid=0

Catppid=2536

pageoutpid=2

fsflushpid=3

inetdpid=140

dtloginpid=251

emacspid=8105

Cshpid=1400

std_shelpid=340

Xsessionpid=294

Netscapepid=7785

Cshppid=7778

inetdpid=7776

initpid=1

lspid=2123

Ejemplo de un árbol de procesos de un sistema Solaris. Usando ps –el ps –aux kill -09 pidpstreeNice Permite cambiar la prioridad de un procesonice -n -5 comando nohup y &Cuando se trata ejecutar procesos en background (segundo plano) topUna utilería muy usada y muy útil para el monitoreo en tiempo real del estado de los procesos jobs que lista los procesos actuales en ejecución

Se puede obtener la información completa de los procesos que se están ejecutando actualmente.

Page 27: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

The Process Family Tree

Each task_struct has a pointer to the parent’s task_struct, named parent, and a list of children, named

children. Consequently, given the current process, it is possible to obtain the processdescriptor of its parent with the following code:struct task_struct *my_parent = current->parent;Similarly, it is possible to iterate over a process’s children withstruct task_struct *task;struct list_head *list;list_for_each(list, &current->children) {task = list_entry(list, struct task_struct, sibling);/* task now points to one of current’s children */}

Page 28: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

The init task’s process descriptor is statically allocated as init_task.A good exampleof the relationship between all processes is the fact that this code will always succeed:struct task_struct *task;for (task = current; task != &init_task; task = task->parent);/* task now points to init */In fact, you can follow the process hierarchy from any one process in the system to anyother. Oftentimes, however, it is desirable simply to iterate over all processes in the system.

Page 29: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

This is easy because the task list is a circular, doubly linked list.To obtain the next task inthe list, given any valid task, uselist_entry(task->tasks.next, struct task_struct, tasks)Obtaining the previous task works the same way:list_entry(task->tasks.prev, struct task_struct, tasks)These two routines are provided by the macros next_task(task) andprev_task(task), respectively. Finally, the macro for_each_process(task) is provided,which iterates over the entire task list. On each iteration, task points to the next task inthe list:struct task_struct *task;for_each_process(task) {/* this pointlessly prints the name and PID of each task */printk(“%s[%d]\n”, task->comm, task->pid);}

Page 30: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Process Creation

In Linux, fork() is implemented through the use of copy-on-write pages. Copy-on-write (or COW) is a technique to delay or altogether prevent copying of the data. Rather than duplicate the process address space, the parent and the child can share a single copy. The data, however, is marked in such a way that if it is written to, a duplicate is made and each process receives a unique copy. Consequently, the duplication of resources occurs only when they are written; until then, they are shared read-only.This technique delays the copying of each page in the address space until it is actually written to. In the case that the pages are never written—for example, if exec() is called immediately after fork()—they never need to be copied.

Page 31: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

ForkingLinux implements fork() via the clone() system call.This call takes a series of flags that specify which resources, if any, the parent and child process should share. (See “The Linux Implementation of Threads” section later in this chapter for more about the flags.) The fork(), vfork(), and __clone() library calls all invoke the clone() system call with the requisite flags.The clone() system call, in turn, calls do_fork().

The bulk of the work in forking is handled by do_fork(), which is defined in kernel/fork.c.This function calls copy_process() and then starts the process running.The interesting work is done by copy_process():

1. It calls dup_task_struct(), which creates a new kernel stack, thread_info structure,and task_struct for the new process.The new values are identical to those ofthe current task. At this point, the child and parent process descriptors are identical.

2. It then checks that the new child will not exceed the resource limits on the numberof processes for the current user.

Page 32: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

3. The child needs to differentiate itself from its parent.Various members of theprocess descriptor are cleared or set to initial values. Members of the processdescriptor not inherited are primarily statistically information.The bulk of the valuesin task_struct remain unchanged.4. The child’s state is set to TASK_UNINTERRUPTIBLE to ensure that it does not yet run.5. copy_process() calls copy_flags() to update the flags member of thetask_struct.The PF_SUPERPRIV flag, which denotes whether a task used superuserprivileges, is cleared.The PF_FORKNOEXEC flag, which denotes a process that hasnot called exec(), is set.

Page 33: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

6. It calls alloc_pid() to assign an available PID to the new task.7. Depending on the flags passed to clone(), copy_process() either duplicates or shares open files, filesystem information, signal handlers, process address space, and namespace.These resources are typically shared between threads in a given process; otherwise they are unique and thus copied here.8. Finally, copy_process() cleans up and returns to the caller a pointer to the newchild.

Page 34: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

TABLA DE PROCESOS EN UNIX

Los campos que tiene cada una de las entradas de la tabla de procesos son los siguientes:

• Campo de estado que identifica el estado del proceso

• Campos para localizar el proceso y su área de usuario, tanto en memoria principal como en memoria secundaria. El núcleo usa esta información para realizar los cambios de contexto cuando el proceso pasa de un estado a otro. También utiliza esta información cunado traslada el proceso de la memoria principal al área de intercambio, y viceversa,.

• Algunos identificadores de usuario – UID – para determinar los privilegios del proceso. Por ejemplo, el campo UID delimita a qué procesos puede enviar señales el proceso actual y qué procesos pueden enviárselas a él.

• Identificadores de proceso – PID – que especifican las relaciones entre procesos. Esos identificadores son fijados cuando se crea el proceso mediante una llamda a fork.

• Descriptores de eventos, cuando el proceso está durmiendo y que serán utilizados al despertar.

Page 35: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

TABLA DE PROCESOS EN UNIX

Los campos que tiene cada una de las entradas de la tabla de procesos son los siguientes:

• Parámetros de planificación que le permiten al núcleo determinar el orden en el que los procesos pasan del estado ejecutándose en modo supervisor a ejecutándose al modo usuario.

• Un campo de señales que enumera las señales recibidas, que no han sido tratadas todavía.

• Algunos temporizadores que indican el tiempo de ejecución del proceso y el tiempo de uso de los recursos del núcleo. Estos campos se usan para llevar la estabilidad del proceso y calcular la prioridad dinámica que se le asigna. Aquí también existe un temporizador que puede programar el usuario y que se usa para enviarle al proceso la señal SIGALRM.

Page 36: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

TABLA DE PROCESOS EN UNIX

Page 37: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

TABLA DE PROCESOS EN LINUX

Un proceso en Linux, aunque tiene un modelo de memoria plano, está estructurado en dos zonas de memoria: •  La zona del usuario, normalmente los tres primeros gigabytes de las direcciones lógicas. •  La zona del núcleo, que ocupa el cuarto gigabyte. La zona del núcleo de Linux está "mapeada" en todos los procesos del sistema.

Page 38: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Esta estructura coincide con los dos modos del procesador que utiliza Linux: •  El código de la zona del núcleo se ejecuta siempre en modo supervisor. •  El código presente en la zona del usuario se ejecuta en modo usuario. Ejemplo:

Page 39: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

CAMPOS DE LA TABLA DE PROCESOS DE MINIX

Administración de procesos

Administración de memoria

Administración de archivos

RegistrosContador de programaPalabra de estado del programaApuntador de pilaEstado del procesoHora en la que se inició el procesoTiempo de CPU utilizadoTiempo de CPU de los hijosHora de la siguiente alarmaApuntadores a la cola de mensajesBits de señales pendientesIdentificador del procesoDiversos bits de banderas

Apuntador al segmento de textoApuntador al segmento de datosApuntador al segmento bssEstado de salidaEstado de señalesIdentificador del procesoProceso padreGrupo de procesosUid realUid efectivoGid realGid efectivoMapas de bits para señalesDiversos bits de bandera

Máscara UMASKDirectorio raízDirectorio de trabajoDescriptores de archivosUid efectivoGid efectivoParámetros de llamadas al sistemaDiversos bits de bandera

Page 40: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

ÁREA DE USUARIOEl área de usuario contiene información que es necesaria sólo cuando el proceso se está ejecutando. Algunos de los campos de que consta esta área son los siguientes:

• Apuntador a la entrada de la tabla de procesos correspondiente al proceso al cual pertenece el área de usuario.

• Los identificadores de usuario real y efectivo, que determinan algunos privilegios del proceso, tales como el permiso de acceso a un archivo.

• Temporizadores que registran el tiempo empleado por el proceso ejecutándose en modo usuario y en modo supervisor.

• Un arreglo que indica cómo va a responder el proceso a las señales que recibe.

• La terminal de inicio de sesión asociado al proceso, que indica cual es, si existe, el terminal de control.

• Un registro de errores que indica los errores producidos durante alguna llamada al sistema.

• Un campo de valor del retorno que contiene el resultado de las llamadas efectuadas por el proceso.

Page 41: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

ÁREA DE USUARIO

Algunos más de los campos de que consta esta área son los siguientes:

• Parámetros de entrada/salida que describen la cantidad de datos a transferir, la dirección del arreglo origen o destino de la transferencia y los apuntadores de lectura/escritura del archivo al que se refiere la operación de entrada/salida

• El directorio de trabajo actual y el directorio raíz asociados alproceso

• La tabla de descriptores de archivo que identifica los archivos que tiene abiertos el proceso.

• Campos de límite que restringen el tamaño del proceso y de algún archivo sobre el que puede escribir

• Una máscara de permisos que es usada cada vez que se crea el archivo.

Page 42: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

CONTEXTO DE UN PROCESO

El contexto de un proceso es su estado definido por: su código, los valores de sus variables de usuario globales y sus estructuras de datos, el valor de los registros de la CPU, los valores almacenados en su entrada de la tabla de procesos y en su área de usuario y el valor de sus pilas de usuario y supervisor.

Cuando se ejecuta un proceso, se dice que el sistema se está ejecutando en el contexto de un proceso. Cuando el núcleo decide ejecutar otro proceso, realiza un cambio de contexto y guarda la información necesaria para reanudar la ejecución del proceso interrumpido en el mismo punto donde lo dejó. De igual manera cuando el proceso cambia del modo usuario al modo supervisor, el núcleo guarda información para que el proceso pueda volver al modo usuario.

Page 43: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

CONTEXTO DE UN PROCESO

CONTEXTO DE UN PROCESO

CONTEXTO ANIVEL DE USUARIO

CONTEXTO DE

REGISTRO

CONTEXTO DEL NIVEL

DEL SISTEMA

Segmento de código

Segmento de datos

Segmento de pila

Zonas de memoria compartidas en la zona de direcciones virtuales del proceso

Contador de programa

Registro del estado del procesador

Apuntador de pila

Registros de propósito general

Entrada en la tabla de procesos

Área de usuario

Entradas de la tabla de regiones por proceso

La pila del supervisor

Parte dinámica del contexto del nivel de sistema.

Page 44: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

DISTIRUBUCIÓN O PLANIFICACIÓN DE PROCESOS

Espacios de tiempo (cuanto) igual a 0.1 seg. Para los sistemas BSD determinado de forma experimental.

Planificadorencargado de

asignar las prioridades

El planificador asigna prioridades de acuerdo al uso reciente de la CPU por cada proceso con objeto de incrementar la prioridad de aquellos que llevan más tiempo esperando la CPU. Cada vez que un proceso cambia de prioridad, también es cambiado de cola para que el distribuidor le pueda asignar la CPU de acuerdo con su nueva prioridad. En modo supervisor el rango reservado es de [0, 49] y en modo usuario es de [50, 127].

Más prioritario

Menos prioritario

127

Page 45: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

FORMA DE CONMUTACIÓN DE LA CPU ENTRE PROCESOS

Proceso P0 Sistema operativo Proceso P1

Salvar el estado en PCB0

Salvar el estado en PCB1

Salvar el estado en PCB1

Salvar el estado en PCB0

en espera

en espera

en esperaejecutándose

ejecutándose

ejecutándose

Interrupción o llamada al sistema

Interrupción o llamada al sistema. PCB Bloque de Control de Procesos

Interrupción o llamada al sistema

Page 46: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

CONMUTACIÓN DE CONTEXTOSLas interrupciones causan que el sistema operativo conmute la CPU de su tarea actual y ejecute una rutina a nivel de kernel. Cuando una interrupción ocurre, el sistema necesita salvar el contexto del proceso que actualmente esté ejecutándose en la CPU de tal forma que se pueda restaurar el contexto cuando el proceso lo requiera. El contexto se representa por el PCB del proceso.

La conmutación de la CPU a otro proceso requiere realizar un ahorro de estados del proceso actual y un re-almacenamiento de un proceso diferente. Esta tarea es conocida como la conmutación de contexto. Cuando una conmutación de contexto ocurre, el kernel salva el contexto del proceso anterior en su PCB y carga el contexto salvado del nuevo proceso planificado para ejecutarse.

Page 47: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Cuando un proceso crea un nuevo proceso, existen dos posibilidades en términos de ejecución:

1. El padre continua su ejecución para ejecutarse de manera concurrente con su hijo.

2. El padre espera hasta que alguno de los hijos haya terminado.

Existen dos posibilidades en términos del proceso padre (éste tiene el mismo programa y datos del padre.

1. El proceso hijo es un duplicado del proceso padre (éste tiene el mismo programa y datos del padre).

2. El proceso hijo tienen un nuevo programa para cargarlo.

En el programa de la siguiente diapositiva un nuevo proceso es creado con la llamada a fork(). El nuevo proceso consiste de una copia del espacio de direcciones del proceso original. El mecanismo permite al proceso padre comunicarse fácilmente con su proceso hijo. Ambos procesos (el padre y el hijo) continúan su ejecución después del fork(), con una diferencia. El código regresado es cero para el nuevo proceso, mientras que el identificador de proceso (no cero) del hijo es regresado al padre.

Típicamente, la llamada al sistema exec() se utiliza después de una llamada a fork() por uno de los dos procesos para reemplazar el espacio de memoria del procesador con un nuevo programa.

Page 48: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

EJEMPLO DE CREACIÓN DE PROCESOS

La llamada al sistema exec() carga un archivo binario en la memoria (destruyendo la imagen en la memoria del programa que contiene la llamada al sistema exec()) e inicia su ejecución. De esta manera, los dos procesos son capaces de comunicarse y entonces trabajar de dos formas. El padre puede entonces crear más hijos, o, llamar a move por si mismo a la cola lista hasta la terminación del hijo.

# include <sys/types.h># include <stdio.h># include <unistd.h>main() { int pid;

if ((pid=fork()) < 0) { printf ("error en creacion de proceso hijo\n");

exit(1); }

else if ( pid == 0) /* proceso hijo */

{ execlp (“bin/ls”,”ls”,NULL);} else /* proceso padre */ { wait (NULL);printf ("Proceso hijo completo\n"); fflush(stdout); exit (0);

}}

Page 49: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

CREACIÓN DE UN NUEVO CONTEXTO

MEDIANTE fork()

Datos delpadre

Pila deusuario

del padre

Archivos abiertosDirectorio actual

Directorio raíz

Pila del modosupervisor

Tabla de regiones por

proceso

Área de usuario

Datos delpadre

Pila deusuario

del padre

Archivos abiertosDirectorio actual

Directorio raíz

Pila del modosupervisor

Tabla de regiones por

proceso

Área de usuario

Códigocompartido

Tabla de archivos

Page 50: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

CREACIÓN DE UN NUEVO CONTEXTO MEDIANTE fork()

• Busca una entrada libre en la tabla de procesos y la reserva para el proceso hijo.

• Asigna un identificador de proceso –PID- para el proceso hijo. Este número es único e invariable durante toda la vida del proceso y con él lo pueden acceder otros procesos.

• Realiza una copia del contexto del nivel de usuario del proceso padre para el proceso hijo. Las secciones que deban ser compartidas, como el código o las zonas de memoria compartida, no se copian, sino que se incrementan los contadores que indican cuántos procesos tienen abiertos esos archivos.

• Las tablas de control de archivos locales al proceso –como la tabla de descriptores de archivo- también se copian del proceso padre al proceso hijo, ya que forman parte del contexto del nivel de usuario. En las tablas globales del núcleo – tabla de archivos y tabla de i-nodos- se incrementan los contadores que indican cuántos procesos tienen abiertos esos archivos.

• Regresa el proceso padre el PID del proceso hijo, y al proceso hijo le devuelve el valor 0.

Page 51: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

ALGORITMOS DE PLANIFICACIÓN

El planificador se encarga de decidir una política que permita que los diferentes procesos puedan ocupar la UCP. Existen varios criterios para determinar en qué consiste un buen algoritmo de planificación. En los cuales se tienen:

a) Equitatividad.- asegurarse de que cada proceso reciba una parte justa del tiempo de la UCP.

b) Eficiencia.- mantener la UCP ocupada todo el tiempo.

c) Tiempo de respuesta.- minimizar el tiempo de respuesta para usuarios interactivos.

d) Retorno.- minimizar el tiempo que los usuarios por lotes tienen que esperar sus salidas.

e) Volumen de producción.- maximizar el número de trabajos procesados por hora.

Page 52: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

DISTIRUBUCIÓN O PLANIFICACIÓN DE PROCESOS

niceCPU

Pu Pt

Pu

*24

min

La prioridad en modo usuario se calcula con la expresión:

Donde Pu es el valor que se está calculando

minPu es el valor más pequeño que puede tomar Pu, es decir, 50;

tCPU es una medida del uso reciente de CPU del proceso

Pnice es un parámetro que elige el usuario en el rango [0,39]

El valor de tCPU es actualizado por el núcleo incrementándose en 1 – hasta un valor máximo de 127 – por cada pulso de reloj para el proceso que actualmente ocupa la CPU y decrementándose D unidades cada segundo para el resto de procesos. D se calcula con la expresión CPUdeesperaen

procesosdepromedioNúmeroN

donde

N

ND

P

P

P

:

1*2

*2

Page 53: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

VENTAJAS Y DESVENTAJASVENTAJAS

•Es sencillo y efectivo en sistemas de tiempo compartido donde existen procesos interactivos con el usuario

•Asimismo, en procesos que se encuentran en segundo plano

DESVENTAJASEs insuficiente e introduce sobrecargas cuando hay que recalcular las prioridades de un número grande de procesos.

•No se puede reservar CPU para un proceso determinado que así lo requiera.

•No se puede garantizar los tiempos de respuesta de los procesos y por lo tanto no es aplicable a sistemas con requisitos de tiempo real.

•Produce inversión de prioridades entre los procesos que se ejecutan en modo supervisor porque el núcleo no es interrumpible.

•Los procesos tienen poco control sobre su prioridad; es el núcleo quien decide por ellos.

Page 54: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PLANIFICACIÓN TIPO ROUND ROBIN

Round robin es un método para seleccionar todos los elementos en un grupo de manera equitativa y en un orden racional, normalmente comenzando por el primer elemento de la lista hasta llegar al último y empezando de nuevo desde el primer elemento.Una forma sencilla de entender el round robin es imaginar una secuencia para "tomar turnos". En operaciones computacionales, un método para ejecutar diferentes procesos de manera concurrente, para la utilización equitativa de los recursos del equipo, es limitando cada proceso a un pequeño periodo de tiempo (quantum), y luego suspendiendo éste proceso para dar oportunidad a otro proceso y así sucesivamente. A esto se le denomina comúnmente como Planificación Round-Robin.En Sistemas operativos, la planificación Round Robin da un tiempo máximo de uso de CPU a cada proceso , pasado el cual es desalojado y retornado al estado de listo, la lista de procesos se planifica por FCFS, primero llegado, primero atendido.

Page 55: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PARÁMETROS DE EVALUACIÓN DE LOS ALGORITMOS DE PLANIFICACIÓN DE

PROCESOSPorcentaje de utilización de la CPU por procesos de usuario. La CPU es un recurso caro que necesita ser explotado, los valores reales suelen estar entre un 40% y un 90%.    Rendimiento (throughput) = nº de ráfagas por unidad de tiempo. Se define una ráfaga como el período de tiempo en que un proceso necesita la CPU; un proceso, durante su vida, alterna ráfagas con bloqueos. Por extensión, también se define como el nº de trabajos por unidad de tiempo.

  Tiempo de espera (E) = tiempo que una ráfaga ha permanecido en estado listo.

  Tiempo de finalización (F) = tiempo transcurrido desde que una ráfaga comienza a existir hasta que finaliza. F = E + t (t = tiempo de CPU de la ráfaga).    Penalización (P) = E + t / t = F / t, es una medida adimensional que se puede aplicar homogéneamente a las ráfagas independientemente de su longitud. 

Page 56: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PLANIFICACIÓN DE PLAZO FIJOEn la planificación de plazo fijo se programan ciertos trabajos para terminarse en un tiempo específico o plazo fijo. Estas tareas pueden tener un gran valor si se entregan a tiempo, y carecer de él si se entregan después del plazo. Esta planificación es compleja por varios motivos:

El usuario debe informar por adelantado de las necesidades precisas de recursos del proceso. Semejante información rara vez está disponible.

 El sistema debe ejecutar el proceso en un plazo fijo sin degradar demasiado el servicio a los otros usuarios y debe planificar cuidadosamente sus necesidades de recursos dentro del plazo. Esto puede ser difícil por la llegada de nuevos procesos que impongan demandas imprevistas al sistema.

 Si hay muchas tareas a plazo fijo activas al mismo tiempo, la planificación puede ser tan compleja que se necesiten métodos de optimización avanzados para cumplir los plazos.

 La administración intensiva de recursos requerida por la planificación de plazo fijo puede producir un gasto extra substancial.

Page 57: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PLANIFICACIÓN TIPO FIFOCuando se tiene que elegir a qué proceso asignar la CPU se escoge al que llevara más tiempo listo. El proceso se mantiene en la CPU hasta que se bloquea voluntariamente. La ventaja de este algoritmo es su fácil implementación, sin embargo, no es válido para entornos interactivos ya que un proceso de mucho cálculo de CPU hace aumentar el tiempo de espera de los demás procesos . Para implementar el algoritmo (ver figura 2) sólo se necesita mantener una cola con los procesos listos ordenada por tiempo de llegada. Cuando un proceso pasa de bloqueado a listo se sitúa el último de la cola. En a) el proceso P7 ocupa la CPU, los procesos P2, P4 y P8 se mantienen en la lista de preparados. En b) P7 se bloquea (ya sea al realizar una E/S, una operación WAIT sobre un semáforo a cero u otra causa) y P2 pasa a ocupar la CPU. En c) ocurre un evento (finalización de la operación de E/S, operación SIGNAL, ...) que desbloquea a P7, esto lo vuelve listo, pasando al final de la cola de procesos listos.

Page 58: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PLANIFICACIÓN ROUND ROBINEste es uno de los algoritmos más antiguos, sencillos y equitativos en el reparto de la CPU entre los procesos, muy válido para entornos de tiempo compartido. Cada proceso tiene asignado un intervalo de tiempo de ejecución, llamado cuantum o cuanto. Si el proceso agota su cuantum de tiempo, se elige a otro proceso para ocupar la CPU. Si el proceso se bloquea o termina antes de agotar su cuantum también se alterna el uso de la CPU. El round robin es muy fácil de implementar. Todo lo que necesita el planificador es mantener una lista de los procesos listos, como se muestra en la figura 6.2.

En esta figura en a) el proceso P7 ocupa la CPU. En b) P7 se bloquea pasando P2 a ocupar la CPU. En c) P2 agota su cuantum con lo que pasa al final de la lista y P4 ocupa la CPU. La figura 4 representa un ejemplo más largo de la ocupación de la CPU utilizando el algoritmo round robin.

Page 59: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PLANIFICACIÓN ROUND ROBIN

Este algoritmo presupone la existencia de un reloj en el sistema. Un reloj es un dispositivo que genera periódicamente interrupciones. Esto es muy importante, pues garantiza que el sistema operativo (en concreto la rutina de servicio de interrupción del reloj) coge el mando de la CPU periódicamente. El cuantum de un proceso equivale a un número fijo de pulsos o ciclos de reloj. Al ocurrir una interrupción de reloj que coincide con la agotación del cuantum se llama al dispatcher.

Page 60: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PLANIFICACIÓN EN EL SISTEMA OPERATIVO LINUX

Antes de la versión 2.5, el kernel de Linux poseía una variación del algoritmo de planificación tradicional de UNIX. Dos problemas de este tipo de planificador son que no otorga un adecuado soporte para los sistema SMP y que no escala de manera adecuada el número de tareas son el crecimiento del sistema. Con la versión 2.5, el planificador fue revisado, y el kernel ahora otorga un algoritmo de planificación que se ejecuta en tiempo constante –conocido como O(1)- a pesar del número de tareas sobre el sistema. El nuevo planificador también otorga un soporte incremental para SMP, incluyendo la afinidad del procesador y el balance de cargas, también como otorgar equidad y soporte para tareas interactivas.

El planificador de Linux es un algoritmo preventivo, basado en la prioridad con dos rangos de prioridad separadas: un rango en tiempo real de 0 a 99 y un rango de valor nice de 100 a 140. Estos dos rangos se mapean dentro de un esquema de prioridad global en donde los valores numéricos más bajos indican las prioridades más altas.

A diferencia de los planificadores de otros sistemas operativos, incluyendo Solaris y Windows XP, Linux asigna cuantos de tiempo más grandes a tareas de prioridad más altas y cuantos de tiempo más cortos a tareas con prioridad más baja. La relación entre prioridades y longitud de las ventanas de tiempo se ilustra a continuación:

Tareas en tiempo real

Otras tareas

Prioridad numérica

Prioridad relativa

Cuanto de tiempo

más alta

más baja

200 ms

10 ms

0

.

.

99

100

.

.

.

140

Page 61: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

PLANIFICACIÓN EN EL SISTEMA OPERATIVO LINUX

Una tarea ejecutable es considerada elegible para se ejecutada en la CPU tan pronto como su tiempo que reste en la ventana de tiempo. Cuando una tarea ha expirado su ventana de tiempo, se considera que ha expirado y no se puede elegir para su ejecución otra vez hasta que todas las demás tareas hayan expirado su cuanto de tiempo. El kernel mantiene una lista de todas las tareas en ejecución en una estructura de datos de cola de ejecución. Debido a su soporte para SMP, cada procesador mantiene su propia cola de ejecución y planificación por sí mismo de manera independiente. Cada cola de ejecución contiene dos arreglos prioritarios (activo y expirado). El arreglo activo contiene todas las tareas con el resto del tiempo en sus ventanas de tiempo, y el arreglo que termina contiene todas las tareas expiradas. Cada uno de estos arreglos prioritarios contiene una lista de tareas indexadas acorde a una prioridad como se ilustra en la siguiente figura. El planificador selecciona la tarea con la más alta prioridad del arreglo activo para su ejecución en la CPU. Cuando todas las tareas han ejecutado sus ventanas de tiempo (esto es, el arreglo activo está vacío), los dos arreglos de prioridades son intercambiados; el arreglo expirado se convierte en un arreglo activo, y viceversa.

Page 62: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

SINCRONIZACIÓN DE PROCESOS

Seccionescríticas

Exclusión mutua

Semáforos Eventos

Métodos de sincronización de procesos utilizados por los sistemas operativos

Ejecución de procesos

En general un proceso se sincroniza con otro poniéndose él mismo a dormir. No obstante, antes de ponerse a dormir, debe de poner en conocimiento del sistema operativo qué evento debe ocurrir para reanudar su ejecución. De esta forma, cuando se produzca ese evento, el sistema operativo despertará al proceso permitiéndole continuar la ejecución.

Page 63: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

SECCIONES CRÍTICASLa parte de un programa en la que se accede a una región de memoria compartida se denomina región crítica o sección crítica. Si se pudieran organizar las cosas de modo que dos procesos nunca pudieran estar en sus regiones críticas al mismo tiempo, se podrían evitar las condiciones de competencia. Sin embargo, se necesitan cumplir con cuatro condiciones para tener una buena solución:

a) Dos procesos nunca pueden estar simultáneamente dentro de sus regiones críticas.

b) No puede suponerse nada acerca de las velocidades o el número de las CPU.

c) Ningún proceso que se ejecute fuera de su región crítica puede bloquear a otros procesos.

d)Ningún proceso deberá tener que esperar indefinidamente para entrar en su región crítica.

Page 64: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

MECANISMOS DE COMUNICACIÓN IPC DE UNIX

SEMÁFOROS

MEMORIACOMPARTIDA

COLAS DEMENSAJES

MECANISMOS

Permiten sincronizar procesos

Permite que los procesos compartan su espacio de direcciones virtuales

Posibilitan el intercambio de datos con un formato determinado.

Page 65: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

EL PROBLEMA DE LOS FILÓSOFOSEn 1965, Dijkstra planteó y resolvió un problema de sincronización al que llamó el problema de la cena de los filósofos. Desde entonces, cualquier propuesta de sincronización debe de dar solución a este problema. Cinco filósofos están sentados alrededor de una mesa circular. Cada filósofo tiene ante sí un plato de espagueti. El espagueti es tan resbaloso que un filósofo necesita dos tenedores para comerlo. Entre cada par de platos existe un tenedor. La figura ilustra este hecho. La vida de un filósofo está constituida por periodos alternantes entre comer y pensar.

Cuando un filósofo siente hambre, trata de adquirir sus tenedores izquierdo y derecho, uno a la vez en cualquier orden. Si logra adquirir dos tenedores comerá durante un rato; luego pondrá los tenedores sobre la mesa y seguirá pensando. La pregunta clave es: ¿se puede escribir un programa para cada filósofo que haga lo que se supone que tiene que hacer y nunca se entrampe?. La solución óptima (correcta y que además admite un paralelismo máximo con n número de filósofos, es utilizar un arreglo State(estado) para mantenerse al tanto de que si un filósofo está comiendo, pensando o hambriento (tratando de disponer de tenedores). Un filósofo sólo puede pasar a la situación de “comiendo” si ninguno de sus vecinos está comiendo. Los vecinos del filósofo i están definidos por las macros LEFT y RIGHT. En otras palabras, si i es 2, LEFT es 1 y RIGHT es 3. El programa utiliza un arreglo de semáforos, uno por filósofo, de modo que los filósofos hambrientos pueden bloquearse si los tenedores que necesitan están ocupados.

Page 66: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

EL PROBLEMA DEL PELUQUERO DORMIDO

Suponga ahora que en una peluquería se encuentra un peluquero, una silla de peluquero y n sillas en donde pueden sentarse los clientes que esperan. Si no hay clientes pendientes, el peluquero se sienta en la silla del peluquero y se duerme. Cuando llega un cliente, tiene que despertar al peluquero dormido. Si llegan clientes adicionales mientras el peluquero está cortándole el pelo a un cliente, se sientan (si hay sillas vacías) o bien salen del establecimiento (si todas las sillas están ocupadas). El problema consiste en programar al peluquero y sus clientes sin entrar en condiciones de competencia.

La solución a este problema utiliza 3 semáforos: customers, que cuenta a los clientes en espera (excluyendo al que está siendo atendido que no está esperando), barbers, el número de peluqueros que están ociosos, esperando clientes (0 o 1), y mutex, que se usa para la exclusión mutua. También se necesita una variable, waiting (esperando), que también cuenta los clientes que están esperando, y que en esencia es una copia de customers. Se requiere de esta variable dado que no es posible leer el valor actual de un semáforo. En esta solución, un cliente que entra en la peluquería debe contar el número de clientes que esperan. Si este número es menor que el número de sillas, se queda; si no, se va.

Page 67: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

Barber(bloqueado en

espera de clientes)

Ejecuta la instrucciónde mutex

Entra a unaregión crítica

Otro cliente llega después, no puede hacer nada hasta que el primero devuelva el mutex que controla la región crítica.

Verifica si el número de clientes en espera en menor al número de sillas disponibles.

Page 68: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

TAREA

Planificación por prioridad al más corto

Planificación por prioridad al tiempo restante más corto

Planificación a la taza de respuesta más alta

Planificación del comportamiento

Page 69: El sistema operativo UNIX Gestión de Procesos Expositor: José Luis Oropeza Rodríguez México D. F., a 06 de agosto 2007.

CONCLUSIONES

•C fue creado en los Bell Telephone Laboratories al principio de los 70, por Dennis M. Ritchie.

Un programa puede verse además de una colección de instrucciones y de datos que se encuentran almacenados en un archivo ordinario, que contiene en su i-nodo un atributo que lo identifica como ejecutable.•Desde un punto de vista funcional, un proceso en UNIX es una entidad creada tras la llamada a fork().

El contexto de un proceso es su estado definido por: su código, los valores de sus variables de usuario globales y sus estructuras de datos, el valor de los registros de la CPU, los valores almacenados en su entrada de la tabla de procesos y en su área de usuario y el valor de sus pilas de usuario y supervisor. •El planificador asigna prioridades de acuerdo al uso reciente de la CPU por cada proceso con objeto de incrementar la prioridad de aquellos que llevan más tiempo esperando la CPU.