Mögliche Status für native Threads auf Android?

Mir wurde gesagt, dass native Threads auf Android nur leichte Prozesse sind. Das stimmt mit dem überein, was ich für Linux im Allgemeinen gefunden habe. Zitieren diese Wiki-Seite :

  

Ein Prozess (der einen Thread enthält) auf einem Linux-Rechner kann sich in einem der folgenden Zustände befinden:

     

• TASK_RUNNING - Der Prozess wird entweder auf einer CPU ausgeführt oder wartet darauf ausgeführt zu werden.
  
• TASK_INTERRUPTIBLE - Der Prozess wird angehalten (nicht aktiv), bis eine Bedingung erfüllt ist. Das Einleiten eines Hardware-Interrupts, das Freigeben einer Systemressource, auf die der Prozess wartet, oder das Liefern eines Signals sind Beispiele für Bedingungen, die den Prozess möglicherweise aufwecken (seinen Status zurück zu TASK_RUNNING bringen). In der Regel werden blockierende E / A-Aufrufe (Festplatte / Netzwerk) dazu führen, dass die Task als TASK_INTERRUPTIBLE gekennzeichnet wird. Sobald die Daten, auf die sie wartet, gelesen werden können, wird ein Interrupt vom Gerät ausgelöst, und der Interrupt-Handler ändert den Status der Task in TASK_INTERRUPTIBLE. Auch Prozesse im Leerlaufmodus (dh keine Task ausführen) sollten sich in diesem Zustand befinden.
  
• TASK_UNINTERRUPTIBLE - Wie TASK_INTERRUPTIBLE , außer dass die Ausgabe eines Signals an den Schlafprozess seinen Zustand unverändert lässt. Dieser Prozesszustand wird selten verwendet. Es ist jedoch unter bestimmten spezifischen Bedingungen wertvoll, in denen ein Prozess warten muss, bis ein bestimmtes Ereignis eintritt, ohne unterbrochen zu werden. Idealerweise befinden sich nicht zu viele Aufgaben in diesem Zustand.   
  • Dieser Status kann beispielsweise verwendet werden, wenn ein Prozess eine Gerätedatei öffnet und der entsprechende Gerätetreiber nach einem entsprechenden Hardwaregerät sucht. Der Gerätetreiber darf nicht unterbrochen werden, bis das Sondieren abgeschlossen ist oder das Hardwaregerät in einem unvorhersehbaren Zustand verbleibt.
    
  • Atomare Schreiboperationen erfordern möglicherweise, dass eine Aufgabe als UNINTERRUPTIBLE markiert wird.
    
  • Der NFS-Zugriff führt manchmal dazu, dass Zugriffsprozesse als UNINTERRUPTIBLE markiert werden.   Lese- / Schreibvorgänge von / auf Platte können so für einen Bruchteil einer Sekunde markiert werden
    
  • I / O nach einem Seitenfehler markiert einen Prozess UNINTERRUPTIBLE
    
  • I / O auf dieselbe Festplatte, auf die für Seitenfehler zugegriffen wird, kann zu einem Prozess führen, der als UNINTERRUPTIBLE gekennzeichnet ist.
    
  • Programmierer können eine Aufgabe als UNINTERRUPTIBLE anstatt als INTERRUPTIBLE markieren
    
  
• TASK_STOPPED - Die Ausführung des Prozesses wurde gestoppt. Der Prozess tritt in diesen Zustand ein, nachdem er ein SIGSTOP , SIGTSTP , SIGTTIN oder SIGTTOU signal erhalten hat.
  
• TASK_TRACED - Die Ausführung des Prozesses wurde von einem Debugger gestoppt.
  
• EXIT_ZOMBIE - Die Ausführung des Prozesses wird beendet, aber der übergeordnete Prozess hat noch keinen wait4() oder waitpid() Systemaufruf ausgegeben. Das Betriebssystem wird die Zombie-Prozesse nicht löschen, bis der Elternteil einen wait() -ähnlichen Anruf ausgibt.
  
• EXIT_DEAD - Endgültiger Status: Der Prozess wird vom System entfernt, weil der Elternprozess gerade einen Systemaufruf wait4() oder waitpid() für diesen Prozess ausgegeben hat. Durch Ändern des Status von EXIT_ZOMBIE in EXIT_DEAD werden Race-Bedingungen aufgrund anderer Ausführungsthreads vermieden, die wait() - ähnliche Aufrufe für denselben Prozess ausführen.
  

Bearbeiten : Und dennoch der Dalvik VM Debug Monitor liefert verschiedene Zustände. Aus seiner Dokumentation:

  

"Thread-Status" muss einer der folgenden sein:

     

1 - running (wird jetzt ausgeführt oder ist dazu bereit)
  2 - sleeping (in Thread.sleep ())
  3 - monitor (blockiert auf einer Monitorsperre)
  4 - waiting (in Object.wait ())
  5 - initializing
  6 - starting
  7 - native (Ausführen von nativem Code)
  8 - vmwait (wartet auf eine VM-Ressource)

     

"suspended" [ein separates Flag in der Datenstruktur] ist 0, wenn der Thread läuft, 1 falls nicht.

Wenn Sie eine System-App entwickeln, die mit Threads noch weiter als mit der üblichen App arbeiten soll, würde ich zunächst untersuchen, welche API unter Android für den Zugriff auf Threads verfügbar ist.

Die Antwort lautet pthread = POSIX-Threads mit der Header-Datei pthread.h, implementiert in der Bionic C-Bibliothek. Sie haben also einen Ausgangspunkt, um zu wissen, was Sie erreichen können.

Eine andere Sache ist, dass Android keine vollständige Pthread-Schnittstelle implementiert, nur eine Untermenge, die für Android benötigt wird. Mehr zu Threads + Bionic hier und wie sie mit Java und Die VM ist hier beschrieben. Ich denke auch, dass Thread tatsächlich ein Prozess ist, da mein Code setpriority verwendet (PRIO_PROCESS, gettid (), pr); um die Priorität eines neuen Threads zu setzen - ich weiß nicht mehr wo ich diese Information bekommen habe, aber das funktioniert.

Ich nehme an, dass der Thread läuft, beendet oder blockiert ist (z. B. Warten auf Mutex), aber das ist mein ein bisschen begrenztes Wissen, da ich nie einen anderen Thread-Status brauchte.

Nun stellt sich die Frage, ob Ihre App diese Zustände tatsächlich mithilfe der verfügbaren API in NDK abrufen kann und ob es mehr Status gibt, wenn Ihre Benutzer wirklich daran interessiert wären.

Wie auch immer, Sie können damit beginnen, möglicherweise unvollständige Zustände von Threads anzuzeigen, und wenn es Ihren Benutzern wirklich wichtig ist, würden Sie aus Rückmeldungen und Anfragen von Benutzern etwas über andere Zustände erfahren.