Насколько независимы потоки внутри одного и того же процесса? - PullRequest
3 голосов
/ 22 января 2009

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

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

Я не уверен, что то же самое с потоками внутри процесса: если один зависает, другие не затронуты? Другими словами, могу ли я запустить «сторожевой» поток, который контролирует другие потоки и, например, уничтожает и воссоздает висячие потоки? Например, если у меня есть пул потоков, который я не хочу осушать случайными зависаниями.

Ответы [ 6 ]

4 голосов
/ 22 января 2009

Потоки независимы, но есть разница между процессом и потоком, и в том, что в случае процессов операционная система делает больше, чем просто "убивает" его. Это также убирает после этого.

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

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

Таким образом, реальный ответ на ваш вопрос: нет, вы не можете убивать темы трудным путем.

Если вы просто попросите закрыть поток, это будет по-другому, потому что тогда поток все еще находится под контролем и может очищать и закрывать ресурсы перед завершением, но вызов функции API, такой как "KillThread" или подобный, плох.

1 голос
/ 22 января 2009

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

Можно отслеживать другие темы из потока. В зависимости от вашей платформы существуют применимые API-интерфейсы: я рекомендую их использовать, поскольку вы не указали для какой ОС вы пишете.

0 голосов
/ 24 января 2009

В документации по Java есть довольно хороший обзор некоторых ловушек уничтожения и приостановки потоков, объясняющий, почему методы, которые это делают, устарели. По сути, если вы ожидаете, что сможете убить поток, вы должны быть очень, очень осторожны, чтобы он работал без какого-либо повреждения. Если поток завис, это, вероятно, из-за ошибки ... в этом случае его уничтожение может привести к повреждению.

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Если вам нужно что-то убить, используйте процессы.

0 голосов
/ 22 января 2009

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

0 голосов
/ 22 января 2009

Простой ответ - да.

Как правило, хотя код в потоке будет обрабатывать сам этот вероятный бред. Чаще всего многие API, выполняющие операции, которые могут зависать, имеют собственные функции тайм-аута.

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

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

0 голосов
/ 22 января 2009

Вы не упомянули о платформе, но, насколько мне известно, ядро ​​NT планирует потоки, а не обрабатывает и угрожает им независимо таким образом. На других платформах это может быть и не так (некоторые платформы, такие как Windows 3.1, не используют вытесняющую многопоточность, и если один поток идет в бесконечном цикле, это влияет на все).

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