Когда я должен рассмотреть изменение приоритета потока

Question

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

У меня вопрос, при каких обстоятельствах должен I конидер изменить приоритет потоков?

Answer 1

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

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

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

Наконец, это зависит от ОС. Если приоритет потока является полностью вторичным по отношению к приоритету процесса, то расстановка приоритетов потоков не должна быть «опасной»: единственное, что вы можете голодать - это вы сами. Но если ваши высокоприоритетные потоки предпочтительнее, чем потоки с обычным приоритетом других, не связанных приложений, то вы несете более широкую ответственность. Вы должны поднимать приоритеты только тем, которые выполняют небольшие объемы срочной работы. Определение «маленького» зависит от того, на каком устройстве вы находитесь - с многоядерным процессором 3 ГГц вам многое не по плечу, но у мобильного устройства могут быть ложные ожидания в реальном времени, которые могут сломать приложения пользовательского уровня.

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

Answer 2

Не много. Единственный раз, когда мне приходилось менять приоритеты потоков в направлении позитив , был поток пользовательского интерфейса. Пользовательский интерфейс должен быть очень быстрым, чтобы приложение чувствовало себя хорошо, поэтому во многих случаях лучше отдавать приоритет рисованию нитей выше, чем другим. Например, поток рассылки событий Swing по умолчанию работает с приоритетом 6 (на 1 больше, чем по умолчанию).

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

Answer 3

Я думаю, это зависит от того, в каком направлении вы смотрите на изменение приоритета.

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

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

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

Answer 4

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

Answer 5

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

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

В противном случае, это часто хак.