que - runnable java
¿Cómo se traducen las prioridades de subprocesos de Java a una prioridad de subprocesos de SO? (4)
Como estamos hablando de hilos, creo que esto nunca llega directamente al sistema operativo. La prioridad probablemente sea una pista al JRE sobre cómo programar el tiempo de CPU de cada hilo. Para lidiar con su ejemplo, debe haber algún tipo de algoritmo de "desempate".
Básicamente, esto va a estar en la parte superior de la prioridad del proceso del sistema operativo a menos que el JRE esté utilizando estándares de threading de terceros como POSIX en lugar de implementar todo internamente.
¿Cómo se traducen las prioridades de subprocesos de la API de java (1-10) a las prioridades de nivel del sistema operativo ya que la mayoría de los sistemas operativos no tienen niveles de prioridad de subprocesos (en términos de número) que coinciden con esto.
Entonces, teniendo en cuenta, ¿puede haber un escenario en el que dos o más subprocesos con diferentes prioridades finalmente obtengan la misma prioridad en el nivel del sistema operativo?
Por favor aclare, si hay alguna corrección en mi entendimiento.
De hecho, algunos niveles de prioridad pueden asignarse al mismo nivel de prioridad "nativo". Aquí está la lista (basada en el código de Hotspot en OpenJDK 6):
Solaris
- 1 ⇒ 0
- 2 ⇒ 32
- 3 ⇒ 64
- 4 ⇒ 96
- 5 - 10 ⇒ 127
Cabe destacar que en Solaris, no puede aumentar la prioridad de subproceso por encima de lo normal, solo disminuirla: el valor de prioridad para 5 es el mismo que cualquiera de los valores más altos.
Linux
- 1 - 10 ⇒ 4 - -5 (
nicevalores)
Es de destacar que en Linux, las diferentes prioridades de subprocesos en Java se asignan a distintos valores de prioridad a nivel nativo.
Windows
- 1 - 2 ⇒
THREAD_PRIORITY_LOWEST - 3 - 4 ⇒
THREAD_PRIORITY_BELOW_NORMAL - 5 - 6 ⇒
THREAD_PRIORITY_NORMAL - 7 - 8 ⇒
THREAD_PRIORITY_ABOVE_NORMAL - 9 - 10 ⇒
THREAD_PRIORITY_HIGHEST
Su comprensión es correcta: las prioridades de subprocesos de Java no se asignan correctamente a las prioridades de subprocesos del sistema operativo.
Como resultado, si su algoritmo se basa de alguna manera en los detalles del mapeo de prioridad de subprocesos, entonces se rompe, ya que variará según tantas variables. Por ejemplo, actualizar tu JRE o aplicar un paquete de revisión / servicio a tu sistema operativo podría romperlo, y por supuesto, solo ejecutarlo en un sistema operativo diferente también tendrá consecuencias.
Excepto en casos muy inusuales, usar solo dos prioridades será suficiente: Normal y Bajo. La mayoría del trabajo se realizará en un hilo Normal. La prioridad baja debe reservarse para los hilos que no se debe permitir que maten de hambre a los hilos de la prioridad Normal, en lugar de engullirlos y la potencia del procesador no utilizada.
Si bien puede obtener más grano fino que esto si lo desea, debe tener en cuenta que es probable que se pierda un mayor detalle en la plataforma de destino.
No estoy tan seguro de Sun JVM en Linux. Escribió un rápido programa de Java para engendrar 10 hilos con cada prioridad y calcular el método pi (4 * atan (1)) con BigDecimals 500,000 veces cada uno, unir cada hilo e informar el tiempo transcurrido para el método de ejecución. Sí, probablemente no sea el mejor ejemplo, pero mantenerlo básico.
$uname -r && grep bogomips /proc/cpuinfo
2.4.33.3
bogomips : 4312.26
$java -version 2>&1 |head -1
Java version "1.6.0_01"
$javac T.java && java -Xmx32m T
1:3112
2:2636
3:2662
4:3118
5:2870
6:3319
7:3412
8:3304
9:3299
10:3069
¡Parece que no hay una desviación que uno esperaría! Eso fue en una pequeña máquina virtual de Linux. Probémoslo en una losa real por si acaso, esta caja también está bastante activa, con promedios de carga raramente por debajo de 7, veamos cómo programamos en un entorno como este:
$uname -r && grep bogomips /proc/cpuinfo
2.6.9-67.ELsmp
bogomips : 3992.93
bogomips : 3990.00
$java -version 2>&1 |head -1
java version "1.4.2_14"
$javac T.java && java -Xmx32m T
1:63200
2:64388
3:62532
4:58529
5:62292
6:64872
7:64885
8:64584
9:61653
10:61575
Hmmm, no hay mucha variación aquí, no sé si 1.4 incluso mapeó los hilos. Probemos un cuadro de Windows. Sé que Windows tiene un esquema de prioridad de subproceso bastante agresivo. Cualquier cosa por encima de lo anecdótico normal consume mucho más. Como tal, aumentemos a 900,000 iteraciones en cada hilo:
C:/>java -version
java version "1.6.0_11"
C:/>java -Xmx32m T
1:12578
2:12625
3:11469
4:11453
5:10781
6:8937
7:10516
8:8406
9:9953
10:7391
Mucho de lo que estamos buscando, ¿no?