Estados posibles para hilos nativos en Android?

Question

¿Cuáles son todos los posibles estados de subprocesos durante la ejecución de subprocesos nativos (C/C++) en un dispositivo Android? ¿Son los mismos que el Java Thread States? ¿Son hilos de Linux? ¿Hilos POSIX?

No es necesario, pero puntos de bonificación por proporcionar ejemplos de lo que puede hacer que un subproceso entre en cada estado.

Editar: Conforme a lo solicitado, aquí está la motivación:

estoy diseñando la interfaz para un generador de perfiles de muestreo que trabaja con nativos código C/C++ en Android. Los informes del perfilador mostrarán los estados del hilo a lo largo del tiempo. Necesito saber qué son todos los estados para a) saber cuántos estados distintos necesitaré para posiblemente diferenciar visualmente, yb) diseñar un esquema de colores que diferencia visualmente y agrupa los estados deseables frente a los estados indeseables.

Answer 1

Me han dicho que los hilos nativos en Android son solo procesos livianos. Esto concuerda con lo que he encontrado para Linux en general. Citando this wiki page:

un proceso (que incluye un hilo) en una máquina Linux puede estar en cualquiera de los siguientes estados:

• TASK_RUNNING - El proceso es o bien ejecutando en una CPU o en espera para ser ejecutado
• TASK_INTERRUPTIBLE - El proceso se suspende (duerme) hasta que se cumpla alguna condición. Elevar una interrupción de hardware, liberar un recurso del sistema que el proceso está esperando o entregar una señal son ejemplos de condiciones que pueden reactivar el proceso (poner su estado nuevamente en TASK_RUNNING). Normalmente, el bloqueo de llamadas IO (disco/red) dará como resultado que la tarea se marque como TASK_INTERRUPTIBLE. Tan pronto como los datos que está esperando estén listos para su lectura, el dispositivo genera una interrupción y el manejador de interrupciones cambia el estado de la tarea a TASK_INTERRUPTIBLE. También los procesos en modo inactivo (es decir, sin realizar ninguna tarea) deben estar en este estado.
• TASK_UNINTERRUPTIBLE - Como TASK_INTERRUPTIBLE, excepto que la entrega de una señal al proceso de suspensión no modifica su estado. Este estado del proceso rara vez se usa. Sin embargo, es valioso bajo ciertas condiciones específicas en las que un proceso debe esperar hasta que ocurra un evento determinado sin interrupción. Lo ideal es que no haya demasiadas tareas en este estado.
  • Por ejemplo, este estado se puede utilizar cuando un proceso abre un archivo de dispositivo y el controlador de dispositivo correspondiente comienza a buscar un dispositivo de hardware correspondiente. El controlador del dispositivo no debe interrumpirse hasta que se complete la exploración, o el dispositivo de hardware podría quedar en un estado impredecible.
  • operaciones de escritura atómicas pueden requerir una tarea para ser marcado como UNINTERRUPTIBLE
  acceso
  • NFS a veces resulta en procesos de acceso se marquen como UNINTERRUPTIBLE lecturas/escrituras desde/hasta el disco se pueden marcar de este modo por una fracción de segundo
  • E/S después de un error de página marca un proceso de UNINTERRUPTIBLE
  • de E/S en el mismo disco al que se accede por fallos de página puede resultar en un proceso marcado como UNINTERRUPTIBLE
  • los programadores pueden marcar una tarea como UNINTERRUPTIBLE en lugar de utilizar INTERRUPTIBLE
• TASK_STOPPED - La ejecución del proceso se ha detenido; el proceso entra en este estado después de recibir una señal SIGSTOP, SIGTSTP, SIGTTIN o SIGTTOU.
• TASK_TRACED - La ejecución del proceso ha sido detenida por un depurador.
• EXIT_ZOMBIE - la ejecución de los procesos terminen, pero el proceso padre aún no ha emitido una llamada wait4() o waitpid() sistema. El sistema operativo no borrará los procesos zombies hasta que el padre emita una llamada similar al wait().
• EXIT_DEAD - El estado final: el proceso está siendo removida por el sistema debido a que el proceso padre acaba de emitir una llamada wait4() o waitpid() sistema para él. Cambiar su estado de EXIT_ZOMBIE a EXIT_DEAD evita las condiciones de carrera debido a otros subprocesos de ejecución que ejecutan wait() -como llamadas en el mismo proceso.

Editar: Y sin embargo la Dalvik VM Debug Monitor proporciona diferentes estados. Desde su documentación:

"estado hilo" debe ser uno de:

1 - running (ahora ejecutar o listos para hacerlo)
2 - sleeping (en Thread.sleep ())
3 - monitor (bloqueado en un bloqueo de monitor)
4 - waiting (en Objec t.esperar())
5 - initializing
6 - starting
7 - native (ejecutar código nativo)
8 - vmwait (a la espera de un recurso VM)

"suspendida "[un indicador separado en la estructura de datos] será 0 si el hilo se está ejecutando, 1 si no.

Answer 2

Google:

Thread.State BLOCKED  The thread is blocked and waiting for a lock. 
Thread.State NEW   The thread has been created, but has never been started. 
Thread.State RUNNABLE  The thread may be run. 
Thread.State TERMINATED The thread has been terminated. 
Thread.State TIMED_WAITING The thread is waiting for a specified amount of time. 
Thread.State WAITING  The thread is waiting. 

Estos estados no están muy bien explicado - No veo la diferencia entre bloqueado y ESPERA, por ejemplo.

Curiosamente, no existe el estado 'EN EJECUCIÓN': ¿estos dispositivos alguna vez hacen algo?

Answer 3

Si diseña una aplicación de sistema que tiene que trabajar con hilos de una manera aún más avanzada que la aplicación habitual, primero comenzaría por examinar qué API está disponible en Android para acceder a los hilos.

La respuesta es pthread = hilos POSIX, con el archivo de cabecera pthread.h, implementado en la biblioteca Bionic C. Entonces tienes un punto de partida para saber lo que puedes lograr.

Otra cosa es que Android no implementa una interfaz pthread completa, solo un subconjunto necesario para ejecutar Android. Más sobre hilos + Bionic here, y cómo se interactúan con Java y VM se describe here. También creo que el hilo es en realidad un proceso, ya que mi código usa setpriority (PRIO_PROCESS, gettid(), pr); para establecer la prioridad del hilo nuevo - No recuerdo dónde obtuve esta información, pero esto funciona.

Supongo que el hilo puede estar en ejecución, finalizado o bloqueado (por ejemplo, en espera de mutex) estado, pero ese es mi conocimiento un poco limitado ya que nunca necesité otro estado de hilo.

Ahora la pregunta es si su aplicación realmente puede recuperar estos estados usando API disponible en NDK, y si hay más estados, si sus usuarios estarían realmente interesados ​​en saberlo.

De todos modos, puede comenzar mostrando estados de hilos posiblemente incompletos, y si a sus usuarios realmente les importa, conocerá otros estados a partir de los comentarios y solicitudes de los usuarios.