Мультиплексирование ввода/вывода и асинхронный ввод/вывод

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

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

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

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

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

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

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

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

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

В Solaris 10 функции асинхронного ввода/вывода включены в библиотеку libaio.so. Для сборки программ, использующих эти функции, необходимо использовать ключ -laio. Для формирования запросов на асинхронный ввод/вывод используются функции aio_read(3AIO), aio_write(3AIO) и lio_listio(3AIO).

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

• int aio_fildes - дескриптор файла
• off_t aio_offset - смещение в файле, начиная с которого будет идти запись или чтение
• volatile void* aio_buf - буфер, в который следует прочитать данные или в котором лежат данные для записи.
• size_t aio_nbytes - размер буфера. Как и традиционный read(2), aio_read(3AIO) может прочитать меньше данных, чем было запрошено, но никогда непрочитает больше.
• int aio_reqprio - приоритет запроса
• struct sigevent aio_sigevent - способ оповещения о завершении запроса (рассматривается далее в этом разделе)
• int aio_lio_opcode - при aio_read(3AIO) и aio_write(3AIO) не используется, используется только функцией lio_listio.

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

• int mode - может принимать значения LIO_WAIT (функция ждет завершения всех запросов) и LIO_NOWAIT (функция возвращает управление сразу после формирования всех запросов).
• struct aiocb *list[] - список указателей на структуры aiocb с описаниями запросов.

  Запросы могут быть как на чтение, так и на запись, это определяется полем aio_lio_opcode. Запросы к одному дескриптору исполняются в том порядке, в каком они указаны в массиве list.
• int nent - количество записей в массиве list.
• struct sigevent *sig - способ оповещения о завершении всех запросов. Если mode==LIO_WAIT, этот параметр игнорируется.

Библиотека POSIX AIO предусматривает два способа оповещения программы о завершении запроса, синхронный и асинхронный. Сначала рассмотрим синхронный способ. Функция 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) блокирует нить до завершения одного из указанных ей запросов асинхронного ввода/вывода либо на указанный интервал времени. Эта функция имеет три параметра:

• const struct aiocb *const list[] - массив указателей на описатели запросов.
• int nent - количество элементов в массиве list.
• const struct timespec *timeout - тайм-аут с точностью до наносекунд (в действительности, с точностью до разрешения системного таймера).

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

Пример использования асинхронного ввода/вывода с синхронной проверкой статуса запроса приводится в примере 8.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> и содержит следующие поля:

• int sigev_notify - режим нотификации. Допустимые значения - SIGEV_NONE (не посылать подтверждения), SIGEV_SIGNAL (генерировать сигнал при завершении запроса) и SIGEV_THREAD (при завершении запроса запускать указанную функцию в отдельной нити). Solaris 10 также поддерживает тип оповещения SIGEV_PORT, который рассматривается в приложении к этой лекции.
• int sigev_signo - номер сигнала, который будет сгенерирован при использовании SIGEV_SIGNAL.
• union sigval sigev_value - параметр, который будет передан обработчику сигнала или функции обработки. При использовании для асинхронного ввода/вывода это обычно указатель на запрос.

  При использовании SIGEV_PORT это должен быть указательна структуру port_event_t, содержащую номер порта и, возможно, дополнительные данные.
• void (*sigev_notify_function)(union sigval) - функция, которая будет вызвана при использовании SIGEV_THREAD.
• pthread_attr_t *sigev_notify_attributes - атрибуты нити, в которой будет запущена
• sigev_notify_function при использовании SIGEV_THREAD.

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

В качестве номера сигнала некоторые приложения используют SIGIO или SIGPOLL (в Unix SVR4 это один и тот же сигнал). Часто используют также SIGUSR1 или SIGUSR2 ; это удобно потому, что гарантирует, что аналогичный сигнал не возникнет по другой причине.

В приложениях реального времени используются также номера сигналов в диапазоне от SIGRTMIN до SIGRTMAX. Некоторые реализации выделяют для этой цели специальный номер сигнала SIGAIO или SIGASYNCIO, но в Solaris 10 такого сигнала нет.

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

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