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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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