Марк Митчелл - Программирование для Linux. Профессиональный подход

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

Тем не менее подобная особенность реализации библиотеки Pthreads в Linux не согласуется со стандартом POSIX. Нельзя полагаться на нее в программах, рассчитанных на то, чтобы быть переносимыми.

В многопотоковой программе один поток может послать сигнал другому. Для этого предназначена функция pthread_kill(). Ее первым параметром является идентификатор потока, а второй параметр — это номер сигнала.

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

В Linux имеется функция clone(), являющаяся обобщением функций fork()и pthread_create(). Она позволяет вызывающему процессу указывать, какие ресурсы он согласен делить с дочерним процессом. Необходимо также задать область памяти, в которой будет расположен стек выполнения нового процесса. Вообще говоря, мы упоминаем функцию clone()лишь для того, чтобы удовлетворить любопытство читателей. Использовать ее в программах не следует. Создавайте процессы с помощью функции fork(), а потоки — с помощью функции pthread_create().

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

■ Все потоки программы должны выполнять один и тот же код. В то же время дочерний процесс может запустить другой исполняемый файл с помощью функции exec().

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

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

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

■ Совместное использование данных несколькими потоками — тривиальная задача, ведь потоки имеют общий доступ к ресурсам (необходимо, правда, внимательно следить за тем, чтобы не возникало состояние гонки). В случае процессов требуется задействовать особый механизм взаимодействия, описанный в главе 5, "Взаимодействие процессов". Это делает программы более громоздкими, зато уменьшает вероятность ошибок, связанных с параллельной работой.

В главе 3, "Процессы", описывалась процедура создания процесса и рассказывалось о том, как родительский процесс может получить код завершения дочернего процесса. Это простейшая форма взаимодействия двух процессов, но не самая эффективная. Рассмотренные в главе 3 механизмы позволяли процессу-предку общаться с процессом-потомком только посредством аргументов командной строки и переменных среды, а все, что мог сделать для предка потомок, — вернуть свой код завершения. Такие механизмы не позволяют контролировать выполняющийся процесс или обращаться к внешнему, независимому процессу.