Possibili stati per i thread nativi su Android?

Question

Quali sono tutti i possibili stati del thread durante l'esecuzione per i thread nativi (C/C++) su un dispositivo Android? Sono uguali a Java Thread States? Sono thread di Linux? Thread POSIX?

non richiesto, ma punti bonus per fornire esempi di cosa può causare un thread entrare ogni stato.

Edit: Come richiesto, ecco la motivazione:

Sto progettando l'interfaccia per un profiler di campionamento che funziona con nativo C/codice C++ su Android. I rapporti del profiler mostreranno gli stati del thread nel tempo. Ho bisogno di sapere che cosa sono tutti gli stati al fine di a) sapere quanti stati distinti ho bisogno di possibilmente per differenziare visivamente, e b) progettare uno schema di colori che visivamente differenzia e raggruppa gli stati desiderabili rispetto agli stati indesiderabili.

Answer 1

mi è stato detto che le discussioni native su Android sono processi solo leggeri. Questo è d'accordo con quello che ho trovato per Linux in generale. Citando this wiki page:

Procedimento (che include un filetto) su una macchina Linux può essere in uno dei seguenti stati:

• TASK_RUNNING - Il processo si sia in esecuzione su una CPU o attesa essere giustiziato.
• TASK_INTERRUPTIBLE - Il processo è sospeso (letto) fino a qualche condizione diventa vera. Aumentare un interrupt hardware, rilasciare una risorsa di sistema che il processo è in attesa o fornire un segnale sono esempi di condizioni che potrebbero attivare il processo (riportare il suo stato a TASK_RUNNING). In genere bloccando le chiamate IO (disco/rete), l'attività viene contrassegnata come TASK_INTERRUPTIBLE. Non appena i dati in attesa sono pronti per essere letti, un interrupt viene generato dal dispositivo e il gestore di interrupt modifica lo stato dell'attività su TASK_INTERRUPTIBLE. Anche i processi in modalità inattiva (ovvero che non eseguono alcuna attività) dovrebbero essere in questo stato.
• TASK_UNINTERRUPTIBLE - Come TASK_INTERRUPTIBLE, ad eccezione del fatto che l'invio di un segnale al processo di sospensione lascia il suo stato invariato. Questo stato del processo è usato raramente. È utile, tuttavia, in determinate condizioni specifiche in cui un processo deve attendere fino a quando un dato evento si verifica senza essere interrotto. Idealmente non troppi compiti saranno in questo stato.
  • Ad esempio, questo stato può essere utilizzato quando un processo apre un file di dispositivo e il driver di periferica corrispondente inizia a sondare per un dispositivo hardware corrispondente. Il driver del dispositivo non deve essere interrotto fino a quando il sondaggio non è completo, o il dispositivo hardware può essere lasciato in uno stato imprevedibile.
  • operazioni di scrittura atomiche possono richiedere un compito contrassegnate come UNINTERRUPTIBLE
  accesso
  • NFS volte provoca processi di accesso vengano contrassegnati come UNINTERRUPTIBLE lettura/scrittura da/a disco può essere contrassegnato dal simbolo per una frazione di secondo
  • I/O a seguito di un errore di pagina segna un processo UNINTERRUPTIBLE
  • I/O sullo stesso disco a cui si accede per errori di pagina può risultare in un processo contrassegnato come UNINTERRUPTIBLE
  • programmatori possono contrassegnare un'attività come UNINTERRUPTIBLE invece di utilizzare INTERRUPTIBLE
• TASK_STOPPED - esecuzione processo viene bloccato; il processo entra in questo stato dopo aver ricevuto un segnale SIGSTOP, SIGTSTP, SIGTTIN o SIGTTOU.
• TASK_TRACED - L'esecuzione del processo è stata interrotta da un debugger.
• EXIT_ZOMBIE - esecuzione processo viene terminato, ma il processo genitore non ha ancora pubblicato un invito wait4() o waitpid() sistema. Il sistema operativo non cancellerà i processi di zombi finché il genitore non emetterà una chiamata simile a wait().
• EXIT_DEAD - Lo stato finale: il processo è stato rimosso dal sistema poiché il processo padre ha appena rilasciato una chiamata wait4() o waitpid() sistema per esso. Cambiando il suo stato da EXIT_ZOMBIE a EXIT_DEAD si evitano le condizioni di gara a causa di altri thread di esecuzione che eseguono chiamate simili a wait() sullo stesso processo.

Edit: Eppure il Dalvik VM Debug Monitor fornisce diversi stati. Dalla sua documentazione:

"stato filo" deve essere uno di:

1 - running (ora di esecuzione o pronto a farlo)
2 - sleeping (in Thread.sleep ())
3 - monitor (bloccato su un blocco del monitor)
4 - waiting (in Objec t.wait())
5 - initializing
6 - starting
7 - native (codice nativo esecuzione)
8 - vmwait (in attesa di una risorsa VM)

"sospeso "[un flag separato nella struttura dati] sarà 0 se il thread è in esecuzione, 1 in caso contrario.

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. 

Questi stati non sono molto ben spiegato - non vedo la differenza tra BLOCCATO E in attesa, per esempio.

È interessante notare che non v'è stato 'RUNNING' - fanno questi dispositivi sempre fanno nulla?

Answer 3

Se si progetta un'app di sistema che deve lavorare con i thread in modo ancora più avanzato rispetto all'usuale app, per prima cosa, inizierò esaminando quale API è disponibile su Android per accedere ai thread.

La risposta è pthread = thread POSIX, con il file di intestazione pthread.h, implementato nella libreria Bionic C. Quindi hai il punto di partenza per sapere cosa puoi ottenere.

Un'altra cosa è che Android non implementa un'interfaccia pthread completa, solo il sottoinsieme necessario per l'esecuzione di Android. Ulteriori informazioni sui thread + Bionic here e come essi interagiscono con Java e VM sono descritti here. Inoltre ritengo che il thread sia effettivamente un processo, poiché il mio codice usa setpriority (PRIO_PROCESS, gettid(), pr); per impostare la priorità del nuovo thread - Non ricordo dove ho ottenuto queste informazioni, ma funziona.

Presumo che il thread possa essere in esecuzione, terminato o bloccato (ad esempio attesa dello stato di mutex), ma questa è la mia conoscenza un po 'limitata poiché non ho mai avuto bisogno di altro stato del thread.

Ora la domanda è se la tua app può effettivamente recuperare questi stati utilizzando l'API disponibile in NDK e se ci sono più stati, se i tuoi utenti sarebbero davvero interessati a sapere.

In ogni caso, è possibile iniziare visualizzando stati di thread eventualmente incompleti e, se gli utenti si interessano veramente, si apprenderanno altri stati dal feedback e dalle richieste degli utenti.