Asmxygen
Websvn
Builds
Bugs
FTP
Wiki
Telegram
Discord
RedditИнтересный факт, связанный с диспетчером задач: два равноправных теоретически процесса получают разные доли процессорного времени.
Попробуйте проделать такой эксперимент: запустите в последнем дистрибутиве Колибри два раза TRANTEST. Результат удивительный, в одном окне количество нарисованных треугольников в 2 раза больше, чем в другом!
Причем несправедливость эта присутствует в системе очень давно.
Scheduler
А можно ли это как-то использовать? Например некоторым задачам, на свое усмотрение, давать приоритет процессорного времени? Есть задачи по управлению оборудованием, там бы это пригодилось.
будем делать
Иван Поддубный
Я повел эксперимент еще дальше.
Запустил 3, 4 и 5 приложение.
Получается, на первый запущенный процесс выделяется времени как на 2 обычных процесса. На все последующие процессы время делится поровну.
Это хорошо заметно и на приложении FIRE2.
Я повел эксперимент еще дальше.
Запустил 3, 4 и 5 приложение.
Получается, на первый запущенный процесс выделяется времени как на 2 обычных процесса. На все последующие процессы время делится поровну.
Это хорошо заметно и на приложении FIRE2.
>Получается, на первый запущенный процесс выделяется времени как на 2 обычных процесса.
Это означает, что после создания потока надо было увеличить какой-то счетчик (то есть перейти на следующий процесс, а не топтаться на одном и том же).
Это означает, что после создания потока надо было увеличить какой-то счетчик (то есть перейти на следующий процесс, а не топтаться на одном и том же).
Как мне объяснил Поддубный, дело в предыдущем процессе - если процесс идет после icon, то он получает почти удвоенный квант времени (icon обычно быстро отказывается от своей доли), а если после процесса, использующего время по полной, то он получит лишь свой гарантированный квант времени.
Да, и на месте ICON может быть любой процесс, ожидающий события.
Соответственно исправить это положение можно, не выделяя кванта времени таким процессам. Тогда проверка на события должна осуществляться в шедулере (планировщике задач).
Соответственно исправить это положение можно, не выделяя кванта времени таким процессам. Тогда проверка на события должна осуществляться в шедулере (планировщике задач).
да совершенно логично. Так сделано даже в винде.
Даже если не активировать ожидающие события процессы, распределение процессорного времени несправедливо.
Например, работающий @RB получает событие от каждого движения мыши. Обработка события занимает много меньше 10мс.
Таким образом, процесс, стоящий в очереди сразу после @RB, получит почти удвоенный квант времени.
Чтобы промежутки времени распределялись справедливо, нужно вводить приоритеты процессов.
Например, работающий @RB получает событие от каждого движения мыши. Обработка события занимает много меньше 10мс.
Таким образом, процесс, стоящий в очереди сразу после @RB, получит почти удвоенный квант времени.
Чтобы промежутки времени распределялись справедливо, нужно вводить приоритеты процессов.
>Чтобы промежутки времени распределялись справедливо, нужно вводить приоритеты процессов.
ИМХО, приоритеты существуют для того, чтобы время распределялось неравномерно
ИМХО, приоритеты существуют для того, чтобы время распределялось неравномерно
Приоритеты создают для того чтобы отдать эти самые "лишние" куски квантов процессам\потокам которые в этом реально нуждаются.
Появляется конуренция за процессорное время.
Появляется конуренция за процессорное время.
Wildwest
Справедливо - не обязательно равномерно!
Однако с использованием динамически изменяемых приоритетов можно добиться более равномерного распределения процессора внутри одного класса задач.
Вопрос в том, какой выбать (придумать?) алгоритм для шедулера... сколько приоритетов, каковы правила их изменения?
Справедливо - не обязательно равномерно!
Однако с использованием динамически изменяемых приоритетов можно добиться более равномерного распределения процессора внутри одного класса задач.
Вопрос в том, какой выбать (придумать?) алгоритм для шедулера... сколько приоритетов, каковы правила их изменения?
http://www.mycomp.com.ua/text/7227;jses ... D6E4E74F35
Может тип проца причем? Тестилось ли на разных процах?
Может тип проца причем? Тестилось ли на разных процах?
Дело не в процессоре, а в алгоритмах планирования, диспетчеризации задач, которые используются в ядре ОС.
Предлагаю выделить структуру где будет описано по 4 бита для приоритета, т.е. 16 комбинаций. Меньше только 4, чего явно мало.
Who is online
Users browsing this forum: No registered users and 17 guests