UNIX: разработка сетевых приложений

Стивенс Уильям Ричард

22 }

23 }

24 static void*

25 doit(void *arg)

26 {

27 int connfd;

28 connfd = *((int*)arg);

29 free(arg);

30 Pthread_detach(pthread_self);

31 str_echo(connfd); /* та же функция, что и раньше */

32 Close(connfd); /* мы закончили с присоединенным сокетом */

33 return (NULL);

34 }

17-22

Каждый раз перед вызовом функции

accept

мы вызываем функцию

malloc

и выделяем в памяти пространство для целочисленной переменной (дескриптора присоединенного сокета). Таким образом каждый поток получает свою собственную копию этого дескриптора.

28-29

Поток получает значение дескриптора присоединенного сокета, а затем освобождает занимаемую им память с помощью функции

free

.

Исторически функции

malloc

и

free

не допускали повторного вхождения. Это означает, что при вызове той или иной функции из обработчика сигнала в то время, когда главный поток выполняет одну из них, возникает большая путаница, так как эти функции оперируют статическими структурами данных. Как же мы можем вызывать эти две функции в листинге 26.3? Дело в том, что в POSIX требуется, чтобы эти две функции, так же как и многие другие, были безопасными в многопоточной среде( thread-safe). Обычно это достигается с помощью некоторой разновидности синхронизации, осуществляемой внутри библиотечных функций и являющейся для нас прозрачной (то есть незаметной).

Функции, безопасные в многопоточной среде

Стандарт POSIX.1 требует, чтобы все определенные в нем функции, а также функции, определенные в стандарте ANSI С, были безопасными в многопоточной среде. Исключения из этого правила приведены в табл. 26.1.

К сожалению, в POSIX.1 ничего не сказано о безопасности в многопоточной среде по отношению к функциям сетевого API. Последние пять строк в этой таблице появились благодаря Unix 98. В разделе 11.18 мы говорили о том, что функции

gethostbyname

и

gethostbyaddr

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

_r

), но поскольку они не стандартизованы, лучше от них отказаться. Все функции

getXXX

, не допускающие повторного вхождения, были приведены в табл. 11.5.

Таблица 26.1. Функции, безопасные в многопоточной среде

Могут не быть безопасными в многопоточной среде	Должны быть безопасными в многопоточной среде	Комментарии
Asctime	asctime_r	Безопасна в многопоточной среде только в случае непустого аргумента
	ctermid
Ctime	ctime_r
getc_unlocked
getchar_unlocked
Getgrid	getgrid_r
Getgrnam	getgrnam_r
Getlogin	getlogin_r
Getpwnam	getpwnam_r
Getpwuid	getpwuid_r
Gmtime	gmtime_r
Localtime	localtime_r
putc_unlocked
putchar_unlocked
Rand	rand_r
Readdir	readdir_r
Strtock	strtock_r
	tmpnam	Безопасна в многопоточной среде только в случае непустого аргумента
Ttyname	ttyname_r
GethostXXX
GetnetXXX
GetprotoXXX
GetservXXX
inet_ntoa

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

_r

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

26.5. Собственные данные потоков

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

1. Использование собственных данных потоков (thread-specific data). Это нетривиальная задача, и функция при этом преобразуется к такому виду, что может использоваться только в системах, поддерживающих потоки. Преимущество этого подхода заключается в том, что не меняется вызывающая последовательность, и все изменения связаны с библиотечной функцией, а не с приложениями, которые вызывают эту функцию. Позже в этом разделе мы покажем безопасную в многопоточной среде версию функции

readline

, созданную с применением собственных данных потоков.

2. Изменение вызывающей последовательности таким образом, чтобы вызывающий процесс упаковывал все аргументы в некую структуру, а также записывал в нее статические переменные из листинга 3.12. Это также было сделано, и в листинге 26.4 показана новая структура и новые прототипы функций.

Листинг 26.4. Структура данных и прототип функции для версии функции readline, допускающей повторное вхождение

typedef struct {

int read_fd; /* дескриптор, указывающий, откуда считываются данные */