История изменений

Я бы сначала проверил, на твоём месте. Перформанс такая штука, что без бенчмарков никуда.

А что ты хочешь?

Вот твой процесс взял тяжёлую задачу. А потом в очереди появилась лёгая задача.

Тут есть ровно два варианта:

- Он прерывает исполнение тяжёлой задачи и переключается на лёгкую. Но тогда это обычная вытесняющая многозадачность. И как вариант с несколькими тредами для разных приоритетов. В условиях ограниченных ресурсов можно играться количеством тредов (и их приоритетами), количеством приоритетов и размерами стеков. Да, если очень сильно захотеть, можно нагородить свой user-space scheduler, но таким занимаются, когда реально упираются в ресурсы, а не в теории, потому что работы много, а выхлоп не гарантирован (в современных ОС планировщики достаточно оптимизированны). Ещё есть Boost.Fiber для кооперативной многозадачности. В таком случае тебе нужно распихать по реализации тяжёлой задачи точки, где она будет проверять наличие лёгких задач и ставиться на паузу.

- Он выполняет тяжёлую задачу до конца, а потом берёт лёгкую. В таком случае не понимаю вопрос, ты уже нашёл priority queue. Просто бери каждый раз задачу с наивысшим приоритетом и всё. Но как ты верно заметил тяжёлая задача может затормозить лёгкую.

Других вариантов не существует в природе.

Я бы сначала проверил, на твоём месте. Перформанс такая штука, что без бенчмарков никуда.

А что ты хочешь?

Вот твой процесс взял тяжёлую задачу. А потом в очереди появилась лёгая задача.

Тут есть ровно два варианта:

- Он прерывает исполнение тяжёлой задачи и переключается на лёгкую. Но тогда это обычная вытесняющая многозадачность. И как вариант с несколькими тредами для разных приоритетов. В условиях ограниченных ресурсов можно играться количеством тредов (и их приоритетами), количеством приоритетов и размерами стеков. Да, если очень сильно захотеть, можно нагородить свой user-space scheduler, но таким занимаются, когда реально упираются в ресурсы, а не в теории, потому что работы много, а выхлоп не гарантирован (в современных ОС планировщики достаточно оптимизированны).

- Он выполняет тяжёлую задачу до конца, а потом берёт лёгкую. В таком случае не понимаю вопрос, ты уже нашёл priority queue. Просто бери каждый раз задачу с наивысшим приоритетом и всё. Но как ты верно заметил тяжёлая задача может затормозить лёгкую.

Других вариантов не существует в природе.

Я бы сначала проверил, на твоём месте. Перформанс такая штука, что без бенчмарков никуда.

А что ты хочешь?

Вот твой процесс взял тяжёлую задачу. А потом в очереди появилась лёгая задача.

Тут есть ровно два варианта:

- Он прерывает исполнение тяжёлой задачи и переключается на лёгкую. Но тогда это обычная вытесняющая многозадачность. И как вариант с несколькими тредами для разных приоритетов. В условиях ограниченных ресурсов можно играться количеством тредов (и их приоритетами), количеством приоритетов и размерами стеков. Да, если очень сильно захотеть, можно нагородить свой user-space scheduler, но таким занимаются, когда реально упираются в ресурсы, а не в теории, потому что работы много, а выхлоп не гарантирован (в современных ОС планировщики достаточно оптимизированны).

- Он выполняет тяжёлую задачу до конца, а потом берёт лёгкую. В таком случае не понимаю вопрос, ты уже нашёл priority queue. Просто бери каждый раз задачу с наивысшим приоритетом и всё.

Я бы сначала проверил, на твоём месте. Перформанс такая штука, что без бенчмарков никуда.

А что ты хочешь?

Вот твой процесс взял тяжёлую задачу. А потом в очереди появилась лёгая задача.

Тут есть ровно два варианта:

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

- Он выполняет тяжёлую задачу до конца, а потом берёт лёгкую. В таком случае не понимаю вопрос, ты уже нашёл priority queue. Просто бери каждый раз задачу с наивысшим приоритетом и всё.