2010-05-22 2 views
1

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

В аппаратном обеспечении это просто: вместо процессора «ожидание», чтобы увидеть, произошло ли что-то, компонент отправляет запрос прерывания.

Но как это работает, например, при переходе от мыши? Я предполагаю следующее: если мышь посылает сигнал («перемещается»), операционная система вычисляет свою новую позицию p, затем проверяет, какая программа рисуется на экране, сообщает, что позиция программы p, тогда сама программа проверяет, объект находится в точке p, проверяет, связаны ли какие-либо обработчики событий с указанным объектом и, наконец, запускает их.

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

Где моя интуиция терпит неудачу? Я понимаю, что даже «медленные» 500-мегагерцовые процессоры выполняют 500 миллионов операций в секунду, но все же кажется, что слишком много работы для такого простого события.

Заранее благодарен!

+0

Будьте осторожны с такими понятиями, как «неэффективность», потому что эффективность всегда относительна, а когда процессоры работают от 6 до 9 порядков быстрее, чем мы, интуиция о том, что эффективна, нельзя доверять. Это помогает рассматривать его в количественном выражении. –

+0

... и BTW, даже запрос прерывания в процессоре по-прежнему выполняется оживленным ожиданием на уровне микрокода. В автомате состояния микрокода есть точка, в которой запрашивается строка запроса прерывания, чтобы узнать, следует ли запускать последовательность прерываний. –

ответ

5

Подумайте о таких событиях, как сетевые пакеты, поскольку они обычно обрабатываются схожими механизмами. Теперь подумайте, что ваша мышь отправляет пару сотен пакетов в секунду, максимум, и они составляют около 6 байтов. Это ничто по сравнению с возможностями пропускной способности современных машин.

На самом деле вы можете сделать гибкий графический интерфейс, где каждое движение мыши буквально отправило сетевой пакет (86 байтов, включая заголовки) на аппаратное обеспечение, построенное около 20 лет назад: X11, основной механизм графического интерфейса для Linux и большинства других Unix, может делают именно это и часто используются таким образом в конце 80-х и начале 90-х годов. Когда я впервые использовал графический интерфейс, это было то, что было, и, хотя он не был отличным по нынешним стандартам, учитывая, что он работает на машинах с частотой 20 МГц, он действительно полезен.

0

По каким критериям вы определяете, что это слишком много? Это столько же, сколько и должно быть. События мыши происходят в миллисекундах. Работа, требуемая для получения кода обработчика, вероятно, измеряется в микросекундах. Это просто не проблема.

+0

Я думаю, что он точно просит некоторую «количественную оценку» рабочей нагрузки, необходимой для понимания, слишком ли это или нет. (очевидно, это не так, поскольку это действительно работает, но лучше, когда у вас есть некоторые номера, чтобы посмотреть) – nico

2

Мое понимание заключается в следующем:

Каждое приложение/окно имеет цикл событий, который заполняется с помощью ОС-прерываний. Движется мышь. Все окна имеют отдельную очередь/процесс, я знаю (в окнах с 3.1)

Каждое окно имеет элементы управления. Окно выведет эти события на элементы управления. Элемент управления определяет, является ли событие для него.

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

0

Вы почти правы - хотя события мыши происходят с фиксированной скоростью (например,USB-мышь на linux дает вам события 125 раз в секунду по умолчанию - это действительно не так много), и ОС или приложение могут дополнительно слить события мыши, которые близки по времени или положению, прежде чем отправлять его для обработки.