Preguntas Capítulo 04
Preguntas Capítulo 04
Preguntas Capítulo 04
- Un proceso moderno es un proceso multihilo. Una familia donde conviven los hijos que son los hilos. Cada hilo
tiene su información privada pero además hay una información general que es la del proceso que los contiene.
- El concepto de hilo surge con la idea de paralelismo. Ejemplos de aplicaciones que se benefician del uso de hilos
son procesador de texto, navegador web.
3. Defina las ventajas de una aplicación que esté programada con hilos.
1. Capacidad de respuesta. Los múltiples hilos de una aplicación interactiva pueden permitir a un programa
continuar ejecutándose incluso si parte de él está bloqueado o está ejecutando una operación prolongada, lo
que aumenta la capacidad de respuesta al usuario. Esta cualidad es especialmente útil en el diseño de interfaces
de usuario. Por ejemplo, considere lo que sucede cuando un usuario hace clic en un botón que da como
resultado observar el rendimiento de una operación que consume mucho tiempo. Una aplicación de un solo hilo
no respondería al usuario hasta que la operación hubiera sido terminada. Por el contrario, si la operación que
lleva mucho tiempo se realiza en un hilo separado y asíncrono, la aplicación sigue respondiendo al usuario.
2. Compartir recursos. Los procesos pueden compartir recursos sólo a través de técnicas como la memoria
compartida y el paso de mensajes. Tales técnicas deben ser organizadas explícitamente por el programador. Sin
embargo, los hilos comparten la memoria y los recursos del proceso al que pertenecen por defecto. El
beneficio de compartir código y datos es que permite a una aplicación tener varios hilos diferentes de actividad
dentro del mismo espacio de direcciones.
3. Economía (en espacio y tiempo). Como la creación de procesos consume mucha memoria y recursos, ya que
los hilos comparten los recursos del proceso al que pertenecen, es más económico crear y cambiar hilos
(cambio de contexto de hilos). Medir empíricamente la diferencia en gastos generales puede ser difícil, pero en
la creación general de hilos consume menos tiempo y memoria que la creación de procesos. Además, el cambio
de contexto suele ser más rápido entre hilos que entre procesos.
4. Escalabilidad. Los beneficios del multihilo pueden ser aún mayores en una arquitectura multiprocesador,
donde los hilos pueden ejecutarse en paralelo en diferentes núcleos de procesamiento. Un proceso de hilo
único solo puede ejecutarse en un procesador, independientemente de cuántos estén disponibles. Exploramos
este tema más adelante en la siguiente sección
4. Explique que significa que los hilos son soportados en el nivel de usuario y su diferencia con aquellos hilos
soportados por el kernel.
- Los hilos de usuarios son compatibles por encima del kernel y se administran sin soporte del kernel, mientras los
hilos del kernel son compatibles con el kernel y son gestionados directamente por el sistema operativo
5. Cuáles son los datos que un SO necesita guardar para administrar hilos y cuáles para un proceso multihilos?
● Prioridad
● Tiempos propios
● un conjunto de registros y
● una pila.
● su sección de código,
● sección de datos y
- En un sistema con un solo núcleo de computación, la concurrencia significa simplemente que la ejecución de los
hilos será intercalada en el tiempo (Figura 4.3), porque el núcleo de procesamiento es capaz de ejecutar sólo un
hilo a la vez.
Sin embargo, en un sistema con múltiples núcleos, concurrencia significa que algunos hilos pueden ejecutarse en
paralelo, porque el sistema puede asignar un hilo separado a cada núcleo (Figura 4.4).
Observe la distinción entre concurrencia y paralelismo en esta discusión. Un sistema concurrente admite más
de una tarea al permitir progresar a todas las tareas (avanzan intercaladamente). Por el contrario, un sistema
paralelo puede realizar más de una tarea simultáneamente. Por lo tanto, es posible tener concurrencia sin
paralelismo. Antes del advenimiento de las arquitecturas multiprocesador y multinúcleo, en la mayoría de las
computadoras, los sistemas tenían un solo procesador y se diseñaron planificadores de CPU para proporcionar la
ilusión de paralelismo cambiando rápidamente entre procesos, permitiendo así que cada proceso progrese.
Tales procesos se estaban ejecutando concurrentemente, pero no en paralelo.
- Identifica ganancias de rendimiento al agregar núcleos adicionales a una aplicación que tiene componentes
tanto en serie como en paralelo.
Por ejemplo, si tengo una tiempo de ejecución de 10 min con un solo procesador y agregar 3 procesadores de
modo de tener 4 procesadores uno podría suponer que entonces al dividir la tarea entre ellos demoraría 2,5min
pero eso no es tan simple. Hay que considerar la parte que se puede paralelizar y la que no, solo esa parte se
podrá dividir entre los procesadores. O sea el tiempo que se mejora (aceleración) no es necesariamente lo que
uno esperaría (aceleración máxima=N num de procesadores).
- El modelo de muchos a uno (Figura 4.7) asigna muchos hilos de nivel de usuario a un hilo de kernel. La
administración de hilos es realizada por la biblioteca de hilos en el espacio del usuario, entonces es eficiente.
Sin embargo, todo el proceso se bloqueará si un hilo realiza una llamada al sistema que sea bloqueante.
Además, porque sólo un hilo puede acceder al kernel a la vez, varios hilos no pueden ejecutarse en paralelo en
sistemas multinúcleo. Hilos verdes (Green threads): una biblioteca de hilos disponible para los sistemas Solaris y
adoptado en las primeras versiones de Java, se utilizaban modelos de muchos a uno. Sin embargo, muy pocos
sistemas continúan usando el modelo debido a su incapacidad para aprovechar múltiples núcleos de
procesamiento, cuya potencia aparece en la mayoría de los sistemas de computación.
Es posible que varios Hilos no se ejecuten en paralelo en el sistema multinúcleo porque solo uno puede estar en
el kernel a la vez
Ventaja. Se acelera mucho la creación y el intercambio de información entre hilos y la comunicación entre hilos
por que se hacía a nivel de usuario pero la aplicación tenía que tener bibliotecas de usuario a las cuales acceder
para hacer esa tarea y esa era la ventaja la rapidez al no trabajar el kernel.
Pero las desventajas son muchas, no puedo usar el paralelismo de ejecución de hilos y uno de esos hilos que se
bloque me lleva al bloqueo total del único hilo que es planificable en el kernel.
- El modelo uno a uno (Figura 4.8) asigna cada hilo de usuario a un hilo del kernel. Eso proporciona más
concurrencia que el modelo de muchos a uno al permitir que otro hilo se ejecute cuando un hilo hace una
llamada al sistema bloqueante. También permite múltiples hilos para ejecutarse en paralelo en
multiprocesadores. El único inconveniente de este modelo es que crear un hilo de usuario requiere crear el
correspondiente hilo del kernel, y una gran cantidad de hilos del kernel pueden afectar el rendimiento de un
sistema. Linux, junto con la familia de sistemas operativos Windows, implementa el modelo uno a uno.
Ventajas. Se puede aprovechar el paralelismo de esos hilos y un hilo no bloque a toda una aplicación.
Desventajas. Crear un hilo de usuario requiere crear un hilo del kernel y una gran cantidad de hilos del kernel
puede afectar al rendimiento de un sistema.
- El modelo de muchos a muchos (Figura 4.9) multiplexa muchos hilos de nivel de usuario para un número menor
o igual de hilos de kernel. El número de hilos del kernel puede ser específico para una aplicación particular o una
máquina particular (una aplicación se puede asignar más hilos de kernel en un sistema con ocho núcleos de
procesamiento de que un sistema con cuatro núcleos)
Consideremos el efecto de este diseño en la concurrencia. Mientras que el modelo muchos a uno le permite al
desarrollador crear tantos hilos de usuario como desee, no resulta en paralelismo, porque el kernel solo puede
planificar un hilo de kernel a la vez. El modelo uno a uno permite una mayor concurrencia, pero el desarrollador
debe tener cuidado de no crear demasiados hilos dentro de una aplicación. (De hecho, en algunos sistemas, ella
puede estar limitada en el número de hilos que puede crear.) El modelo de muchos a muchos no sufre ninguna
de estas deficiencias: los desarrolladores pueden crear tantos hilos de usuario como sea necesario, y los hilos del
kernel correspondientes pueden ejecutarse en paralelo en un multiprocesador. También, cuando un hilo realiza
una llamada al sistema bloqueante, el kernel puede planificar otro hilo para ejecución.
Ventajas. Si hay un hilo bloqueante este va a tener un correspondiente hilo del kernel exclusivo para él.
Mientras que otros hilos comparten un mismo hilo del kernel. Por lo tanto no hay mucho hilos del kernel (o sea
no hay una correspondencia uno a uno)
Desventajas. No se implementa sino que se usa el modelo uno a uno (el hardware actual se presta para eso).
12. ¿Qué cuestiones surgen con las llamadas al sistema fork y exec, en los programas multihilos?
- ¿Fork () duplica solo el hilo de llamada (el llamador) o todos los hilos?. ¿Se va a duplicar un proceso con todos los
hijos creados en ese proceso padre? o solamente va a continuar en el que hizo la llamada al sistema? Entonces
la semántica de las llamadas fork y exec cambian de un programa mono a uno multihilo. Si un hilo en un
programa llama a fork hace que se todos los hilos se dupliquen en el nuevo proceso? o el nuevo proceso es un
solo hilo?
- Algunos sistemas UNIX tiene las dos versiones una que duplica todos los hilos y otra que duplica solo el hilo que
invoca la llamada al sistema fork. la llamada al sistema exec generalmente funciona de la misma manera que lo
descrito en el capítulo 3 o sea reemplaza el programa que contenía el proceso hijo por otro programa nuevo que
se especifica. Cuando se llama exec no se duplican todos los hilos ya que se va a reemplazar por esto se dice que
funciona igual.
- Entonces para saber cual version de fork usar la pregunta seria se va a llamar a exec o no ? si lo va a llamar
entonces no conviene que el nuevo proceso herede todos los hilos y si no lo llama entonces sería bueno que
herede todos los hilos ya creados.
- Es un método UNIX que se utiliza para notificar a un proceso que se ha producido un evento particular .
- Por ejemplo si se utiliza un controlador de señales para procesar señales entonces la señal se genera por un
evento particular, luego la señal se entrega a otro proceso, y la señal es manejada por uno de dos manejadores
de señal (definido por defecto o por el usuario ← estos son código que se va ejecutar para “atender la señal” ).
las interrupciones son al hardware lo que las señales son al software.
Una señal (signal) se utiliza en sistemas UNIX para notificar a un proceso que un evento particular ha ocurrido.
Se puede recibir una señal sincrónica o asincrónicamente, dependiendo de la fuente y el motivo del evento que
se señala. Todas las señales, sincrónicas o asincrónicas, siguen el mismo patrón:
Ejemplos de señales sincrónicas incluyen acceso ilegal de memoria y división en 0. Si un programa en ejecución
realiza cualquiera de estas acciones, se genera una señal. Las señales síncronas se entregan al mismo proceso
que realizó la operación que causó la señal (esa es la razón por la que se consideran sincronico).
Cuando una señal es generada por un evento externo a un proceso en ejecución, El proceso recibe la señal de
forma asíncrona. Los ejemplos de tales señales incluyen finalizar un proceso con pulsaciones de teclas
específicas (como <control> <C>) y Tener un temporizador para terminar. Por lo general, se envía una señal
asincrónica a otro proceso.
Una señal puede ser manejada por uno de los dos posibles manejadores:
Cada señal tiene un controlador de señal predeterminado que el kernel ejecuta al manejar esa señal Esta acción
predeterminada puede ser anulada por un controlador de señal definido por el usuario que se llama para
manejar la señal. Las señales se manejan en diferentes formas. Algunas señales pueden ser ignoradas, mientras
que otras (por ejemplo, un acceso ilegal a la memoria) se manejan terminando el programa.
El manejo de señales en programas de un solo hilo es sencillo: las señales siempre se entregan a un proceso. Sin
embargo, entregar señales en programas multihilos es más complicado, donde un proceso puede tener varios
hilos.
15. ¿Por qué se dice que las señales son al Software y las interrupciones son al hardware? - respondida arriba
Esto lo hace así por una cuestión de ganancia de espacio. Windows tiene un área que es el ejecutivo (ETHREAD),
luego tiene la capa del kernel (KTHREAD) y luego en el espacio de usuario tiene el TEB
La mayor cantidad de información es de usuario y al ser de usuario puede ser expulsable y llevada a disco para
que el espacio en el kernel no sea tan grande eso le permitiría manejar un grado de multiprogramación mayor al
tener menos espacio en el kernel.
- En LINUX, no se habla de hilos sino de tareas. se puede usar fork o clone() este último es mucho más
flexible que fork porque se le puede pasar parámetros y entonces ese hilo podría crear un proceso com
lo hacia con fork o podría crear un hilo si la cantidad de recursos que está compartiendo es mayor por
ejemplo, linux no distingue entre procesos e hilos en su lugar usa el término de tarea y cuando se refiere
a un flujo de control de programa le llama tarea directamente y cuando se invoca clone se pasa un
conjunto de indicadores y parámetros que determinan todo lo que se quiere compartir entre las tareas
principales padres y los hijos.
- Según los parámetros especificados se puede usar por ejemplo para crear un hilo.