Асинхронный ввод/вывод: принципы и реализация

Введение

Форма обработки ввода/вывода

В информатике асинхронный ввод/вывод (также непоследовательный ввод/вывод) — это форма обработки ввода/вывода, которая позволяет другим процессам продолжать работу до завершения операции ввода/вывода. В Windows API для асинхронного ввода/вывода используется термин «перекрывающийся ввод/вывод». Операции ввода и вывода (I/O) на компьютере могут быть значительно медленнее обработки данных. Устройство ввода/вывода может включать механические компоненты, требующие физического перемещения, например, жесткий диск, ищущий дорожку для чтения или записи; это часто на порядки медленнее, чем переключение электрического тока. Например, во время дисковой операции, занимающей десять миллисекунд, процессор с тактовой частотой один гигагерц мог бы выполнить десять миллионов циклов обработки инструкций. Простой подход к I/O заключается в запуске доступа и ожидании его завершения. Однако такой подход, называемый синхронным вводом/выводом или блокирующим вводом/выводом, блокирует выполнение программы на время обмена данными, оставляя системные ресурсы неиспользуемыми. Если программа выполняет множество операций ввода/вывода (например, программа, в основном или в значительной степени зависящая от пользовательского ввода), процессор может большую часть времени простаивать в ожидании завершения этих операций. В качестве альтернативы можно запустить обмен данными и затем выполнять обработку, не требующую завершения ввода/вывода. Этот подход называется асинхронным вводом/выводом. Любая задача, зависящая от завершения ввода/вывода (включая использование входных значений и критические операции, подтверждающие завершение операции записи), все равно должна ждать завершения операции ввода/вывода и, следовательно, остается заблокированной, но другая обработка, не зависящая от операции ввода/вывода, может продолжаться. Существует множество функций операционной системы для реализации асинхронного ввода/вывода на различных уровнях. Фактически, одна из основных функций большинства операционных систем, за исключением самых простых, — выполнение хотя бы базового асинхронного ввода/вывода, хотя это может быть не очевидно для пользователя или программиста. В простейшем программном решении состояние аппаратного устройства периодически опрашивается для определения его готовности к следующей операции. (Например, операционная система CP/M была построена таким образом. Её семантика системных вызовов не требовала более сложной структуры ввода/вывода, хотя большинство реализаций были более сложными и, следовательно, более эффективными.) Прямой доступ к памяти (DMA) может значительно повысить эффективность системы, основанной на опросе, а аппаратные прерывания могут полностью устранить необходимость в опросе. Многозадачные операционные системы могут использовать функциональность, предоставляемую аппаратными прерываниями, скрывая сложность обработки прерываний от пользователя. Спулинг был одной из первых форм многозадачности, разработанной для использования асинхронного ввода/вывода. Наконец, многопоточность и явные асинхронные API в пользовательских процессах могут еще больше использовать асинхронный ввод/вывод, но за счет увеличения сложности программного обеспечения. Асинхронный ввод/вывод используется для повышения энергоэффективности и, в некоторых случаях, пропускной способности. Однако в некоторых случаях он может негативно влиять на задержку и пропускную способность.

In computer science, asynchronous I/O (also non sequential I/O) is a form of input/output processing that permits other processing to continue before the I/O operation has finished. A name used for asynchronous I/O in the Windows API is overlapped I/O. Input and output (I/O) operations on a computer can be extremely slow compared to the processing of data. An I/O device can incorporate mechanical devices that must physically move, such as a hard drive seeking a track to read or write; this is often orders of magnitude slower than the switching of electric current. For example, during a disk operation that takes ten milliseconds to perform, a processor that is clocked at one gigahertz could have performed ten million instruction processing cycles. A simple approach to I/O would be to start the access and then wait for it to complete. But such an approach, called synchronous I/O or blocking I/O, would block the progress of a program while the communication is in progress, leaving system resources idle. When a program makes many I/O operations (such as a program mainly or largely dependent on user input), this means that the processor can spend almost all of its time idle waiting for I/O operations to complete. Alternatively, it is possible to start the communication and then perform processing that does not require that the I/O be completed. This approach is called asynchronous input/output. Any task that depends on the I/O having completed (this includes both using the input values and critical operations that claim to assure that a write operation has been completed) still needs to wait for the I/O operation to complete, and thus is still blocked, but other processing that does not have a dependency on the I/O operation can continue. Many operating system functions exist to implement asynchronous I/O at many levels. In fact, one of the main functions of all but the most rudimentary of operating systems is to perform at least some form of basic asynchronous I/O, though this may not be particularly apparent to the user or the programmer. In the simplest software solution, the hardware device status is polled at intervals to detect whether the device is ready for its next operation. (For example, the CP/M operating system was built this way. Its system call semantics did not require any more elaborate I/O structure than this, though most implementations were more complex, and thereby more efficient.) Direct memory access (DMA) can greatly increase the efficiency of a polling based system, and hardware interrupts can eliminate the need for polling entirely. Multitasking operating systems can exploit the functionality provided by hardware interrupts, whilst hiding the complexity of interrupt handling from the user. Spooling was one of the first forms of multitasking designed to exploit asynchronous I/O. Finally, multithreading and explicit asynchronous I/O APIs within user processes can exploit asynchronous I/O further, at the cost of extra software complexity. Asynchronous I/O is used to improve energy efficiency, and in some cases, throughput. However, it can have negative effects on latency and throughput in some cases.

Процесс

Доступен в ранних версиях Unix. В многозадачной операционной системе обработка может быть распределена между различными процессами, которые выполняются независимо, имеют собственную память и обрабатывают собственные потоки ввода-вывода; эти потоки обычно соединяются в конвейеры. Создание и поддержка процессов достаточно затратно, поэтому это решение эффективно только при небольшом и относительно стабильном наборе процессов. Оно также предполагает, что отдельные процессы могут работать независимо, за исключением обработки ввода-вывода друг друга; если им требуется взаимодействие другими способами, их координация может оказаться сложной. Расширением этого подхода является программирование потоками данных, позволяющее создавать более сложные сети, чем просто цепочки, поддерживаемые конвейерами.

Выберите (/ опрос) петли

Доступен в BSD Unix и практически в любой другой системе с пакетом протоколов TCP/IP, который либо использует, либо основан на реализации BSD. Являясь разновидностью механизма опроса, цикл `select` использует системный вызов `select` для ожидания, пока не произойдет событие на файловом дескрипторе (например, когда появятся данные для чтения), не истечет время ожидания или не будет получен сигнал (например, при завершении дочернего процесса). Анализируя возвращаемые параметры вызова `select`, цикл определяет, какой файловый дескриптор изменился, и выполняет соответствующий код. Часто, для удобства, цикл `select` реализуется как цикл обработки событий, возможно, с использованием функций обратного вызова; такая ситуация особенно хорошо подходит для событийного программирования. Хотя этот метод надежен и относительно эффективен, он сильно зависит от парадигмы Unix, согласно которой "все есть файл"; любой блокирующий ввод-вывод, не связанный с файловым дескриптором, заблокирует процесс. Цикл `select` также требует возможности включить весь ввод-вывод в центральный вызов `select`; библиотеки, выполняющие собственный ввод-вывод, представляют в этом отношении особую проблему. Дополнительная потенциальная проблема заключается в том, что `select` и операции ввода-вывода все еще достаточно слабо связаны, поэтому результат `select` может оказаться неверным: если два процесса читают из одного файлового дескриптора (что, возможно, является плохим дизайном), `select` может указать на наличие данных для чтения, которые исчезли к моменту выполнения операции чтения, что приведет к блокировке; если два процесса записывают в один файловый дескриптор (что не редкость), `select` может указать на возможность немедленной записи, но запись все равно может быть заблокирована, поскольку буфер мог быть заполнен другим процессом, или из-за того, что запись слишком велика для доступного буфера, или по другим причинам не подходит для получателя. Цикл `select` не достигает максимальной эффективности системы, возможной, например, при использовании метода очередей завершения, поскольку семантика вызова `select`, позволяющая настраивать допустимый набор событий для каждого вызова, требует некоторого времени на перебор массива выбора при каждом вызове. Это создает небольшую нагрузку для пользовательских приложений, которым может потребоваться один файловый дескриптор для оконной системы и несколько для открытых файлов, но становится более серьезной проблемой по мере увеличения числа потенциальных источников событий и может затруднить разработку многих клиент-серверных приложений, как в случае проблемы C10k; другие асинхронные методы могут быть заметно более эффективными в таких случаях. Некоторые Unix-системы предоставляют системные вызовы с лучшей масштабируемостью, например, `epoll` в Linux (который заполняет возвращаемый массив выбора только теми источниками событий, на которых произошло событие), `kqueue` в FreeBSD и порты событий (и `/dev/poll`) в Solaris. SVR3 Unix предоставлял системный вызов `poll`. Возможно, более удачное название, чем `select`, но для целей данного обсуждения они по сути одинаковы. SVR4 Unix (и, следовательно, POSIX) предлагают оба вызова.

Available in BSD Unix, and almost anything else with a TCP/IP protocol stack that either utilizes or is modeled after the BSD implementation. A variation on the theme of polling, a select loop uses the select system call to sleep until a condition occurs on a file descriptor (e. g., when data is available for reading), a timeout occurs, or a signal is received (e. g., when a child process dies). By examining the return parameters of the select call, the loop finds out which file descriptor has changed and executes the appropriate code. Often, for ease of use, the select loop is implemented as an event loop, perhaps using callback functions; the situation lends itself particularly well to event driven programming. While this method is reliable and relatively efficient, it depends heavily on the Unix paradigm that "everything is a file"; any blocking I/O that does not involve a file descriptor will block the process. The select loop also relies on being able to involve all I/O in the central select call; libraries that conduct their own I/O are particularly problematic in this respect. An additional potential problem is that the select and the I/O operations are still sufficiently decoupled that select's result may effectively be a lie: if two processes are reading from a single file descriptor (arguably bad design) the select may indicate the availability of read data that has disappeared by the time that the read is issued, thus resulting in blocking; if two processes are writing to a single file descriptor (not that uncommon) the select may indicate immediate writability yet the write may still block, because a buffer has been filled by the other process in the interim, or due to the write being too large for the available buffer or in other ways unsuitable to the recipient. The select loop does not reach the ultimate system efficiency possible with, say, the completion queues method, because the semantics of the select call, allowing as it does for per call tuning of the acceptable event set, consumes some amount of time per invocation traversing the selection array. This creates little overhead for user applications that might have open one file descriptor for the windowing system and a few for open files, but becomes more of a problem as the number of potential event sources grows, and can hinder development of many client server applications, as in the C10k problem; other asynchronous methods may be noticeably more efficient in such cases. Some Unixes provide system specific calls with better scaling; for example, epoll in Linux (that fills the return selection array with only those event sources on which an event has occurred), kqueue in FreeBSD, and event ports (and /dev/poll) in Solaris. SVR3 Unix provided the poll system call. Arguably better named than select, for the purposes of this discussion it is essentially the same thing. SVR4 Unixes (and thus POSIX) offer both calls.

Сигналы (перерывы)

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

Функции обратного вызова

Доступен в классических Mac OS, VMS и Windows. Обладает многими характеристиками сигнального метода, поскольку по сути является тем же самым, хотя это и редко признается. Разница заключается в том, что каждый запрос ввода/вывода обычно может иметь свою собственную функцию завершения, в то время как сигнальная система использует единственный механизм обратного вызова. С другой стороны, потенциальная проблема использования обратных вызовов заключается в том, что глубина стека может стать неуправляемой, поскольку очень часто после завершения одного запроса ввода/вывода планируется следующий. Если это требование должно быть выполнено немедленно, первый обратный вызов не завершается (не "разворачивается" из стека) до того, как будет вызван следующий. Механизмы предотвращения этого (например, промежуточное планирование новых задач) усложняют систему и снижают производительность. Однако на практике это обычно не является проблемой, поскольку новый запрос ввода/вывода обычно возвращает управление сразу после запуска, позволяя стеку "развернуться". Эту проблему также можно избежать, предотвращая дальнейшие обратные вызовы с помощью очереди, пока не вернется первый обратный вызов.

Легкие процессы или нити

Легкие процессы (LWPs) или потоки доступны в большинстве современных операционных систем. Подобно использованию процессов, но с меньшими накладными расходами и без изоляции данных, которая затрудняет координацию потоков. Каждый LWP или поток сам по себе использует традиционный блокирующий синхронный ввод/вывод, что упрощает логику программирования; это распространенная парадигма, используемая во многих языках программирования, включая Java и Rust. Многопоточность требует использования механизмов синхронизации, предоставляемых ядром, и потокобезопасных библиотек. Этот метод не является оптимальным для приложений очень большого масштаба, таких как веб-серверы, из-за большого количества необходимых потоков. Этот подход также используется в среде выполнения языка программирования Erlang. Виртуальная машина Erlang использует асинхронный ввод/вывод, используя небольшой пул из нескольких потоков или иногда только один процесс, для обработки ввода/вывода от миллионов процессов Erlang. Обработка ввода/вывода в каждом процессе в основном осуществляется с использованием блокирующего синхронного ввода/вывода. Таким образом, высокая производительность асинхронного ввода/вывода сочетается с простотой обычного ввода/вывода (ср. модель Actor). Многие задачи ввода/вывода в Erlang сводятся к передаче сообщений, которые можно легко обрабатывать с помощью встроенного селективного приема. Волокна / Корутины можно рассматривать как аналогичный легковесный подход к реализации асинхронного ввода/вывода вне среды выполнения Erlang, хотя они не предоставляют тех же гарантий, что и процессы Erlang.

Очереди на заполнение/порт

Доступен в Microsoft Windows, Solaris, AmigaOS, DNIX и Linux (с использованием io uring, начиная с версии 5.1). Запросы ввода/вывода выполняются асинхронно, однако уведомления о завершении предоставляются посредством синхронизирующего механизма очереди в порядке их завершения. Как правило, используется в структуре основного процесса, основанной на конечном автомате (событийно-ориентированное программирование), что может существенно отличаться от процесса, не использующего асинхронный ввод/вывод или использующего другие подходы, что затрудняет повторное использование кода. Не требует дополнительных специальных механизмов синхронизации или потокобезопасных библиотек, а также не разделяет логический (код) и временной (события) потоки выполнения.

Флаги события

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

Канал ввода/вывода

Доступен на мейнфреймах IBM, Groupe Bull и Unisys. Канал ввода-вывода разработан для максимизации загрузки центрального процессора и увеличения пропускной способности за счет перекладывания большей части операций ввода-вывода на сопроцессор. Сопроцессор оснащен встроенным DMA, обрабатывает аппаратные прерывания, управляется основным процессором и прерывает его только при крайней необходимости. Эта архитектура также поддерживает так называемые канальные программы, выполняемые на канальном процессоре для обработки ресурсоемких задач ввода-вывода и протоколов.

Зарегистрированные В/В

Доступен в Windows Server 2012 и Windows 8. Оптимизирован для приложений, обрабатывающих большое количество небольших сообщений, чтобы добиться более высокой скорости операций ввода-вывода в секунду при снижении колебаний и задержки.

Реализация

Подавляющее большинство вычислительного оборудования общего назначения полностью полагается на два метода реализации асинхронного ввода-вывода: опрос и прерывания. Обычно оба метода используются совместно, а их соотношение сильно зависит от конструкции оборудования и требуемых характеристик производительности. (DMA само по себе не является независимым методом, а лишь способом выполнения большего объема работы за один опрос или прерывание.) Чистые системы опроса вполне возможны; небольшие микроконтроллеры (например, системы на базе PIC) часто строятся именно так. Системы CP/M также могли быть построены таким образом (хотя это случалось редко), с использованием DMA или без него. Кроме того, когда максимальная производительность необходима лишь для нескольких задач в ущерб любым другим потенциальным задачам, опрос может быть предпочтительным, поскольку накладные расходы на обработку прерываний могут быть нежелательны. (Обслуживание прерывания требует времени [и памяти] для сохранения как минимум части состояния процессора, а также времени, необходимого для возобновления прерванной задачи.) Большинство вычислительных систем общего назначения в значительной степени полагаются на прерывания. Чистая система прерываний возможна, хотя обычно требуется и компонент опроса, поскольку часто несколько потенциальных источников прерываний используют общую линию сигнала прерывания, в этом случае опрос используется в драйвере устройства для определения фактического источника. (Время определения также вносит вклад в снижение производительности системы прерываний. За прошедшие годы было проделано много работы для минимизации накладных расходов, связанных с обслуживанием прерываний. Современные системы прерываний довольно неторопливы по сравнению с некоторыми хорошо настроенными старыми системами, но общее повышение производительности оборудования значительно смягчило эту проблему.) Возможны и гибридные подходы, когда прерывание запускает начало серии асинхронных операций ввода-вывода, а опрос используется внутри этой серии. Эта техника распространена в высокоскоростных драйверах устройств, таких как сетевые или дисковые, где время, потерянное на возврат к задаче, прерванной прерыванием, больше, чем время до следующего необходимого обслуживания. (Современное оборудование ввода-вывода в значительной степени полагается на DMA и большие буферы данных для компенсации относительно неэффективной системы прерываний. Они используют опрос внутри циклов драйверов и могут демонстрировать огромную пропускную способность. В идеале, опросы по каждому элементу данных всегда успешны или, в худшем случае, повторяются лишь несколько раз.) В свое время этот гибридный подход был распространен в дисковых и сетевых драйверах, где не было DMA или значительной буферизации. Поскольку желаемые скорости передачи данных были выше, чем мог выдержать минимальный цикл из четырех операций на элемент данных (проверка бита, условный переход к самому себе, выборка и сохранение), аппаратное обеспечение часто строилось с автоматической генерацией состояний ожидания на устройстве ввода-вывода, что переносило проверку готовности данных из программного обеспечения на аппаратное обеспечение выборки или сохранения процессора и сокращало запрограммированный цикл до двух операций. (По сути, используя сам процессор в качестве DMA-контроллера.) Процессор 6502 предлагал необычный способ реализации цикла из трех элементов на элемент данных, поскольку он имел аппаратный вывод, который при активации напрямую устанавливал бит переполнения (Overflow) процессора. (Очевидно, при проектировании аппаратного обеспечения необходимо было проявлять большую осторожность, чтобы избежать перезаписи бита переполнения вне драйвера устройства!)

The vast majority of general purpose computing hardware relies entirely upon two methods of implementing asynchronous I/O: polling and interrupts. Usually both methods are used together, the balance depends heavily upon the design of the hardware and its required performance characteristics. (DMA is not itself another independent method, it is merely a means by which more work can be done per poll or interrupt.) Pure polling systems are entirely possible, small microcontrollers (such as systems using the PIC) are often built this way. CP/M systems could also be built this way (though rarely were), with or without DMA. Also, when the utmost performance is necessary for only a few tasks, at the expense of any other potential tasks, polling may also be appropriate as the overhead of taking interrupts may be unwelcome. (Servicing an interrupt requires time [and space] to save at least part of the processor state, along with the time required to resume the interrupted task.) Most general purpose computing systems rely heavily upon interrupts. A pure interrupt system may be possible, though usually some component of polling is also required, as it is very common for multiple potential sources of interrupts to share a common interrupt signal line, in which case polling is used within the device driver to resolve the actual source. (This resolution time also contributes to an interrupt system's performance penalty. Over the years a great deal of work has been done to try to minimize the overhead associated with servicing an interrupt. Current interrupt systems are rather lackadaisical when compared to some highly tuned earlier ones, but the general increase in hardware performance has greatly mitigated this.) Hybrid approaches are also possible, wherein an interrupt can trigger the beginning of some burst of asynchronous I/O, and polling is used within the burst itself. This technique is common in high speed device drivers, such as network or disk, where the time lost in returning to the pre interrupt task is greater than the time until the next required servicing. (Common I/O hardware in use these days relies heavily upon DMA and large data buffers to make up for a relatively poorly performing interrupt system. These characteristically use polling inside the driver loops, and can exhibit tremendous throughput. Ideally the per datum polls are always successful, or at most repeated a small number of times.) At one time this sort of hybrid approach was common in disk and network drivers where there was not DMA or significant buffering available. Because the desired transfer speeds were faster even than could tolerate the minimum four operation per datum loop (bit test, conditional branch to self, fetch, and store), the hardware would often be built with automatic wait state generation on the I/O device, pushing the data ready poll out of software and onto the processor's fetch or store hardware and reducing the programmed loop to two operations. (In effect using the processor itself as a DMA engine.) The 6502 processor offered an unusual means to provide a three element per datum loop, as it had a hardware pin that, when asserted, would cause the processor's Overflow bit to be set directly. (Obviously one would have to take great care in the hardware design to avoid overriding the Overflow bit outside of the device driver!)

Синтез

Используя только эти два инструмента (опрос и прерывания), все остальные формы асинхронного ввода-вывода, описанные выше, могут быть (и фактически являются) синтезированы. В среде, такой как виртуальная машина Java (JVM), асинхронный ввод-вывод может быть синтезирован, даже если среда, в которой работает JVM, вообще не предоставляет его. Это обусловлено интерпретируемым характером JVM. JVM может периодически выполнять опрос (или обрабатывать прерывание), чтобы инициировать внутреннее изменение потока управления, создавая видимость множества одновременных процессов, по крайней мере некоторые из которых, предположительно, существуют для выполнения асинхронного ввода-вывода. (Разумеется, на микроскопическом уровне параллелизм может быть довольно грубым и демонстрировать некоторые неидеальные характеристики, но внешне он будет выглядеть желаемым образом.) Именно в этом, на самом деле, заключается проблема использования опроса в любой форме для синтеза другого вида асинхронного ввода-вывода. Каждый цикл процессора, затраченный на опрос, пропадает впустую и уходит на накладные расходы, вместо выполнения полезной работы. Каждый цикл процессора, не затраченный на опрос, приводит к увеличению задержки реакции на ожидающие операции ввода-вывода. Найти приемлемый баланс между этими двумя противоположными факторами сложно. (Именно поэтому изначально были изобретены аппаратные системы прерываний.) Ключ к максимальной эффективности – минимизировать объем работы, который необходимо выполнить при получении прерывания для пробуждения соответствующего приложения. Второстепенно (но не менее важно) – метод, который само приложение использует для определения необходимых действий. Особенно проблематичны для эффективности приложения методы явного опроса, включая механизмы select/poll. Хотя базовые события ввода-вывода, которые их интересуют, скорее всего, генерируются прерываниями, взаимодействие с этими механизмами осуществляется посредством опроса и может занимать значительное время. Это особенно актуально для потенциально масштабного опроса, возможного с помощью select (и poll). Прерывания хорошо сочетаются с сигналами, функциями обратного вызова, очередями завершения и флагами событий, и такие системы могут быть очень эффективными.

Using only these two tools (polling, and interrupts), all the other forms of asynchronous I/O discussed above may be (and in fact, are) synthesized. In an environment such as a Java virtual machine (JVM), asynchronous I/O can be synthesized even though the environment the JVM is running in may not offer it at all. This is due to the interpreted nature of the JVM. The JVM may poll (or take an interrupt) periodically to institute an internal flow of control change, effecting the appearance of multiple simultaneous processes, at least some of which presumably exist in order to perform asynchronous I/O. (Of course, at the microscopic level the parallelism may be rather coarse and exhibit some non ideal characteristics, but on the surface it will appear to be as desired.) That, in fact, is the problem with using polling in any form to synthesize a different form of asynchronous I/O. Every CPU cycle that is a poll is wasted, and lost to overhead rather than accomplishing a desired task. Every CPU cycle that is not a poll represents an increase in latency of reaction to pending I/O. Striking an acceptable balance between these two opposing forces is difficult. (This is why hardware interrupt systems were invented in the first place.) The trick to maximize efficiency is to minimize the amount of work that has to be done upon reception of an interrupt in order to awaken the appropriate application. Secondarily (but perhaps no less important) is the method the application itself uses to determine what it needs to do. Particularly problematic (for application efficiency) are the exposed polling methods, including the select/poll mechanisms. Though the underlying I/O events they are interested in are in all likelihood interrupt driven, the interaction to this mechanism is polled and can consume a large amount of time in the poll. This is particularly true of the potentially large scale polling possible through select (and poll). Interrupts map very well to Signals, Callback functions, Completion Queues, and Event flags, such systems can be very efficient.