Асинхронный ввод/вывод

Еще одна альтернатива многопоточности для приложений, ориентированных на ввод/вывод – это асинхронный ввод/вывод.

Традиционно, Unixиспользует синхронную модель ввода/вывода. Системные вызовыread(2),write(2) и их аналоги возвращают управление только того, как данные уже прочитаны или записаны. Часто это приводит к блокировке нити.

Примечание

В действительности, не все так просто. read(2) действительно должен ожидать физического прочтения данных с устройства, ноwrite(2) по умолчанию работает в режиме отложенной записи: он возвращает управление после того, как данные переданы в системный буфер, но, вообще говоря, до того, как данные будут физически переданы устройству. Это, как правило, значительно повышает наблюдаемую производительность программы и позволяет использовать память из-под данных для других целей сразу после возвратаwrite(2). Но отложенная запись имеет и существенные недостатки. Главный из них – вы узнаете о результате физической операции не сразу по коду возвратаwrite(2), а лишь через некоторое время после возврата, обычно по коду возврата следующего вызоваwrite(2). Для некоторых приложений – для мониторов транзакций, для многих программ реального времени и др. – это неприемлемо и они вынуждены выключать отложенную запись. Это делается флагомO_SYNC, который может устанавливаться при открытии файла и изменяться у открытого файла вызовомfcntl(2). Синхронизация отдельных операций записи может быть обеспечена вызовомfsync(2).

Для многих приложений, работающих с несколькими устройствами и/или сетевыми соединениями синхронная модель неудобна. Работа в режиме опроса тоже не всегда приемлема. Дело в том, что select(3С) иpoll(2) считают дескриптор файла готовым для чтения только после того, как в его буфере физически появятся данные. Но некоторые устройства начинают отдавать данные только после того, как их об этом явно попросят.

Также, для некоторых приложений, особенно для приложений реального времени важно знать точный момент начала поступления данных. Для таких приложений также может быть неприемлемо то, что select(3C) иpoll(2) считают регулярные файлы всегда готовыми для чтения и записи. Действительно, файловая система читается с диска и хотя она работает гораздо быстрее, чем большинство сетевых соединений, но все-таки обращения к ней сопряжены с некоторыми задержками. Для приложений жесткого реального времени эти задержки могут быть неприемлемы – но без явного запроса на чтение файловая система данные не отдает!

С точки зрения приложений жесткого реального времени может оказаться существенным еще один аспект проблемы ввода/вывода. Дело в том, что приложения жесткого РВ имеют более высокий приоритет, чем ядро, поэтому исполнение ими системных вызовов – даже неблокирующихся! – может привести к инверсии приоритета.

Решение этих проблем известно давно и называется асинхронный ввод/вывод. В этом режиме системные вызовы ввода/вывода возвращают управление сразу после формирования запроса к драйверу устройства, как правило, даже до того, как данные будут скопированы в системный буфер. Формирование запроса состоит в установке записи (IRP,Input/OutputRequestPacket, пакет запроса ввода вывода) в очередь. Для этого надо лишь ненадолго захватить мутекс, защищающий «хвост» очереди, поэтому проблема инверсии приоритета легко преодолима. Для того, чтобы выяснить, закончился ли вызов, и если закончился, то чем именно, и можно ли использовать память, в которой хранились данные, предоставляется специальныйAPI(см. рис. 1)

Рис. 1. Асинхронная модель ввода/вывода

Асинхронная модель была основной моделью ввода/вывода в таких ОС, как DECRT-11,DECRSX-11,VAX/VMS,OpenVMS. Эту модель в той или иной форме поддерживают практически все ОС реального времени. В системах семействаUnixс конца 1980х использовалось несколько несовместимыхAPIдля асинхронного ввода/вывода. В 1993 годуANSI/IEEEбыл принят документPOSIX1003.1b, описывающий стандартизованныйAPI, который мы и изучим далее в этом разделе.

В Solaris10 функции асинхронного ввода/вывода включены в библиотекуlibaio.so. Для сборки программ, использующих эти функции, необходимо использовать ключ –laio.

Для формирования запросов на асинхронный ввод/вывод используются функции aio_read(3AIO),aio_write(3AIO) иlio_listio(3AIO).

Функции aio_read(3AIO) иaio_write(3AIO) имеют единственный параметр,structaiocb*aiocbp. Структураaiocbопределена в файле <aio.h> и содержит следующие поля:

intaio_fildes– дескриптор файла

off_taio_offset– смещение в файле, начиная с которого будет идти запись или чтение

volatilevoid*aio_buf– буфер, в который следует прочитать данные или в котором лежат данные для записи.

size_taio_nbytes– размер буфера. Как и традиционныйread(2),aio_read(3AIO) может прочитать меньше данных, чем было запрошено, но никогда не прочитает больше.

intaio_reqprio– приоритет запроса

structsigeventaio_sigevent– способ оповещения о завершении запроса (рассматривается далее в этом разделе)

intaio_lio_opcode– приaio_read(3AIO) иaio_write(3AIO) не используется, используется только функциейlio_listio.

Функция lio_listio(3AIO) позволяет одним системным вызовом сформировать несколько запросов на ввод/вывод. Эта функция имеет четыре параметра:

intmode– может принимать значенияLIO_WAIT(функция ждет завершения всех запросов) иLIO_NOWAIT(функция возвращает управление сразу после формирования всех запросов).

structaiocb*list[] – список указателей на структурыaiocbс описаниями запросов. Запросы могут быть как на чтение, так и на запись, это определяется полемaio_lio_opcode. Запросы к одному дескриптору исполняются в том порядке, в каком они указаны в массивеlist.

intnent– количество записей в массивеlist.

structsigevent*sig– способ оповещения о завершении всех запросов. Еслиmode==LIO_WAIT, этот параметр игнорируется.

Библиотека POSIXAIOпредусматривает два способа оповещения программы о завершении запроса, синхронный и асинхронный. Сначала рассмотрим синхронный способ.

Функция aio_return(3AIO) возвращает статус запроса. Если запрос уже завершился и завершился успешно, она возвращает размер прочитанных или записанных данных в байтах. Как и у традиционногоread(2), в случае конца файлаaio_return(3AIO) возвращает 0 байт. Если запрос завершился ошибкой или еще не завершился, возвращается -1 и устанавливаетсяerrno. Если запрос еще не завершился, код ошибки равенEINPROGRESS. Функцияaio_return(3AIO) разрушающая; если ее вызвать для завершенного запроса, то она уничтожит системный объект, хранящий информацию о статусе запроса. Многократный вызовaio_return(3AIO) по поводу одного и того же запроса, таким образом, невозможен.

Функция aio_error(3AIO) возвращает код ошибки, связанной с запросом. При успешном завершении запроса возвращается 0, при ошибке – код ошибки, для незавершенных запросов –EINPROGRESS.

Функция aio_suspend(3AIO) блокирует нить до завершения одного из указанных ей запросов асинхронного ввода/вывода либо на указанный интервал времени. Эта функция имеет три параметра:

conststructaiocb*constlist[] – массив указателей на описатели запросов.

intnent– количество элементов в массивеlist.

conststructtimespec*timeout– тайм-аут с точностью до наносекунд (в действительности, с точностью до разрешения системного таймера).

Функция возвращает 0, если хотя бы одна из операций, перечисленных в списке, завершилась. Если функция завершилась с ошибкой, она возвращает -1 и устанавливает errno. Если функция завершилась по тайм-ауту, она также возвращает -1 иerrno==EINPROGRESS.

Пример использования асинхронного ввода/вывода с синхронной проверкой статуса запроса приводится в примере 3.

Пример 3 Асинхронный ввод/вывод с синхронной проверкой статуса запроса. Код сокращен, из него исключены открытие сокета и обработка ошибок.

const char req[]="GET / HTTP/1.0\r\n\r\n";

int main() {

int s;

static struct aiocb readrq;

static const struct aiocb *readrqv[2]={&readrq, NULL};

/* Открыть сокет […] */

memset(&readrq, 0, sizeof readrq);

readrq.aio_fildes=s;

readrq.aio_buf=buf;

readrq.aio_nbytes=sizeof buf;

if (aio_read(&readrq)) {

/* … */

}

write(s, req, (sizeof req)-1);

while(1) {

aio_suspend(readrqv, 1, NULL);

size=aio_return(&readrq);

if (size>0) {

write(1, buf, size);

aio_read(&readrq);

} else if (size==0) {

break;

} else if (errno!=EINPROGRESS) {

perror("reading from socket");

}

}

}

Асинхронное оповещение приложения о завершении операций состоит в генерации сигнала при завершении операции. Чтобы это сделать, необходимо внести соответствующие настройки в поле aio_sigeventописателя запроса.

Поле aio_sigevent имеет тип struct sigevent. Эта структура определена в <signal.h> и содержит следующие поля:

intsigev_notify– режим нотификации. Допустимые значения –SIGEV_NONE(не посылать подтверждения),SIGEV_SIGNAL(генерировать сигнал при завершении запроса) иSIGEV_THREAD(при завершении запроса запускать указанную функцию в отдельной нити).Solaris10 также поддерживает тип оповещенияSIGEV_PORT, который рассматривается в приложении к этой лекции.

intsigev_signo– номер сигнала, который будет сгенерирован при использованииSIGEV_SIGNAL.

unionsigvalsigev_value– параметр, который будет передан обработчику сигнала или функции обработки. При использовании для асинхронного ввода/вывода это обычно указатель на запрос. При использованииSIGEV_PORTэто должен быть указатель на структуруport_event_t, содержащую номер порта и, возможно, дополнительные данные.

void(*sigev_notify_function)(unionsigval) – функция, которая будет вызвана при использованииSIGEV_THREAD.

pthread_attr_t*sigev_notify_attributes– атрибуты нити, в которой будет запущенаsigev_notify_functionпри использованииSIGEV_THREAD.

Далеко не все реализации libaioподдерживают оповещениеSIGEV_THREAD. НекоторыеUnix-системы используют вместо него нестандартное оповещениеSIGEV_CALLBACK. Далее в этой лекции мы будем обсуждать только оповещение сигналом.

В качестве номера сигнала некоторые приложения используют SIGIOилиSIGPOLL(вUnixSVR4 это один и тот же сигнал). Часто используют такжеSIGUSR1 илиSIGUSR2; это удобно потому, что гарантирует, что аналогичный сигнал не возникнет по другой причине. В приложениях реального времени используются также номера сигналов в диапазоне отSIGRTMINдоSIGRTMAX. Некоторые реализации выделяют для этой цели специальный номер сигналаSIGAIOилиSIGASYNCIO, но вSolaris10 такого сигнала нет.

Разумеется, перед тем, как исполнять асинхронные запросы с оповещением сигналом, следует установить обработчик этого сигнала. Для оповещения необходимо использовать сигналы, обрабатываемые в режиме SA_SIGINFO. Установить такой обработчик при помощи системных вызововsignal(2) иsigset(2) невозможно, необходимо использоватьsigaction(2). Установка обработчиков при помощиsigactionрассматривается в приложении 2 к этой лекции.

Обработка сигнала в режиме SA_SIGINFOимеет два свойства, каждое из которых полезно для наших целей. Во первых, обработчики таких сигналов имеют три параметра, в отличие от единственного параметра у традиционных обработчиков. Первый параметр имеет типintи соответствует номеру сигнала, второй параметр имеет типsiginfo_t*, генерируется системой и содержит ряд интересных полей. Нас в данном случае больше всего интересует поле этой структурыsi_value. Как раз в этом поле нам передается значениеaio_sigevent.sigev_value, которое мы создали при настройке структурыaiocb.