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

Мы ждали его слишком долго

Что может быть глупее, чем ждать?

Б. Гребенщиков

Системный вызов select

Если ваша программа главным образом занимаетсяоперациями ввода/вывода, вы можете получить наиболее важные из преимуществ многопоточности в однопоточной программе, используя системный вызов select(3C). В большинстве Unix-систем select является системным вызовом, или, во всяком случае, описывается в секции системного руководства 2 (системные вызовы), т.е. ссылка на него должна была бы выглядеть как select(2), но в Solaris 10 соответствующая страница системного руководства размещена в секции 3C (стандартная библиотека языка С).

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

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

Если ваша программа работает с несколькими устройствами ввода/вывода и/или сетевыми соединениями, ей невыгодно блокироваться на операции, связанной с одним из этих устройств, ведь в таком состоянии она может пропустить возможность совершить ввод/вывод с другого устройства без блокировки. Эту проблему можно решать при помощи создания нитей, работающих с различными устройствами. В предыдущих лекциях мы изучили все необходимое для разработки таких программ. Однако для решения этой проблемы есть и другие средства.

Системный вызов select(3C) позволяет ожидать готовности нескольких устройств или сетевых соединений (в действительности, готовности объектов большинства типов, которые могут быть идентифицированы файловым дескриптором). Когда один или несколько из дескрипторов оказываются готовы передать данные, select(3C) возвращает управление программе и передает списки готовых дескрипторов в выходных параметрах.

В качестве параметров select(3C) использует множества (наборы) дескрипторов. В старых Unix-системах множества были реализованы в виде 1024-разрядных битовых масок. В современныхUnix-системах и в других ОС, реализующих select, множества реализованы в виде непрозрачного типа fd_set, над которым определены некоторые теоретико-множественные операции, а именно - очистка множества, включение дескриптора в множество, исключение дескриптора из множества и проверка наличия дескриптора в множестве. Препроцессорные директивы для выполнения этих операций описаны на странице руководства select(3C).

В 32-разрядных версиях Unix SVR4, в том числе в Solaris, fd_set по прежнему представляет собой 1024-битовую маску; в 64-разрядных версиях SVR4 это маска разрядности 65536 бит. Размер маски определяет не только максимальное количество файловых дескрипторов в наборе, но и максимальный номер файлового дескриптора в наборе. Размер маски в вашей версии системы можно определить во время компиляции по значению препроцессорного символа FD_SETSIZE. Нумерация файловых дескрипторов в Unix начинается с 0, поэтому максимальный номер дескриптора равен FD_SETSIZE-1.

Таким образом, если вы используете select(3C), вам необходимо установить ограничения на количество дескрипторов вашего процесса. Это может быть сделано шелловской командой ulimit(1) перед запуском процесса или системным вызовом setrlimit(2) уже во время исполнения вашего процесса. Разумеется, setrlimit(2) необходимо вызвать до того, как вы начнете создавать файловые дескрипторы.

Если вам необходимо использовать более 1024 дескрипторов в 32-битной программе, Solaris 10 предоставляет переходный API. Для его использования необходимо определить препроцессорный символ FD_SETSIZE с числовым значением, превышающим 1024, перед включением файла <sys/time.h>. При этом в файле <sys/select.h> сработают необходимые препроцессорные директивы и тип fd_set будет определен как большая битовая маска, а select и другие системные вызовы этого семейства будут переопределены для использования масок такого размера.

В некоторых реализациях fd_set реализован другими средствами, без использования битовых масок. Например, Win32 предоставляет select в составе так называемого Winsock API. В Win32 fd_set реализован как динамический массив, содержащий значения файловых дескрипторов. Поэтому вам не следует полагаться на знание внутренней структуры типа fd_set.

Так или иначе, изменения размера битовой маски fd_set или внутреннего представления этого типа требуют перекомпиляции всех программ, использующих select(3C). В будущем, когда архитектурный лимит в 65536 дескрипторов на процесс будет повышен, может потребоваться новая версия реализации fd_set и select и новая перекомпиляция программ. Чтобы избежать этого и упростить переход на новую версию ABI, компания Sun Microsystems рекомендует отказываться от использования select(3C) и использовать вместо него системный вызов poll(2). Системный вызов poll(2) рассматривается далее на этой лекции.

Системный вызов select(3C) имеет пять параметров.

• int nfds - число, на единицу большее, чем максимальный номер файлового дескриптора во всех множествах, переданных как параметры.
• fd_set *readfds - Входной параметр, множество дескрипторов, которые следует проверять на готовность к чтению. Конец файла или закрытие сокета считается частным случаем готовности к чтению. Регулярные файлы всегда считаются готовыми к чтению. Также, если вы хотите проверить слушающий сокет TCP на готовность к выполнению accept(3SOCKET), его следует включить в это множество. Также, выходной параметр, множество дескрипторов, готовых к чтению.
• fd_set *writefds - Входной параметр, множество дескрипторов, которые следует проверять на готовность к записи. Ошибка при отложенной записи считается частным случаем готовности к записи. Регулярные файлы всегда готовы к записи. Также, если вы хотите проверить завершение операции асинхронного connect(3SOCKET), сокет следует включить в это множество. Также, выходной параметр, множество дескрипторов, готовых к записи.
• fd_set *errorfds - Входной параметр, множество дескрипторов, которые следует проверять на наличие исключительных состояний. Определение исключительного состояния зависит от типа файлового дескриптора. Для сокетов TCP исключительное состояние возникает при приходе внеполосных данных. Регулярные файлы всегда считаются находящимися в исключительном состоянии. Также, выходной параметр, множество дескрипторов, на которых возникли исключительные состояния.
• struct timeval * timeout - тайм-аут, временной интервал, задаваемый с точностью до микросекунд. Если этот параметр равен NULL, то select(3C) будет ожидать неограниченное время; если в структуре задан нулевой интервал времени, select(3C) работает в режиме опроса, то есть возвращает управление немедленно, возможно с пустыми наборами дескрипторов.

Вместо всех параметров типа fd_set * можно передать нулевой указатель. Это означает, что соответствующий класс событий нас не интересует. select(3C) возвращает общее количество готовых дескрипторов во всех множествах при нормальном завершении (в том числе при завершении по тайм-ауту), и -1 при ошибке.

В примере 8.1 приводится использование select(3C) для копирования данных из сетевого соединения на терминал, а с терминала - в сетевое соединение. Эта программа упрощенная, она предполагает, что запись на терминал и в сетевое соединениеникогда не будет заблокирована. Поскольку и терминал, и сетевое соединение имеют внутренние буферы, при небольших потоках данных это обычно так и есть.

Пример 8.1 взят из книги У.Р. Стивенс, Unix: разработка сетевых приложений. Вместо стандартных системных вызовов используются "обертки", описанныев файле " unp.h "

#include "unp.h" 


void str_cli(FILE *fp, int sockfd) { 
    int maxfdp1, stdineof; 
    fd_set rset; 
    char sendline[MAXLINE], recvline[MAXLINE]; 

    stdineof = 0; 
    FD_ZERO(&rset); 
    for ( ; ; ) { 
        if (stdineof == 0) FD_SET(fileno(fp), &rset); 
        FD_SET(sockfd, &rset); 
        maxfdp1 = max(fileno(fp), sockfd) + 1; 
        Select(maxfdp1, &rset, NULL, NULL, NULL); 
        if (FD_ISSET(sockfd, &rset)) { /* socket is readable */ 
    	    if (Readline(sockfd, recvline, MAXLINE) == 0) { 
                if (stdineof == 1) return; /* normal termination */ 
                else err_quit("str_cli: server terminated prematurely"); 
        	} 
        	Fputs(recvline, stdout); 
        } 
        if (FD_ISSET(fileno(fp), &rset)) { /* input is readable */ 
    	    if (Fgets(sendline, MAXLINE, fp) == NULL) { 
                stdineof = 1; 
                Shutdown(sockfd, SHUT_WR); /* send FIN */ 
                FD_CLR(fileno(fp), &rset); 
                continue; 
            } 
            Writen(sockfd, sendline, strlen(sendline)); 
        } 
    } 
}

Обратите внимание, что программа примера 8.1 заново пересоздает множества дескрипторов перед каждым вызовом select(3C). Это необходимо, потому что при нормальном завершении select(3C) модифицирует свои параметры.

select(3C) считается MT-Safe, однако при его использовании в многопоточной программе надо иметь в виду следующий момент. Действительно, сам по себе select(3C) не использует локальных данных и поэтому его вызов из нескольких нитей не должен приводить к проблемам. Однако если несколько нитей работают с пересекающимися наборами файловых дескрипторов, возможен такой сценарий:

1. Нить 1 включает дескриптор s в набор readfds и вызывает select.
2. select в нити 1 возвращает s как готовый для чтения
3. Нить 2 включает дескриптор s в набор readfds и вызывает select
4. select в нити 2 возвращает s как готовый для чтения
5. Нить 1 вызывает read из дескриптора s и получает все данные из его буфера
6. Нить 2 вызывает read из дескриптора s и блокируется.

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

Важно подчеркнуть, что защищать надо не select, а именно последовательность операций над конкретным файловым дескриптором, начиная с включения дескриптора в множество для select и заканчивая приемом данных из этого дескриптора, точнее, обновлением указателей в буфере, в который вы считали эти данные. Если этого не сделать, возможны еще более увлекательные сценарии, например:

1. Нить 1 включает дескриптор s в набор readfds и вызывает select.
2. select в нити 1 возвращает s как готовый для чтения
3. Нить 2 включает дескриптор s в набор readfds и вызывает select
4. select в нити 2 возвращает s как готовый для чтения
5. Нить 1 вызывает read из дескриптора s и получает только часть данных из его буфера
6. Нить 2 вызывает read из дескриптора s, получает данные и записывает их поверх данных, полученных нитью 1

В "Архитектуры многопоточных приложений" мы рассмотрим архитектуру приложения, в котором несколько нитей работают с общим пулом файловых дескрипторов - так называемую архитектуру рабочих нитей (worker threads). При этом нити, разумеется, должны указывать друг другу, с какими именно дескрипторами они сейчас работают.

С точки зрения разработки многопоточных программ, важным недостатком select(3C) - или, возможно, недостатком POSIX Thread API - является тот факт, что примитивы синхронизации POSIX не являются файловыми дескрипторами и не могут использоваться в select(3C). В то же время, при реальной разработке многопоточных программ, занимающихся вводом/выводом, часто было бы полезно ожидать в одной операции готовности файловых дескрипторов и готовности других нитей собственного процесса.