У меня есть вопрос, преследующий меня долгое время.
Короткая версия:
Какова рабочая парадигма цикла сообщений Windows?
Подробная версия:
Когда мы запускаем приложение Windows (не консольное приложение)), мы можем взаимодействовать с ним через мышь или клавиатуру.Приложение извлекает все виды сообщений, представляющих наши движения, из своей очереди сообщений.И именно Windows отвечает за сбор наших действий и правильную подачу сообщений в эту очередь.Но не означает ли этот сценарий, что Windows должна бесконечно запускать ?
Я думаю, что Windows планировщик должен работать постоянно.Это может быть вызвано прерыванием по времени с заранее заданным интервалом.Когда планировщик срабатывает по временному прерыванию, он переключает текущий поток на следующий ожидающий поток.Один поток может получить свое сообщение только с помощью GetMessage () , когда он запланирован к запуску.
Мне интересно, будет ли запущено только одно приложение Windows, получит ли это приложение больше шансов получитьего сообщение?
Обновление - 1 (9:59 AM 11/22/2010)
Вот мой последний вывод:
Согласно Глава 7 Раздел: Приоритеты потоков
... Например, если основной поток вашего процесса вызывает GetMessage (), и система видит, что сообщения не ожидают, система приостанавливает поток вашего porcess., освобождает оставшуюся часть временного интервала потока и немедленно назначает ЦП другому ожидающему потоку.
Если для извлечения GetMessage не отображаются сообщения, основной поток процесса остается приостановленным и никогда не назначается ЦП.,Однако, когда сообщение помещается в очередь потока, система знает, что поток больше не должен приостанавливаться, и назначает поток на ЦП, если нет необходимости выполнять потоки с более высоким приоритетом.
Myтекущее понимание:
Чтобы система знала, когда сообщение помещается в очередь потока, я могу представить два возможных подхода:
1 - Централизованный подход : Система всегда отвечает за проверку очереди потока EVERY .Даже этот поток заблокирован из-за отсутствия сообщений.Если какое-либо сообщение доступно, система изменит состояние этого потока на планируемое.Но эта проверка, на мой взгляд, может быть реальным бременем для системы.
2 - Распределенный подход : Система не проверяет очередь каждого потока.Когда поток вызывает GetMessage и обнаруживает, что сообщение недоступно, система просто изменит состояние потока на заблокированное, что больше не будет планироваться.И в будущем, независимо от того, кто помещает сообщение в очередь заблокированного потока, именно этот " who " (не система) отвечает за изменение состояния потока с заблокированного готов (или в любом другом состоянии). Таким образом, этот поток дисквалифицирован для планирования системой и переквалифицирован кем-то еще в отношении GetMessage .Система заботится только о том, чтобы запланировать работоспособные потоки.Системе все равно, откуда берутся эти запланированные потоки.Этот подход позволит избежать бремени подхода 1 и, таким образом, избежать возможного узкого места.
На самом деле ключевой момент здесь заключается в том, как изменяются состояния потоков?Я не уверен, действительно ли это распределенная парадигма , как показано в appraoch 2, но может ли это быть хорошим вариантом?