Возможные состояния для собственных потоков на Android? - PullRequest
9 голосов
/ 08 октября 2011

Каковы все возможные состояния потоков во время выполнения для собственных (C / C ++) потоков на устройстве Android?Они такие же, как Состояния потоков Java ?Это нити Linux?Потоки POSIX?

Не требуется, но бонусные баллы за предоставление примеров того, что может привести к переходу потока в каждое состояние.

Редактировать : какпросил, вот мотивация:

Я разрабатываю интерфейс для профилировщика выборки, который работает с собственным кодом C / C ++ на Android.Отчеты профилировщика будут показывать состояния потоков с течением времени.Мне нужно знать, что представляют собой все состояния, чтобы: а) узнать, сколько разных состояний мне потребуется для визуальной дифференциации, и б) разработать цветовую схему, которая визуально дифференцирует и группирует желаемые состояния по сравнению с нежелательными состояниями.

Ответы [ 3 ]

8 голосов
/ 09 октября 2011

Мне сказали, что нативные потоки на Android - это просто облегченные процессы. Это согласуется с тем, что я нашел для Linux в целом. Цитирование этой вики-страницы :

Процесс (который включает в себя поток) на компьютере с Linux может находиться в любом из следующих состояний:

  • TASK_RUNNING - Процесс выполняется на ЦПУ или ожидает выполнения.
  • TASK_INTERRUPTIBLE - Процесс приостанавливается (спит) до тех пор, пока не выполнится какое-либо условие. Возникновение аппаратного прерывания, освобождение системного ресурса, которого ожидает процесс, или доставка сигнала - примеры условий, которые могут пробудить процесс (вернуть его состояние обратно в TASK_RUNNING). Обычно блокировка вызовов ввода-вывода (диск / сеть) приводит к тому, что задача помечается как TASK_INTERRUPTIBLE. Как только данные, которые он ожидает, готовы для чтения, устройство вызывает прерывание, и обработчик прерываний изменяет состояние задачи на TASK_INTERRUPTIBLE. Также процессы в режиме ожидания (то есть не выполняющие никаких задач) должны находиться в этом состоянии.
  • TASK_UNINTERRUPTIBLE - Как и TASK_INTERRUPTIBLE, за исключением того, что передача сигнала в спящий процесс оставляет его состояние без изменений. Это состояние процесса используется редко. Это ценно, однако, при определенных конкретных условиях, в которых процесс должен ждать, пока данное событие не произойдет, не прерываясь. В идеале не слишком много задач будет в этом состоянии.
    • Например, это состояние может использоваться, когда процесс открывает файл устройства и соответствующий драйвер устройства начинает поиск соответствующего аппаратного устройства. Драйвер устройства не должен прерываться до тех пор, пока зондирование не будет завершено, или аппаратное устройство может остаться в непредсказуемом состоянии.
    • Для атомарных операций записи может потребоваться пометить задачу как UNINTERRUPTIBLE
    • Доступ по NFS иногда приводит к тому, что процессы доступа помечаются как UNINTERRUPTIBLE таким образом, чтение / запись с / на диск может быть помечена за долю секунды
    • Ввод / вывод после сбоя страницы отмечает процесс UNINTERRUPTIBLE
    • Ввод / вывод на тот же диск, к которому осуществляется доступ для сбоев страниц, может привести к процессу, помеченному как UNINTERRUPTIBLE
    • Программисты могут пометить задачу как UNINTERRUPTIBLE вместо использования INTERRUPTIBLE
  • TASK_STOPPED - выполнение процесса остановлено; процесс переходит в это состояние после получения сигнала SIGSTOP, SIGTSTP, SIGTTIN или SIGTTOU.
  • TASK_TRACED - выполнение процесса было остановлено отладчиком.
  • EXIT_ZOMBIE - выполнение процесса прекращено, но родительский процесс еще не выполнил системный вызов wait4() или waitpid(). ОС не будет очищать процессы зомби, пока родитель не выполнит wait() -подобный вызов.
  • EXIT_DEAD - конечное состояние: процесс удаляется системой, поскольку родительский процесс только что выпустил системный вызов wait4() или waitpid(). Изменение его состояния с EXIT_ZOMBIE на EXIT_DEAD позволяет избежать условий гонки из-за других потоков выполнения, которые выполняют wait() -подобные вызовы в том же процессе.

Редактировать : И все же Dalvik VM Debug Monitor предоставляет различные состояния. Из документации:

"состояние потока" должно быть одним из:

1 - running (сейчас выполняется или готов к выполнению)
2 - sleeping (в Thread.sleep ())
3 - monitor (заблокировано при блокировке монитора)
4 - waiting (в Object.wait ())
5 - initializing
6 - starting
7 - native (выполнение собственного кода)
8 - vmwait (ожидание на ресурсе виртуальной машины)

«приостановлено» [отдельный флаг в структуре данных] будет 0, если поток запущен, 1, если нет.

4 голосов
/ 13 октября 2011

Если вы разрабатываете системное приложение, которое должно работать с потоками даже более сложным способом, чем обычное приложение, я бы сначала начал с изучения того, какой API доступен на Android для доступа к потокам.

Ответ таков:pthread = потоки POSIX с заголовочным файлом pthread.h, реализованные в библиотеке Bionic C.Таким образом, у вас есть отправная точка для знания того, чего вы можете достичь.

Другое дело, что Android не реализует полный интерфейс pthread, а только подмножество, необходимое для работы Android.Подробнее о потоках + Bionic здесь и о том, как они взаимодействуют с Java и VM, описано здесь .Также я чувствую, что поток на самом деле является процессом, так как мой код использует setpriority (PRIO_PROCESS, gettid (), pr);установить приоритет нового потока - я не помню, откуда я получил эту информацию, но это работает.

Я предполагаю, что поток может находиться в состоянии выполнения, завершения или блокировки (например, в ожидании мьютекса), но это моенемного ограниченные знания, так как мне никогда не требовалось другое состояние потока.

Теперь вопрос заключается в том, может ли ваше приложение действительно получать эти состояния, используя доступный API в NDK, и если есть больше состояний, если ваши пользователи будут действительно заинтересованызнать.

В любом случае, вы можете начать с отображения, возможно, неполных состояний потоков, и, если ваши пользователи действительно заботятся, вы узнаете о других состояниях из отзывов и запросов пользователей.

0 голосов
/ 08 октября 2011

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. 

Эти состояния не очень хорошо объяснены - я, например, не вижу разницы между BLOCKED и WAITING.

Интересно, что нет состояния «РАБОТА» - эти устройства когда-нибудь что-нибудь делают?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...