2011-09-22 19 views
5

Tengo dos códigos C++ uno llamado a y uno llamado b. Estoy corriendo en un Linux de 64 bits, usando la biblioteca de threading Boost.rendimiento entre diferentes procesos

El código a crea 5 hilos que permanecen en un bucle sin fin realizando alguna operación. El código b crea 5 subprocesos que permanecen en un bucle sin fin que invoca yield().

Estoy en una máquina quadcore ... Cuando invoco el código a solo, obtiene casi el 400% del uso de la CPU. Cuando se invoca el código b solo, obtiene casi el 400% del uso de la CPU. Ya lo esperaba.

Pero cuando se ejecutan los dos juntos, yo estaba esperando que el código b utiliza casi nada de CPU y un utilizar el 400%. Pero, en realidad, ambos están usando partes iguales de la CPU, casi el 200%.

Mi pregunta es, no cede() funciona entre diferentes procesos? ¿Hay alguna manera de hacerlo funcionar de la manera que esperaba?

+1

No tengo una respuesta, y creo que su pregunta es interesante porque sched_yield afirma poner el proceso en la parte posterior de la cola de ejecución, pero esto podría ser interesante para usted en términos de poner en duda la utilidad real de utilizando sched_yield: http://kerneltrap.org/Linux/Using_sched_yield_Improperly – Kevin

+1

Este fragmento de libro implica que la versión de su kernel de Linux importa: http://books.google.com/books?id=k_ocKY0iegsC&pg=PA168&lpg=PA168&dq=sched_yield+ a + otro + proceso & fuente = bl & ots = VgCNK6kGIu & sig = gyduzTS_2EY8v8wwwAE8MScSLsg & hl = en & ei = 68N7TqfOCcXPiAK6qrDVBw & sa = X & oi = book_result & ct = resultado & resnum = 3 & ved = 0CCgQ6AEwAg # v = onepage & q = sched_yield% 20to% 20another% 20process & f = false – Kevin

Respuesta

2

Linux utiliza prioridad de subprocesos dinámicos. La prioridad estática que establece con nice es solo limitar la prioridad dinámica. Cuando un subproceso usa su intervalo de tiempo completo, el kernel reducirá su prioridad y cuando un subproceso no use todo su timeslice (haciendo IO, llamando a wait/yield, etc.) el kernel aumentará su prioridad.

Así que mi conjetura es que el proceso b hilos tienen mayor prioridad, por lo que se ejecutan con más frecuencia.

3

Así que tiene 4 núcleos que ejecutan 4 hilos que pertenecen a A. Hay 6 hilos en la cola - 1 A y 5 B. Uno de los hilos A en ejecución agota su timeslice y vuelve a la cola. El planificador elige el siguiente subproceso ejecutable de la cola. ¿Cuál es la probabilidad de que este dibujo pertenezca a B? 5/6. Bien, este hilo se inició, llama a sched_yield() y vuelve a la cola. ¿Cuál es la probabilidad de que el siguiente hilo vuelva a ser un hilo B? 5/6 otra vez!

El proceso B obtiene el tiempo de CPU una y otra vez, y también obliga al kernel a realizar costosos cambios de contexto.

sched_yield está diseñado para un caso particular: cuando un hilo hace que otro hilo se pueda ejecutar (por ejemplo, desbloquea un mutex). Si desea que B espere mientras A está trabajando en algo importante, utilice algún mecanismo de sincronización que pueda poner a B en reposo hasta que A lo despierte

Cuestiones relacionadas