por eso mencioné algunas funciones como esas, porque me imagino que si quiero poner un hilo a dormir y que me libere la cpu debería usar algo como 'wait'
No, los procesos tienen diferentes
flags de estado ... en el caso de linux no podés "dormir" un hilo con una función equivalente al SuspendThread() de Windows, pero sí podés usar algo como un mutex para "esperar" (que es la manera que se recomienda en windows de todas maneras)
bien, yo entiendo que por ejemplo el kernel mediante el scheduler por ejemplo use round robin para los procesos, digamos.... pero en cuanto a los hilos de un proceso cómo los planifica? osea espera a que duerma uno para proseguir con otro, o espera señales del programa (programación, ejemplo 'wait'), o el kernel interviene directamente con los hilos y los planifica por ejemplo usando algun algoritmo de prioridades.
Linux usa el Completely Fair Scheduler.
Lo de arriba debería responder lo otro.
Eso es lo que quiero saber, porque si es así que el kernel lo hace, entonces lo que yo leí que el programador debía encargarse de todo está mal, y lo leí en varios lugares. por ejemplo usando una libreria.
Citame el texto y lo vemos, quizá está mal o quizá no ... pero no, si bien parecería que es "teóricamente posible" no estoy al tanto de un sistema operativo que permita cambiar el scheduler programáticamente desde modo usuario. Si se puede instruir al algoritmo de scheduling (repito: si lo permite, por que cada kernel es un mundo) podés dar "hints" sobre prioridad, affinity, etc ... pero eso es algo MUY diferente a "el kernel lo hace [...] yo leí que el programador debía encargarse [...] por ejemplo usando una libreria"
son controversias que nunca me terminan de aclarar la situación. tan sólo estoy interesado en saber quien lo hace y medianamente como lo hace. porque me imagino que si es el kernel como te dije antes, entonces debería poder reconocer cuantos hilos hay en un proceso, pero como te dije, he leído que no se da cuenta de la cantidad de hilos que tiene un proceso. por eso estaba casi convencido de que lo hacía el programador.
quien lo hace → El scheduler es el que planifica procesos u hilos
medianamente como lo hace → http://en.wikipedia.org/wiki/Completely_Fair_Scheduler#Algorithm
he leído que no se da cuenta de la cantidad de hilos que tiene un proceso →
cat /proc/`pgrep clementine`/status | grep Threads
ps -eLo pid,cmd,nlwp | grep clementine
Nah, no son controversias ... es que hablar de scheduling es hablar de teoría de sistemas operativos, después de las especificidades de cada sistema y sus algoritmos.
Ponele que en linux un proceso es un conjunto de hilos (o un hilo solo) que comparten espacio de memorias ... linux no diferencia entre procesos e hilos, sino que planifica tareas (tasks) y a esas las maneja según el tiempo de ejecución.
aparte si el kernel interviene tiene que poder reconocer que es un hilo y que es un proceso, y saber cuantos hilos hay en un proceso determinado, para poder planificarlos. algo como una lista de subprocesos, no lo se. pero yo leí que el kernel ve a un proceso en modo user como si fuera un sólo hilo, así tenga 5 o más.
Pensá en términos de código ... hay mil maneras de resolver un problema, no? planificar tareas es lo mismo, hay mil maneras de planificarlas y depende del kernel (libres tenés Linux, IllumOS, FreeBSD, OpenBSD, NetBSD, DragonflyBSD, Minix, Match de HURD, el de HaikuOS, etc ... entendés por que soy insistente con que primero pienses de manera más genérica? )
La explicación está en el link de Wikipedia.
pero entonces surge un inconveniente, quién provoca el context switch y cómo?
porque el programador pueda usar alguna función del sistema para provocar un switch, también puede poner a dormir un hilo para poder continuar con otro por ejemplo, ese tipo de cosas son mis dudas.
Ver
1)
http://www.informit.com/articles/article.aspx?p=101760&seqNum=32) Primera respuesta sobre mutexes
lo de la biblioteca que se encarga de todo te juro que lo leí no lo estoy inventando, se dice que la librería hace todo, crea, destruye, planifica, etc
Waaait, lo de crear y destruir hilos (que en el fondo son tareas) es válido ... planificar no, creo que habrás leído de CPU affinity?
http://www.cyberciti.biz/tips/setting-processor-affinity-certain-task-or-process.htmlEso no es planificar ... es un tema semántico nomás
pero eso no aclara nada porque lo que quisiera saber en ese caso es como hace el kernel para hacer el switch en base a la librería y como sincronizarse en si con la librería (yo asumiía que mediante systemcalls) pero cómo el kernel reconoce los hilos de un proceso? yo leí que no notaba más de un hilo
Ya creo que está contestado arriba ...
Saludos.
Mostrar Mensajes
