Асинхронды кіріс-шығыс өңдеуі

Кіріспе

Кіріс/шығыс өңдеу түрі

Компьютерлік ғылымда асинхронды I/O (сондай-ақ ретті емес I/O) – I/O операциясы аяқталғанға дейін басқа өңдеуді жалғастыруға мүмкіндік беретін кіріс/шығыс өңдеу түрі. Windows API-де асинхронды I/O үшін қолданылатын атау – I/O-ның үстінен жабысуы. Компьютердегі кіріс-шығыс (I/O) операциялары деректерді өңдеумен салыстырғанда өте баяу болуы мүмкін. I/O құрылғысына физикалық түрде қозғалуы тиіс механикалық құрылғылар кіре алады, мысалы, оқу немесе жазу үшін жол іздейтін қатты диск; бұл көбінесе электр тогының ауысуынан әлдеқайда баяу. Мысалы, дискіде он миллисекундқа созылатын операция кезінде бір гигагерц жиілікте жұмыс істейтін процессор он миллион нұсқаулық өңдеу циклын орындай алады. I/O-ға қарапайым тәсіл – кіруді бастау және оның аяқталуын күту. Бірақ синхронды I/O немесе I/O блоктау деп аталатын мұндай тәсіл, байланыс жүргізіліп жатқанда бағдарламаның ілгерілеуін тоқтатады, жүйе ресурстарын бос қалдырады. Бағдарлама көптеген I/O операцияларын орындағанда (мысалы, бағдарлама негізінен немесе көбінесе пайдаланушының енгізуіне байланысты), процессор I/O операцияларының аяқталуын күтіп, уақытының көп бөлігін бекер өткізе алады. Сонымен қатар, байланысты бастау және кейін I/O аяқталуын талап етпейтін өңдеуді орындау мүмкін. Бұл тәсіл асинхронды кіріс/шығыс деп аталады. I/O аяқталуына байланысты кез келген тапсырма (бұл кіріс мәндерін пайдалануды және жазу операциясы аяқталғанын растайтын маңызды операцияларды қамтиды) әлі де I/O операциясын аяқтауын күтуі керек, сондықтан бұғатталған болып қалады, бірақ I/O операциясына тәуелді емес басқа өңдеу жалғаса алады. Көптеген деңгейде асинхронды I/O-ны іске асыру үшін көптеген операциялық жүйе функциялары бар. Шын мәнінде, барлық операциялық жүйелердің ең негізгі функцияларының бірі – кем дегенде, негізгі асинхронды I/O түрін орындау, бірақ бұл пайдаланушы немесе бағдарламашы үшін айқын болмауы мүмкін. Ең қарапайым бағдарламалық шешімде аппараттық құрылғының жағдайы оның келесі операцияға дайындығын анықтау үшін үнемі тексеріледі. (Мысалы, CP/M операциялық жүйесі осылай құрылған. Оның жүйелік шақыру семантикасы бұдан да күрделі I/O құрылымын қажет етпеді, бірақ көптеген іске асырулар күрделірек және тиімдірек болды.) Тікелей жадқа қол жеткізу (DMA) дауыс беру жүйесінің тиімділігін арттырады, ал аппараттық үзілістер дауыс беруді толығымен жоюға мүмкіндік береді. Көп тапсырмалы операциялық жүйелер аппараттық үзілістермен қамтамасыз етілген функционалдылықты пайдалана алады, сонымен бірге үзілістерді басқарудың күрделілігін пайдаланушыдан жасырады. Spooling – асинхронды I/O-ны пайдалану үшін жасалған көп тапсырмалы жұмыстың алғашқы түрлерінің бірі. Соңында, пайдаланушы процестеріндегі көптіріктілік және айқын асинхронды I/O API қосымша бағдарламалық жасақтама күрделілігі есебінен асинхронды I/O-ны одан әрі пайдалана алады. Асинхронды I/O энергия тиімділігін және кейбір жағдайларда өнімділікті жақсарту үшін қолданылады. Алайда, кейбір жағдайларда ол кідіріс пен өнімділікке кері әсерін тигізуі мүмкін.

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-тің алғашқы нұсқаларында қолжетімді. Көп тапсырмалы операциялық жүйеде өңдеу әртүрлі процестерге таратылуы мүмкін, олар тәуелсіз жұмыс істейді, өз жадына ие және өздерінің I/O ағындарын өңдейді; мұндай ағындар көбінесе құбырлар арқылы байланысады. Процестерді құру және қолдау өте қымбат болғандықтан, бұл шешім процестер жиынтығы кішкентай және салыстырмалы түрде тұрақты болған жағдайда ғана тиімді. Сондай-ақ, жеке процестер бір-бірінің I/O ағындарын өңдеуден басқа тәуелсіз жұмыс істей алады деп есептеледі; егер олар басқа тәсілдермен байланысуы керек болса, оларды үйлестіру қиындық тудыруы мүмкін. Бұл тәсілдің кеңейтілген түрі – дерек ағыны бағдарламалау, ол құбырлар қолдайтын тізбектерге қарағанда күрделірек желілер құруға мүмкіндік береді.

Select (/ poll) бұрандалары

BSD Unix-те және BSD іске асырудан кейін пайдаланған немесе үлгіленген TCP/IP протоколы бар кез келген басқа да жүйеде қолжетімді. Сауалнама тақырыбының бір түрі ретінде, select циклы select жүйелік шақыруды пайдаланып, файл дескрипторында жағдай туғанға дейін (мысалы, оқуға деректер келгенде), белгілі бір уақыт өткенде немесе сигнал алынғанда (мысалы, бағынышты процесс аяқталғанда) күту режиміне көшеді. Select шақыруының қайтарым параметрлерін қарап, цикл қай файл дескрипторы өзгергенін анықтап, тиісті кодты орындайды. Әдетте, пайдаланудың ыңғайлылығы үшін select циклы оқиға циклы ретінде іске асырылады, мүмкін callback функцияларын қолдана отырып; мұндай жағдай оқиғаларға негізделген бағдарламалауға өте қолайлы. Бұл әдіс сенімді және салыстырмалы түрде тиімді болғанымен, ол Unix парадигмасына – «барлығы файл» деген қағидаға көп тәуелді. Файл дескрипторын қатыстырмайтын I/O операциялары процесті тоқтата алады. Select циклы сондай-ақ барлық I/O операцияларын орталық select шақыруына біріктіруге қабілетті болуға байланысты; өз I/O операцияларын жүзеге асыратын кітапханалар бұл жағынан қиындық тудыруы мүмкін. Тағы бір әлеуетті мәселе – select және I/O операцияларының жеткілікті деңгейде байланыспауы, нәтижесінде select нәтижесі жалған болуы мүмкін: егер екі процесс бір файл дескрипторынан оқыса (дизайннің нашарлығы), select оқуға деректердің бар екенін көрсетуі мүмкін, бірақ оқу операциясы орындалған кезде деректер жоғалып кеткен болуы мүмкін, соның салдарынан процесс тоқтап қалады; егер екі процесс бір файл дескрипторына жазса (бұл жиі кездеседі), select дереу жазуға болатындығын көрсетуі мүмкін, бірақ жазу операциясы бұрынғы процесс буферді толтырғандықтан немесе жазу буфердің көлемінен асып кеткендіктен немесе алушыға сәйкес келмегендіктен тоқтап қалуы мүмкін. Select циклы, мысалы, аяқталу тізімі әдісімен қол жеткізілетін жүйенің ең жоғары тиімділігіне жете алмайды, себебі select шақыруының семантикасы, қабылданатын оқиғалар жиынтығын әр шақыруда өзгертуге мүмкіндік береді, таңдау массивін қарап шығу үшін белгілі бір уақыт жұмсайды. Бұл бір файл дескрипторын терезелік жүйе үшін және бірнеше ашық файлдар үшін ашатын пайдаланушы бағдарламалары үшін аз жүктеме тудырады, бірақ әлеуетті оқиға көздерінің саны артқан сайын проблемаға айналады және көптеген клиент-сервер бағдарламаларын жасауға кедергі келтіруі мүмкін, мысалы, C10k мәселесінде; басқа асинхронды әдістер мұндай жағдайларда айтарлықтай тиімді болуы мүмкін. Кейбір Unix жүйелері жүйеге арналған шақыруларды ұсынады, олар жақсы масштабталуға мүмкіндік береді; мысалы, Linux-тағы epoll (қайтарылатын таңдау массивін тек оқиға болған оқиға көздерімен ғана толтырады), FreeBSD-дегі kqueue және Solaris-тегі оқиға порттары (және /dev/poll). 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 жүйелерінде қолжетімді. Сигнал әдісінің көптеген ерекшеліктерін мұралайды, себебі ол негізінен соған ұқсас, бірақ көбінесе осылай танылмайды. Ерекшелігі, әрбір I/O сұранысының әдетте өзіндік аяқталу функциясы болуы мүмкін, ал сигнал жүйесінде тек бір ғана қайта шақыру болады. Дегенмен, кері шақыруларды пайдаланудың потенциалды мәселесі – стек тереңдігі басқарылмайтын деңгейде өсуі мүмкін, себебі бір I/O операциясы аяқталғанда, екіншісін жоспарлау өте жиі кездеседі. Егер бұл талап дереу орындалса, келесі шақыру шақырылғанға дейін алғашқы кері шақыру стекте «ашылмай» қалады. Мұны болдырмау үшін жасалған жүйелер (мысалы, жаңа жұмысты «орталық» кестелеу) күрделілікті арттырып, өнімділікті төмендетеді. Бірақ, практикада бұл көбінесе мәселе тудырмайды, өйткені жаңа I/O операциясы жаңа I/O басталысымен бірге дереу қайта оралады, бұл стекке «еркін оралуға» мүмкіндік береді. Бұл мәселені кезек пайдалану арқылы, алғашқы кері шақыру аяқталғанға дейін қосымша кері шақырулардан аулақ болу арқылы да болдырмауға болады.

Жеңіл процестер немесе жіктер

Жеңіл салмақты процестер (ЖЖП) немесе жіптер қазіргі заманғы операциялық жүйелердің көпшілігінде қолжетімді. Процесс әдісіне ұқсас, бірақ төменгі жүктемемен және ағындарды үйлестіруге кедергі келтіретін деректерді оқшаулаусыз. Әрбір ЖЖП немесе жіп өзі бағдарламалау логикасын жеңілдететін дәстүрлі блоктау синхронды I/O-ны пайдаланады; бұл Java және Rust сияқты көптеген бағдарламалау тілдерінде қолданылатын кең таралған үлгі. Көп жіптілікте ядро ұсынған синхрондау механизмдері мен жіпке қауіпсіз кітапханаларды пайдалану қажет. Бұл әдіс веб-серверлер сияқты өте кең ауқымды қолданбалар үшін тиімді емес, себебі көптеген жіптер қажет болады. Бұл тәсіл Erlang бағдарламалау тілінің жұмыс уақытында да қолданылады. Erlang виртуалды машинасы миллионға дейін Erlang процесінен I/O-ны өңдеу үшін аз ғана жіптер немесе кейде бір ғана процесс кішкентай тобын пайдаланып, асинхронды I/O-ны қолданады. Әрбір процесте I/O-мен жұмыс істеу көбінесе блоктау синхронды I/O арқылы жазылады. Осылайша асинхронды I/O-ның жоғары өнімділігі мен қалыпты I/O-ның қарапайымдылығы біріктіріледі (мысалы, Actor моделі). Erlang-тағы көптеген I/O мәселелері хабар алмасуға бейімделеді, оны енгізілген таңдамалы қабылдау арқылы оңай өңдеуге болады. Fibers / Coroutines Erlang процестерімен салыстырылатын кепілдіктер бермесе де, Erlang жұмыс уақытынан тыс асинхронды I/O-ны жүзеге асырудың ұқсас жеңіл тәсілі ретінде қарастырылуы мүмкін.

Толықтыру кезектері/порттар

Microsoft Windows, Solaris, AmigaOS, DNIX және Linux-та қолжетімді (io uring пайдаланылады, 5.1 және одан жоғары нұсқаларында қолжетімді). I/O сұраулары асинхронды түрде жіберіледі, бірақ олардың аяқталу ретімен синхронды кезек механизмі арқылы аяқталғаны туралы хабарламалар беріледі. Әдетте, негізгі процестің (оқиға басқарылатын бағдарламалау) күй машинасы құрылымымен байланысты, бұл асинхронды I/O қолданбайтын немесе басқа формаларды пайдаланатын процестен өте өзгеше болуы мүмкін, соның салдарынан кодты қайта пайдалану қиынға түседі. Қосымша арнайы синхрондау механизмдері немесе жиекке қауіпсіз кітапханалар қажет емес, сондай-ақ код және оқиға ағындары да бөлек емес.

Іс-шара жалаушалары

VMS және AmigaOS жүйелерінде қолжетімді (көбінесе аяқталу портымен бірге пайдаланылады). Бұл толтыру кезегі әдісінің көптеген ерекшеліктерін мұралайды, себебі ол негізінен бір тереңдігі бар толтыру кезегі болып табылады. Кезек "тереңдігі" әсерін имитациялау үшін әрбір өңделмеген (бірақ аяқталған) оқиғаға қосымша оқиға белгісі қажет, әйтпесе оқиға туралы мәліметтер жоғалуы мүмкін. Мұндай жиынтықтағы келесі қолжетімді оқиғаны күту үшін, үлкен мөлшердегі параллель оқиғаларға жақсы масштабтала бермейтін синхронизация механизмдері қажет.

I/O арнасы

IBM, Groupe Bull және Unisys компанияларының негізгі компьютерлерінде қолжетімді. I/O арнасы CPU-дың пайдалануын және өнімділігін арттыру үшін, көп бөлігін қосымша процессорға (coprocessor) жүктеу арқылы жасалған. Қосымша процессорда тікелей жадқа қол жеткізу (DMA) мүмкіндігі бар, ол құрылғыдан келетін сигналдарды өңдейді, негізгі процессормен басқарылады және тек қана қажет болған жағдайда ғана негізгі процессорды тоқтатады. Бұл архитектура сонымен қатар I/O операциялары мен протоколдары үшін ауыр жүк көтеруге арналған арна бағдарламаларын қолдайды, олар арна процессорында жұмыс істейді.

Тіркелген I/O

Windows Server 2012 және Windows 8 нұсқаларында қолжетімді. Үлкен көлемде шағын хабарламаларды өңдейтін қосымшалар үшін оңтайландырылған, бұл джиттер мен жауап уақытын азайту арқылы секундына I/O операцияларының санын арттыруға мүмкіндік береді.

Іске асыру

Жалпы мақсаттағы есептеу аппараттарының басым көпшілігі асинхронды I/O-ны жүзеге асырудың екі әдісіне толықтай сүйенеді: сауалнама және үзілістер. Әдетте екі әдіс те бірге қолданылады, арақатынасы аппараттық құрылғының дизайнына және оның қажетті өнімділік сипаттамаларына күрт тәуелді. (DMA өзі жеке тәуелсіз әдіс емес, ол бір сауалнама немесе үзіліс арқылы көбірек жұмыс атқару құралы ғана.) Таза сауалнама жүйелері мүмкін, кішкентай микроконтроллерлер (мысалы, PIC негізіндегі жүйелер) көбінесе осылай жасалады. CP/M жүйелері де осылай құрылуы мүмкін (бірақ көбінесе солай болмайды), DMA болсын, болмасын. Сондай-ақ, егер басқа тапсырмалардың барлығынан бас тартып, тек бірнеше тапсырма үшін максималды өнімділік қажет болса, сауалнама да орынды болуы мүмкін, себебі үзілістерді қабылдаудың қосымша шығындары ыңғайсыз болуы мүмкін. (Үзіліске жауап беру үшін процессор күйінің кем дегенде бір бөлігін сақтауға уақыт [және жад] керек, сондай-ақ үзіліске ұшыраған тапсырманы қайта бастауға уақыт кетеді.) Көптеген жалпы мақсаттағы есептеу жүйелері үзілістерге көп сүйенеді. Таза үзіліс жүйесі де мүмкін, бірақ көбінесе сауалнаманың да бір бөлігі қажет, өйткені үзілістердің бірнеше мүмкін көздері бір үзіліс желісін бөлісуі жиі кездеседі, мұндай жағдайда құрылғы драйвері нақты көзді анықтау үшін сауалнаманы пайдаланады. (Бұл анықтау уақыты үзіліс жүйесінің өнімділігін төмендетуге әсер етеді. Ыңғайлылық үшін үзіліске жауап беруге байланысты шығындарды азайту үшін жылдар бойы көп жұмыс істелді. Қазіргі үзіліс жүйелері кейбір жақсырақ бұрынғы жүйелермен салыстырғанда өте жай, бірақ аппараттық өнімділіктің жалпы өсуі бұл мәселені жеңілдетті.) Гибридтік тәсілдер де мүмкін, онда үзіліс асинхронды I/O-ның бірнеше блогын бастай алады, ал блоктердің ішінде сауалнама қолданылады. Бұл әдіс жоғары жылдамдықты құрылғы драйверлерінде, мысалы, желілік немесе дискілік драйверлерде жиі қолданылады, онда үзіліске дейінгі тапсырмаға оралуға кеткен уақыт келесі қызмет көрсетуге қажетті уақыттан артық. (Қазіргі I/O жабдықтары салыстырмалы түрде нашар өнімді үзіліс жүйесін толықтыру үшін DMA және үлкен дерек буферлерін кеңінен пайдаланады. Бұл жүйелер драйвер циклдерінің ішінде сауалнаманы қолданады және үлкен өнімділікті көрсете алады. Идеалды жағдайда, әр дерек бойынша сауалнамалар әрқашан сәтті аяқталады немесе ең көп дегенде бірнеше рет қайталанады.) Бір кезде бұл гибридтік тәсіл дискілік және желілік драйверлерде кең таралған, онда DMA немесе маңызды буферлеу болмаған. Қажетті деректерді беру жылдамдығы тіпті ең төменгі төрт операциялық циклдан (бит тесті, өзіне шартты өту, алу және сақтау) жылдам болғандықтан, аппараттық жабдық көбінесе I/O құрылғысында автоматты күту күйін жасаумен жасалған, деректер дайын сауалнамасын бағдарламалық жасақтамадан процессордың алу немесе сақтау аппараттарына көшіріп, бағдарламалық циклды екі операцияға дейін қысқартқан. (Дәлі, процессорды DMA машинасы ретінде пайдалану.) 6502 процессоры дерек бойынша үш операциялық циклді қамтамасыз етудің ерекше мүмкіндігін ұсынды, өйткені оның аппараттық тірегі болған, ол белсенді болғанда процессордың Overflow битін тікелей орнатуға мүмкіндік берді. (Әрине, құрылғы драйверінің сыртында 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!)

Синтез

Тек осы екі құралды (сауалнама және үзілістер) пайдаланып, жоғарыда талқыланған асинхронды I/O-ның барлық басқа түрлері синтезделуі мүмкін (және шындығында да синтезделеді). Java виртуалды машинасы (JVM) сияқты ортада асинхронды I/O синтезделуі мүмкін, тіпті JVM жұмыс істейтін орта оны мүлдем ұсынбауы мүмкін. Бұл JVM-нің интерпретациялық табиғатына байланысты. JVM бақылау ағынын ішкі түрде өзгерту үшін мерзімді түрде сауалнама жасауға (немесе үзіліс күтуге) болады, соның салдарынан бірнеше бір уақытта іске қосылған процестер пайда болады, олардың кем дегенде бірі асинхронды I/O-ны орындау үшін қажет. (Әрине, микроскопиялық деңгейде параллелизм өте жоғары болуы мүмкін және кейбір идеалды емес қасиеттерін көрсетуі мүмкін, бірақ сырттай көрінісі қалағандай болады.) Шындығында, асинхронды I/O-ның басқа түрін синтездеу үшін сауалнаманы кез келген түрінде пайдаланудың мәселесі осында. Сауалнама болып табылатын әрбір CPU циклы босқа кетеді, қажетті міндетті орындаудың орнына қосымша шығындарға жұмсалады. Сауалнама емес әрбір CPU циклы күтіп тұрған I/O-ға жауап беру уақытының ұзаруын білдіреді. Осы екі қарама-қарсы күштің арасында қанағаттанарлық тепе-теңдік табу қиын. (Дәл осы себепті аппараттық үзіліс жүйелері ойлап табылды.) Тиімділікті арттырудың кілті – тиісті қолданбаны ояту үшін үзіліс қабылданған кезде жасалатын жұмыстың мөлшерін азайту. Екінші жағынан (бірақ кем емес маңыздысы) – қолданбаның өзіне не істеу керектігін анықтау үшін қолданатын әдіс. Әсіресе (қолданба тиімділігі үшін) проблемалық болып табылады ашық сауалнама әдістері, соның ішінде таңдау/сауалнама механизмдері. Олардың қызығушылығын тудыратын I/O оқиғалары үзіліс арқылы туындаса да, осы механизмбен өзара әрекеттесу сауалнама арқылы жүзеге асырылады және сауалнама кезінде көп уақыт жұмсалуы мүмкін. Бұл әсіресе таңдау (және сауалнама) арқылы мүмкін болатын кең ауқымды сауалнамаға қатысты. Үзілістер Сигналдарға, Кері шақыру функцияларына, Аяқталу кезектеріне және Оқиға туларына өте жақсы сәйкес келеді, мұндай жүйелер өте тиімді болуы мүмкін.

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.