Procesos Flashcards
¿Qué es y para qué sirve una System Call? Explicar los pasos involucrados por hardware y software. Ejemplificar. (2017)
Syscall es un tipo de instrucción, son llamadas al sistema. Los pasos son los mismos que para las interrupciones: Sirven para proveer funcionalidad, que solo puede ser accedida por el kernel, a las aplicaciones de usuario.
El hardware mete el PC, PSW, registros, etc. a la pila.
El hardware carga el nuevo PC del vector de interrupciones.
Procedimiento en lenguaje ensamblador guarda los registros.
Procedimiento en lenguaje ensamblador establece la nueva pila.
El servicio de interrupciones de C se ejecuta.
El scheduler decide que proceso se va a ejecutar a continuación.
Procedimiento en C regresa al código en ensamblador.
Procedimiento en lenguaje ensamblador inicia el nuevo proceso actual.
Una PCB clásica para el manejo de procesos contiene todos los recursos para que el proceso pueda ejecutar, por ejemplo Registros, Archivos abiertos, etc. ¿Cómo debe modificarse para soportar threads?
En los sistemas operativos que soportan threads, la PCB debe expandirse para incluir información de cada thread individual.
Un thread es la unidad básica de utilización de CPU en un sistema. Se compone de un thread id (tid), un program counter, un set de registros, y un stack.
Otros https://apps4two.com/curso_dba/bibliografia/2-Sistemas%20operativos%20moderno%203ed%20Tanenbaum.pdf como el mapeo de memoria (la sección de código, sección de datos, área de heap), y recursos como archivos abiertos, son del proceso que tiene los threads, y son compartidos entre todos los threads de un mismo proceso.
De modo que, para expandir la PCB y soportar threads, debe haber entradas para cada thread para almacenar (como mínimo): tid, program counter y registros, stack pointer, estado de scheduling y pid (o algún puntero) del proceso que contiene al thread.
(SILBERSCHATZ pags 109, 110, 163, 164)
Proponga un escenario en donde un proceso requiera la modificación de algún valor de la PCB. Escriba el pseudocódigo de las rutinas para realizar ese cambio y quién (SO o proceso) es responsable de cada una.
Cuando un proceso escribe algún registro y luego se produce una interrupción de clock y el scheduler decide hacer un cambio de contexto. En este caso se modificará el registro que está guardado en el PCB de ese proceso, por el nuevo valor que se modificó en el proceso.
El proceso únicamente cambia el valor del registro. El SO es el encargado de realizar el cambio en el PCB.
changeRegisterPcb(String r,int value,long pid){
pcbProceso ← obtener el PCB con valor pid de la tabla de procesos
registroAModificar ← obtener el registro r de pcbProceso
registroAModifica ← value
return;
}
Cuando abrís un archivo se modifica el File Descriptor Table y por lo tanto, también el PCB.
En la PCB tambien esta el program counter y el stack pointer, asi que con el simple hecho de que el proceso “avance”, se va a modificar la tabla de ese proceso.
En Unix/Linux los procesos no pueden acceder a puertos de entrada/salida directamente, salvo que explícitamente se le dé permiso. ¿Cómo podría implementarse?
When a User Mode process attempts to access an I/O port by means of an in or out instruction, the CPU may need to access an I/O Permission Bitmap stored in the TSS (PCB) to verify whether the process is allowed to address the port.
More precisely, when a process executes an in or out I/O instruction in User Mode, the control unit performs the following operations:
It checks the 2-bit IOPL field in the eflags register. If it is set to 3, the control unit executes the I/O instructions. Otherwise, it performs the next check.
It accesses the tr register to determine the current TSS, and thus the proper I/O Permission Bitmap.
It checks the bit of the I/O Permission Bitmap corresponding to the I/O port specified in the I/O instruction. If it is cleared, the instruction is executed; otherwise, the control unit raises a “General protection” exception.
¿Qué son las funciones reentrantes y cuál es su relación con los threads? (2017)
El término función reentrante hace referencia a que múltiples instancias de la función pueden estar ejecutándose en simultáneo (sin que nada explote). Es decir, se puede “entrar” de nuevo al código antes de haber terminado de ejecutar una instancia anterior. Es un concepto estrechamente relacionado con la sincronización (en particular la exclusión mutua) y el manejo de recursos compartidos. Un ejemplo donde hace falta que el código sea reentrante es cuando hay llamadas recursivas. Además, muchas partes del sistema operativo tienen que ser reentrantes: un ejemplo típico es el código de los drivers.
Relación con threads: si hay chances de que una misma función vaya a ser ejecutada por distintos threads, y no hay garantías de que lo vayan a hacer de manera exclusiva, entonces el código sí o sí tiene que ser reentrante.
Ver: pág 118 de Tanenbaum 4ta edición
Dar dos ejemplos de transición de running a ready. (06/08/2015)
Un ejemplo puede ser en un sistema con un scheduler Round Robin, si se agota el quantum de un proceso, el scheduler lo desaloja, y el proceso que estaba corriendo (running) vuelve a la cola de procesos listos (ready). No pasa a waiting porque el proceso no estaba esperando ningún evento (por ejemplo E/S).
Otro caso podría ser un proceso que decide por cuenta propia dejar de correr para luego ser retomado más adelante. Esto podría tener sentido en sistemas non-preemptive, donde un proceso decide ceder su lugar (quizás para ayudar otros procesos).
Si tenemos un scheduling que maneja prioridades con desalojo (como un SO RT), y una tarea con mayor prioridad aparece, la que se estaba ejecutando pasa de running a ready. Esta tarea de mayor prioridad puede ser una tarea nueva, una evento nuevo de un SO RT (que cree una tarea), como también una tarea en waiting que está lista para volver a correr (porque ya tiene el recurso por el que estaba esperando).
Otro ejemplo más estaría bueno quizás pero no se me ocurre… (interrupciones que no sean la del reloj)
Se puede ir directo de waiting a running? Explicar las razones. (06/08/2015)
Mirando la máquina de estados clásica de los estados de un proceso, la respuesta sería que no se puede. De waiting solo se puede pasar a ready, y luego de ahí puede pasarse a running. Sin embargo, (me s+uena a que) 8 sistema operativo, y no hay nada que impida que pueda ser diseñado así. Incluso, muchos sistemas operativos modernos implementan más estados que solamente los 5 básicos (new, ready, running, waiting, terminated).
Por ejemplo, podría haber un sistema operativo donde una llamada bloqueante de un proceso pueda ser marcada como “URGENTE” (por ejemplo), de modo que ni bien esté listo el dato, se desaloje la tarea que está corriendo y se reemplace con el proceso que estaba esperando. Dependerá de la implementación del sistema si en el medio el proceso es marcado como ready o no. De todos modos, esto podría traer problemas quizás si muchos procesos usasen este mecanismo.
Podría ser también, que si sólo hay un proceso en el sistema en el momento, y estaba en waiting y su dato ya está listo, entonces pase directamente a running, dado que no habría ningún otro proceso en ready ni running.
Cuál es la diferencia entre mode switch y context switch? (06/08/2015)
Context switch se produce al cambiar procesos en ejecución mientras que Mode switch se produce al cambiar de privilegios (por ejemplo, al ejecutar una syscall). La idea es que el Mode Switch está asociado a cuando se cambia de modo user a kernel o viceversa (ver links más abajo, en especial el de Quora).
Context switch implica cargar una nueva entrada de la tabla de procesos y guardar la anterior).
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/performance/mode_switches.html
What is the difference between a mode switch and a context switch?
Dibujar el mapa de memoria de un proceso. (06/08/2015)
A process is more than the program code, which is sometimes known as the text section. It also includes the current activity, as represented by the value of the program counter and the contents of the processor’s registers.
A process generally also includes the process stack, which contains temporary data (such as function parameters, return addresses, and local variables), and a data section, which contains global variables. A process may also include a heap,which is memory that is dynamically allocated during process run time.
(Silberschatz pag 106)
Qué pasa con la memoria cuando se crea un proceso hijo? Explicar los casos de fork() y vfork(). (06/08/2015)
En el caso de fork() el proceso hijo apunta a una copia de las páginas de memoria del padre. Aunque en realidad se utiliza la técnica copy-on-write, copiando las páginas sólo cuando sea necesario, para optimizar el uso de memoria.
Por el otro lado vfork() suspende al padre y le da al hijo una copia de las páginas, sin copy-on-write, es decir, cualquier modificación del hijo va a ser vista por el padre al finalizar y retornar el control.
Qué es Copy on Write? Cómo funciona en sistemas con Paginación? (06/08/2015)
Copy on Write es una política de optimización de recursos. Si dos procesos piden recursos que inicialmente son indistinguibles o iguales, se les da un puntero al mismo recurso físico. En el momento en que alguno de los procesos intenta modificar su copia del recurso, el sistema operativo hace la copia auténtica del recurso físico, y asigna esta nueva copia al proceso que intentó modificar (de no hacer esto, los cambios de uno se verían reflejados en los otros también).
En la paginación puede emplearse esta optimización. Cuando un proceso hace fork() por ejemplo, esto crea una copia completa del proceso (junto con su espacio de memoria). Sin embargo, podría implementarse la política de Copy on Write, de modo que al principio ambos procesos apunten a las mismas páginas de memoria, y sólo en el momento que alguno desea modificar una página es cuando se hace la copia de ella realmente. De esta manera, el fork() se puede hacer más rápido, y la copia de memoria según la necesidad.
Cuántas veces imprime “Hello, world!” el siguiente programa? Explicar. ¿Qué pasa si se usa vfork() en lugar de fork()? (06/08/2015)
foo () {
int i;
for(i = 0; i<3; i++) fork();
printf(“Hello, world!\n”);
}
Caso fork():
8 (porque 2^3 = 8). Primero hay 1 proceso, y se hace el primer fork. Ahora hay 2 procesos, a cada uno le quedan dos llamadas más a fork. Cada uno de estos procesos hace fork entonces, dejando un total de 4 procesos con una llamada más a fork. Luego, estos 4 hacen su último fork cada uno, dejando un total de 8 procesos. Luego cada proceso escribe por pantalla.
Caso vfork():
4 porque el primer proceso entra en el for (i=0) hace vfork, se bloquea y el nuevo proceso entra en el fork (como comparten la mem i=1), así dos veces más, bloqueando el proceso que llama al vfork y ejecutando el otro. Al llegar a i=3 el último proceso sale del for (no ejecuta vfork) y al volver el control a los anteriores i ale 3 (porque es la misma memoria, no copias)
Se poseen dos procesadores y se pueden ver los cambios de estado de los procesos. ¿Qué tendría que ver para que se aumente el rendimiento agregando…
…un procesador?
Un caso sería si los procesos pasan mucho de RUNNING a READY. Esto quiere decir que el procesador está desalojando mucho a los procesos en lugar de que se bloqueen solos, lo cual implica que a estos no les está alcanzando el tiempo de CPU que se les asigna. Asumiendo que el quantum no es excesivamente corto, esto quiere decir que hay muchos procesos CPU bound. Luego, tiene sentido agregar un procesador para incrementar el throughput.
Otro caso puede ser si hay muchos procesos READY. Esto implica que el CPU time no está alcanzando para satisfacer la demanda de los procesos, por lo cual se van acumulando en la cola de READY. Agregar un procesador mitigaría esta situación.
En otras palabras: agregar un procesador extra podría hacer que haya menos procesos en ready comparado a la versión sin el procesador extra. En este caso, podemos ver la carga del sistema antes de agregar el procesador, y después ver la carga del sistema luego de agregar el procesador para comparar si disminuyó. (carga del sist ema = cantidad de procesos en ready)
Se poseen dos procesadores y se pueden ver los cambios de estado de los procesos. ¿Qué tendría que ver para que se aumente el rendimiento agregando……más memoria?
Los procesos se bloquean mucho. Esto podría deberse a que el d, situación en la que por falta de memoria el SO debe hacer constantemente swapping de páginas entre disco y memoria para poder correr los procesos. Cuando esto pasa cada vez que se quiere ejecutar un proceso sus páginas deben ser traídas a memoria desalojando las de otro proceso, que posteriormente deberá ser traída de vuelta. Esto haría que los procesos se bloqueen todo el tiempo esperando al disco, dejando cada vez menos procesos en READY.
