 Mensaje: #1
Aporto VoF de finales resueltos, solo de Procesos, algunos resueltos por mi y otros los encontré resueltos, la idea es debatir cuales estan mal.
Un proceso es una entidad estática formada por los datos, código, pila y su contexto de ejecución.
Falso, no es estática.
Si un proceso efectúa una llamada al sistema bloqueante, entonces el proceso es bloqueado y enviado a la cola de BLOCKED.
Falso si la llamada al systema se hizo en un thread de kernel y hay otros threads para ejecutar.
Al hablar de procesos , se puede afirmar que la E/S no bloqueante plantea un modelo de programación más complejo y propenso a errores que la E/S bloqueante.
Verdadero, La E/S no bloqueante requiere de sincronización y algún tipo de mecanismo para avisar cuando se completo la solicitud.
A pesar que el procesador sólo puede ejecutar una instrucción en cada instante de tiempo, gracias a la multiprogramación, es posible que dos procesos se completen en un tiempo menor que si se ejecutaran de forma secuencial, incluso en un equipo con un solo procesador.
Verdadero porque cuando un proceso está bloqueado se permite la ejecución de otro proceso.
El PCB (Process Control Block) es mantenido en un almacenamiento secundario (generalmente disco) además de la localización en Memoria Central.
Falso, el PCB es parte de la imagen del proceso. "La posición de la imagen dependerá del esquema de gestión de memoria" [Stallings pág.128]
Un proceso está formado por los siguientes tres componentes: porción de un programa ejecutable, datos asociados que necesita el programa (variables , espacio de trabajo, buffers, etc.) el contexto de ejecución del programa y de estos, el componente más esencial son los datos asociados que necesita el programa.
Falso. La más esencial es el contexto de ejecución. Que es el conjunto de datos interno por el cual el S.O. es capaz de supervisar y controlar el proceso. [Stallings pág. 69]
Aceptando que dentro del PCB encontramos información respecto a tres categorias: Identificación del proceso, Información del estado del procesador e Información de control de proceso; los registros de códigos de condición (signo, cero, acarreo, igual, etc.) se encuentran dentro de la categoría Información del estado del procesador.
Verdadero. Los códigos de condición resultan de la operación lógica o aritmética más reciente. [Stallings pág. 130]
Durante la ejecución de los procesos puede ocurrir que estos alternen entre CPU burst e I/O burst, pudiendo terminar normalmente el proceso durante cualquiera de ellos.
Falso, un proceso que termina en forma correcta debe terminar con un cpu burst.
En un sistema con un diagrama de procesos de siete estados que utiliza memoria virtual se elimina la necesidad de usar Swapping Explícito para enviar los procesos de Bloqueado a Suspendido.
Falso. Incluso con un sistema de Memoria Virtual el SO necesita hacer swapping de los procesos de forma explícita y completa, de vez en cuando, con la intención de mejorar el rendimiento. [Stallings, 5ª ed. Esp., Pg. 122].
“El swapping de procesos es independiente del manejo de memoria virtual.”
El cambio de proceso (Process Switch) puede ocurrir al tiempo que el SO ha ganado el control desde el proceso en ejecución.
Verdadero. “Un cambio de proceso puede ocurrir en cualquier momento en el que el SO obtiene el control sobre el proceso actualmente en ejecución”. [Stallings, 5ª ed. Esp., Pg. 138].
El cambio de contexto es una operación que realiza el propio hardware.
Falso, es el SO quien cambia de un proceso a otro.
Si procesos estrechamente relacionados ejecutan en paralelo (en distintos procesadores), el bloqueo por sincronización puede llegar a ser alto, menos process switching pueden llegar a ser necesarios, y la performance se incrementará.
Falso. El bloqueo por sincronización disminuirá, por el paralelismo. Si el bloqueo por sincronización es alto, la performance no se incrementará ya que habrá más procesos bloqueados sin posibilidad de ejecutar.
En un sistema con un diagrama de 7 estados, un proceso podría pasar directamente del estado Ready al estado Exit.
Verdadero. Esto ocurre cuando un proceso hijo es finalizado, ya sea por pedido de su proceso padre o por finalización del mismo.
Un proceso puede pasar del estado de Bloqueados al estado de Finalizados.
Verdadero si finaliza el proceso padre.
Solo cuando un proceso termina puede devolver un valor de estado a su padre, pidiendo que lo elimine.
Verdadero. "Un proceso termina cuando ejecuta su ultima instrucción y pide al sistema operativo que lo elimine usando la llamada al sistema exit(). En ese momento, el proceso puede devolver un valor de estado a su proceso padre (a través de la llamada al sistema wait() )". [Silberchatz-Galvin, 7ª ed. Esp., Pg. 85].
Los procesos IO-Bundle (orientados al uso de I/O) son los más eficientes para dividir en múltiples procesos livianos.
Verdadero. Ya que puede haber muchos hilos que realicen I/Os diferentes simultáneamente y bloquearse solamente ellos (si trabajamos con KLT, con ULT recordemos que se bloquea todo el proceso y esta afirmación sería falsa), permitiendo que corran otros hilos del proceso listos para ejecutar.
Al usar ULTs combinados con KLTs, las syscalls bloqueantes desde un ULT no bloquean al resto de los UTLs
Verdadero si las ULT se ejecutan dentro de otras KLT.
Los UTL tienen la ventaja de que implican un menor overhead de planificación en comparación con los KLT.
Verdadero porque no necesita cambiar a modo kernel para gestionar los hilos. [Stallings 168]
Una ventaja de los ULTs es que el algoritmo de planificación puede ser propio de cada aplicación, pero como contrapartida debe generar una llamada al sistema por cada cambio de hilo en ejecución, lo que provoca overhead al cambiar de modo usuario a modo kernel.
Falso, Como un ULT se genera en un entorno del mismo proceso el kernel ni se entera de su existencia, de modo que no se necesitan cambios de modo.
Los hilos a nivel usuario son creados, eliminados y planificados por la biblioteca de hilos. Para realizar el cambio de contexto de los hilos , la biblioteca cambia de modo, salva el contexto del hilo saliente y de el control a otro hilo que está listo.
Falso, no necesita cambiar a modo kernel.
En un proceso con dos o más ULT, si el que está en ejecución solicita una I/O bloqueante, cuando vuelva a ejecutar el proceso, podría seguir ejecutando el mismo hilo, independientemente del algoritmo de planificación de dicha biblioteca.
Falso, si era RR con Q=1, ejecutó un hilo, se fue a bloqueados y cuando volvió a ejecutar el proceso si o si a va ir a otro hilo que estuviera en la cola de listos.
Cuando en un proceso se usan Threads siempre se necesita la estructura PCB u otra similar, independientemente de que sean KLT o ULTs.
Verdadera, un proceso siempre utiliza un PCB, y si hay hilos cada hilo tiene su TCB.
En una aplicación compleja que hace uso de la multiprogramación y donde la estabilidad es un requisito prioritario, es más conveniente usar procesos que hilos de cualquier tipo.
Verdadero, usar hilos puede traer más problemas de sincronización porque comparten memoria y archivos abiertos.
En el caso de los ULT (User Level Threads) el código para crear y destruir los threads son rutinas del Kernel
Falso, son rutinas de la biblioteca de threads. [Stallings, 5ª ed. Esp., Pg. 166].
Entre las categorías de implementación de hilos ULT y KLT, los KLT presentan respecto a los ULT la ventaja de que pueden ejecutar en cualquier sistema operativo.
Falso. Al revés, una ventaja de las ULT respecto a los KLT es que pueden ejecutar en cualquier sistema operativo. [Stallings pág. 168]
Una de las ventajas del uso de kernel level threads (KLTs) es que el cambio de threads (Thread switch) de un mismo proceso es más rápido que el cambio entre procesos (process switch) ya que los primeros comparten el stack (pila) del proceso.
Falso, si bien es cierto que el Thread switch es más rápido que el process switch por el tamaño de su pila y porque no se actualiza el “process control information” del PCB ( solo se cambian los registros dentro del address space) y no es cierto que compartan la pilas, cada thread tiene su propia pila.
Los ULT y los KLT no poseen el estado Zombie.
Verdadero. El estado Zombie es a nivel de proceso y sirve para indicar que un proceso hijo ha finalizado pero su señal de terminación no ha sido recogida por su proceso padre.
Existe una relación directamente proporcional entre la cantidad de threads de una aplicación y la velocidad de ejecución de la misma.
Falso. La velocidad no necesariamente depende de la cantidad de hilos
Los Threads son más rápidos que los procesos pesados debido a que al procesador le cuesta menos tiempo una instrucción proveniente de un Thread que la de un proceso.
Falso. Se debe a:
Toma menos tiempo crear un nuevo thread en un proceso existente, que crear un nuevo proceso.
Toma menos tiempo terminar un thread que un proceso.
El context switch entre threads de un mismo proceso es más rápido que el context switch entre procesos.
Los procesos pesados ejecutan solo un programa por proceso, de la misma manera que los procesos ligeros ejecutan ese mismo programa entre varios.
Falso, La diferencia entre procesos pesados y livianos es que los procesos pesados no comparten ninguna porción de la memoria. Procesos Livianos o threads comparten toda la memoria y el espacio de almacenamiento permanente.
En la facilidad KLT puro tiene el código de administración del thread en el área de aplicación (del proceso).
Falso. Está en el área del sistema operativo.
Un thread switch entre hilos del mismo proceso es más rápido que un process switch.
Verdadero. Por otro lado toma menos tiempo realizar el cambio para procesar un nuevo thread. Comparten un mismo espacio de memoria y datos entre sí debido a que forman parte de un mismo proceso. No se efectúa un context switch completo sobre el procesador sino una pequeña parte del mismo perteneciente al Thread.
El tiempo de creación de un Thread es mucho menor que el de un proceso pesado, debido a que la estructura TCB es más pequeña que el PCB.
Falso. La asignación de memoria y recursos para la creación de procesos es costosa, mientras que la creación de hebras es más sencilla debido a que comparten recursos del proceso. [Silberchatz-Galvin, 7ª ed. Esp., Pg. 115].
Ejecutar threads en equipos con un solo procesador no tiene sentido.
Falso. Tiene sentido, ya que por ejemplo mientras varios hilos permanecen bloqueados a la espera de sucesos (de una E/S por ejemplo) concurrentemente otro hilo puede estar ejecutando. Se incrementa la capacidad de respuesta al usuario. Además es más económico crear y realizar cambios de contexto entre hebras, ya que comparten recursos del proceso al que pertenecen. [Silberchatz-Galvin, 7ª ed. Esp., Pgs. 114/115].
Los Threads son más rápido que los procesos pesados solo si se ejecutan en equipos con multiprocesadores o que el único procesador tenga más de un hilo de ejecución.
Falso, son más rápidos porque tienen menor overhead de context switch.
Todo proceso tiene al menos un hilo.
Verdadero, por default cuando se crea un proceso siempre tiene un hilo corriendo.
Los hilos de un mismo proceso comparten las variables globales, el heap, la pila (stack) y los manejadores de señales (signal handlers), pero no comparten el contador de programa (Program Counter).
Falso, no comparten el stack.
Como el Sistema Operativo los desconoce, no tiene sentido sincronizar a los ULTs (User Level Threads), en cambio es fundamental sincronizar los KLTs (Kernel Level Threads).
Falso, independientemente de si es ULT, KLT o un proceso, es necesario asegurar la sincronización en el acceso a los recursos críticos.
En un sistema que cuenta con un solo procesador y dicho procesador no cuenta con múltiples hilos de ejecución no se obtienen mejoras al dividir los procesos pesados en Threads.
Falso. Los procesadores nunca cuentan con múltiples hilos de ejecución, son los procesos los que pueden contar con varios hilos/threads (o no). Por otro lado, en sistemas con un solo procesador sí se obtienen mejoras al utilizar Threads, ya que por ejemplo mientras un hilo (o varios) permanece bloqueado a la espera de un E/S, otro puede estar ejecutando.
Un proceso suspendido siempre está a la espera de un evento.
Falso, un proceso puede estar en el estado listo/suspendido, y en este estado no está a la espera de un evento sino que está listo para ser llevado a memoria central.
La existencia de un planificador a corto plazo sólo tiene sentido en los sistemas con multiprogramación.
Falso. Pues el planificador a corto plazo puede ser necesario igualmente al momento de la suspensión del proceso. Por ejemplo Operating system calls, i/o interrupts or signals.(pag 398).
¿Cuál de los planificadores es el encargado de bajar la tasa de multiprogramación del sistema?
Planificador a largo plazo. Éste es el planificador que hace lo indicado. El planificador a largo plazo, ya que determina qué programas se admiten e el sistema para su procesamiento (controla el grado de multiprogramación). [Stallings, 5ª ed. Esp., Pg. 403].
Uno de los objetivos del planificador a corto plazo en sistemas de tiempo compartido es proporcionar equidad y hacer que el tiempo de respuesta sea razonable y predecible.
Falso, depende del algoritmo de planificación proporcionar equidad y que el tiempo de respuesta sea predecible. Tiempo de respuesta es el tiempo desde la carga hasta que el proceso da su primer respuesta.
El planificador de corto plazo (Short Term Scheduler) es invocado solamente cuando se produce una interrupción de reloj.
Falso se invoca la ejecución del planificador de corto plazo para decidir qué proceso continuará en uso del procesador después de un context switch y esto ocurre frente a cualquier interrupción.
La ejecución muy frecuente de los planificadores de corto y largo plazo es la principal característica de los mismos.
Falso, el planificador largo plazo se ejecuta con mucha menos frecuencia que el de corto plazo.
En un algoritmo de planificación de corto plazo sin desalojo (non-preemptive), no es posible que un proceso pase del estado RUNNING al estado READY
Verdadero porque si es sin desalojo se ejecuta hasta que termina o hasta que tenga que hacer una E/S y vaya a la cola de bloqueados, pero nunca puede ir a Ready directo.
La siguiente afirmación sobre planificación de procesos “todos los métodos basados en prioridades tiene riesgo de inanición”.
Falso. Existen algoritmos de planificación basados en prioridades que utilizan la técnica de aging para evitar la inanición, mediante la cual la prioridad de los procesos incrementa gradualmente con el tiempo.
Se puede producir la inanición de un proceso cuando se use una planificación de procesos por prioridades fijas.
Verdadero, por ejemplo un proceso de prioridad muy baja puede sufrir inanición si constantemente entran al sistema procesos de prioridades altas.
Referido al algoritmo de Round Robin para scheduling de CPU de corto plazo ¿Es posible que se presente inanición?.
Falso. porque le da un quantum de tiempo a cada proceso equitativamente por turnos.
La planificación RR (Round Robin) es particularmente efectiva en sistemas de tiempo compartido de propósito general y en sistemas de procesamiento transaccional.
Verdadero. Extracción textual de [Stallings, 5ª ed. Esp., Pg. 413].
En un Sistema que utiliza Round Robin como política de planificación de procesos, si existen procesos que ejecutan solamente operaciones atómicas entonces el Short Term Scheduler degenera en FCFS, y a que no se va a poder interrumpir el proceso en ejecución hasta que finalice.
Falso, lo que no se puede interrumpir es la operación atómica, pero ni bien termina esa operación, el planificador a corto plazo evalúa si hay que cambiar de proceso.
Una duración muy baja del quantum de tiempo en el algoritmo Round Robin puede llegar a producir una baja performance en el Sistema.
Verdadero, si el quantum de tiempo es bajo va a ser mayor el tiempo consumido en hacer los cambios de cambios de proceso que lo se consume en procesar.
El algoritmo de planificación de procesos SRT (Shortest Remaining Time) es el que menor Turnarround Time posee para cualquier proceso que se encuentre corriendo en el sistema.
Falso, SRT beneficia a los procesos cortos y no a los largos por lo que puede haber inanición y el turn around de un proceso ser eterno.
El algoritmo de planificación SJF (Shortest Job First) se puede implementar para la cola de nuevos, pero no para la cola de listos.
Verdadero, "Aunque el algoritmo SJF es óptimo no se puede implementar en el nivel de la planificación a corto plazo ya que no hay forma de conocer la duración de la siguiente ráfaga de CPU". [Silberchatz p.144]
Cuando se produce un cambio de estado por una interrupción de E/S, este es una parte mínima del Quantum del proceso en ejecución.
Falso, el tiempo que insume el process switch no se cuenta adentro del quantum sino aparte.
Es imposible implementar Feedback con round robin en cada nivel en un sistema operativo tipo UNIX ya que se desconoce el largo de los procesos.
Falso, para hacer el algoritmo feedback no se necesitan conocer el largo de cada proceso. Pues sí es posible aplicar feedback en los casos en que se desconoce el largo de los procesos.
El algoritmo Feedback tiene como desventaja la necesidad de estimar la duración del burst de CPU.
Falso, no necesita estimar la duración del burst del CPU porque puede utilizar prioridades fijas.
La planificación por prioridades fijas no se puede implementar mediante múltiples colas multinivel con retroalimentación.
Falso, en la planificacion mediante colas multinivel realimentadas, cada cola puede tener una prioridad con respecto a la siguiente cola, pero al ser retroalimentadas permite mover un proceso de una cola a otra.
En la planificación del procesador, el modelo de varias colas resuelve el problema de que el procesador esté la mayor parte del tiempo desocupado.
Falso. Lo minimiza pero no lo resuelve.
En un sistema que trabaja con el algoritmo de planificación HRRN (high ratio response next) sólo los procesos nuevos tendrán el ratio igual a 1 (uno).
Verdadero. Analizando la función de seleccion de procesos... R=(w+s)/s (con R: Response Ratio, w:tiempo de espera del procesador y s: tiempo de servicio esperado) podemos deducir que la única forma que R=1 es que w=0 (porque quedaría R= (0+s)/s = s/s = 1); por lo tanto sólo los procesos con w=0 tienen el ratio igual a 1, y dichos procesos son los procesos nuevos (w:tiempo de espera del procesador=0).
"En un Sistema Operativo PREEMPTIVE no se pueden hacer presupuestos sobre el tiempo de corrida de un proceso" (cita del libro de Tanenbaum). Es por este motivo que el Sistema Operativo es el que hace el context switch, dado que es el único que sabe cuándo termina el quantum de tiempo de un proceso.
Falso. El concepto de quantum es del algoritmo RR que no es PREEMPTIVE.
El turnaround time promedio de un conjunto de procesos no necesariamente mejora si aumenta el tamaño del quantum.
Verdadero, Turnaround time (tiempo de retorno), es el tiempo desde que un proceso es cargado hasta que este finaliza su ejecución, si el quantum es mayor a la duración del proceso puede empeorar si tiene que esperar a que finalice otro proceso.
El throughtput viene influenciado por la duración promedio de los procesos y a su vez por la política de planificación de procesos.
Verdadero, el desempeño (throughput) es la cantidad de trabajo completado en un intervalo de tiempo dado y dependiendo de la planificación puede un proceso terminar antes.
Una de las funciones que realiza el dispatcher es el de guardar el estado del proceso actual en su PCB y restaurar el estado del proceso siguiente a ejecutar.
Falso, la función del dispatcher es de otorgarle al procesador los procesos o sacarle los procesos al procesador. El SO se encarga de la restauración.
Dentro de los algoritmos de planificación de tiempo real aquellos que cuando llega una tarea, el sistema le asigna una prioridad basada en las características de la misma es conocido como: Planificación dinámica basada en un plan.
Falso. La Planificación dinámica basada en un plan es aquella en que cuando llega una nueva tarea, pero antes de que comience su ejecución se intentara crear un plan que contenga las tareas previamente planificadas así como la nueva. La enunciada en la pregunta es la Planificación dinámica de mejor esfuerzo. Pag. 468
La política de planificación por grupos o Gang Scheduling reduce la sobrecarga de planificación, ya que una sola decisión afecta a varios procesadores y procesos.
Verdadero, recude overhead porque una decision afecta a varios procesos y procesadores. Produce menos switch.
(Este mensaje fue modificado por última vez en: 16-01-2013 20:40 por Alejandro.)
|
![[-]](images/collapse.gif)
Alejandro recibio 12 Gracias por este post
