В некоторых ситуациях потоки имеют преимущество перед процессами. Рассмотрим традиционный для UNIX подход к обеспечению конкурентного выполнения за счет создания нескольких процессов. Возьмем для примера модель сетевого сервера, в которой родительский процесс принимает входящие подключения и создает с помощью вызова fork() отдельные дочерние процессы для общения с каждым клиентом (см. раздел 56.3). Это позволяет одновременно обслуживать сразу несколько подключений. Такой подход обычно хорошо себя проявляет, но в некоторых ситуациях он приводит к следующим ограничениям.
Рис. 29.1.
• Обмен информацией между процессами имеет свои сложности. Поскольку родитель и потомок не разделяют память (помимо текстового сегмента, предназначенного сугубо для чтения), мы вынуждены использовать некую форму межпроцессного взаимодействия для обмена данными.
• Создание процесса с помощью fork() потребляет относительно много ресурсов. Даже если использовать метод копирования при записи, описанный в подразделе 24.2.2, нам все равно приходится дублировать различные атрибуты процесса, такие как таблицы со страницами памяти и файловыми дескрипторами; это означает, что вызов fork() по-прежнему занимает существенное время.
Потоки помогают избавиться от обеих этих проблем.
• Обмен информации между потоками является простым и быстрым. Для этого всего лишь нужно скопировать данные в общие переменные (глобальные или в куче). Но чтобы избежать проблем, которые могут возникнуть в ситуации, когда сразу несколько потоков пытаются обновить одну и ту же информацию, приходится применять методы синхронизации, описанные в главе 30.
• Создание потока занимает меньше времени, чем создание процесса — обычно имеем как минимум десятикратный выигрыш в производительности (в Linux потоки реализованы с помощью системного вызова clone(); отличия в скорости между ним и вызовом fork() показаны в табл. 28.3). Процедура создания потока является более быстрой, поскольку многие атрибуты вместо непосредственного копирования, как в случае с fork(), просто разделяются. В частности, отпадает потребность в дублировании страниц памяти (с помощью копирования при записи) и таблиц со страницами.
Помимо глобальной памяти, потоки также разделяют целый ряд других атрибутов (это когда атрибуты являются глобальными для всего процесса, а не для отдельных потоков). Среди них можно выделить атрибуты, перечисленные ниже.
• Идентификаторы процесса и его родителя.
• Идентификаторы группы процессов и сессии.
• Управляющий терминал.
• Учетные данные процесса (идентификаторы пользователя и группы).
• Дескрипторы открытых файлов.
• Блокировки записей, созданные с помощью вызова fcntl().
• Действия сигналов.
• Информация, относящаяся к файловой системе: umask, текущий и корневой каталог.
• Интервальные таймеры (setitimer()) и POSIX-таймеры (timer_create()).
• Значения отмены семафоров (semadj) в System V.
• Ограничения на ресурсы.
• Потребленное процессорное время (полученное из times()).
• Потребленные ресурсы (полученные из getrusage()).
• Значение nice (установленное с помощью setpriority() и nice()).
Ниже перечислены атрибуты, которые являются уникальными для каждого отдельного потока:
• Идентификатор потока (см. раздел 29.5).
• Маска сигнала.
• Данные, относящиеся к определенному потоку (см. раздел 31.3).
• Альтернативный стек сигналов (sigaltstack()).
• Переменная errno.
• Настройки плавающей запятой (см. env(3)).
• Политика и приоритет планирования в режиме реального времени (см. разделы 35.2 и 35.3).
• Привязка к ЦПУ (относится только к Linux, описывается в разделе 35.4).
• Возможности (относится только к Linux, описывается в главе 39).
• Стек (локальные переменные и сведения о компоновке вызовов функций).
Как можно видеть на рис. 29.1, все стеки, относящиеся к отдельным потокам, находятся внутри одного и того же виртуального адресного пространства. Это означает, что потоки, имея подходящие указатели, могут обмениваться данными через стеки друг друга. Это бывает удобно, но требует осторожности при написании кода, чтобы уладить зависимость, вытекающую из того факта, что локальная переменная остается действительной только на время существования стека, в котором она находится (если функция возвращает значение, участок памяти, использовавшийся ее стеком, может быть повторно задействован во время последующего вызова функции; если поток завершается, участок памяти, в котором находился его стек, формально становится доступным другому потоку). Неправильная работа с этой зависимостью может привести к ошибкам, которые будет сложно отследить.
В конце 1980-х и начале 1990-х годов существовало несколько разных программных интерфейсов для работы с потоками. В 1995 году в стандарте POSIX.1 был описан API-интерфейс POSIX-потоков, который позже вошел в состав SUSv3.
