Мотивация для порождения нового процесса в потоке

Question

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

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

Процессы дают вам большебезопасность с точки зрения того, что один процесс не может «связываться» с содержимым других процессов, в то время как если один поток аварийно завершает работу, вероятно, все потоки завершатся с ошибкой в ​​указанном процессе.Вы хотите использовать процесс (например, с помощью fork () в C)?

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

В частности, когда имеет смысл, когда одна программа порождает новый процесс против потока?

Answer 1

Основная причина использования процессов заключается в том, что процесс может завершиться сбоем или сойти с ума, а ОС ограничит влияние, которое это оказывает на другие процессы. Так, например, Firefox недавно начал запускать плагины в отдельных процессах, IIRC Chrome запускает разные страницы в разных процессах, а веб-серверы долгое время обрабатывали отдельные запросы в отдельных процессах.

Существует несколько различных способов применения ограничений ОС:

• Сбои - как вы заметили, если поток падает, он обычно останавливает весь процесс. Это мотивирует границы процессов браузера: браузеры и плагины браузера представляют собой сложные фрагменты кода, подверженные постоянной атаке, поэтому имеет смысл принять необычные меры предосторожности.
• Лимиты ресурсов. Если поток в вашем процессе открывает много файлов, выделяет много памяти и т. Д., То это влияет на вас. Другой процесс не нужен, потому что он может быть ограничен отдельно. Таким образом, каждый запрос на веб-сервере может быть более ограниченным в использовании ресурсов, чем сервер в целом, потому что вы хотите, чтобы ваш сервер обслуживал несколько запросов одновременно без какого-либо одного удаленного пользователя, занимающего ресурсы.
• Возможности. Зависит от ОС, но, например, вы можете запустить процесс в изолированной тюрьме, чтобы убедиться, что он не изменяет и не читает файлы, которые не должны, независимо от того, насколько уязвим ваш код для эксплойтов. В другом примере SymbianOS имеет явный список разрешений для различных действий с системой («чтение телефонной книги пользователя», «запись телефонной книги пользователя», «расшифровка файлов DRM» и т. Д.). Нет способа отменить разрешения, которые есть у вашего процесса, поэтому, если вы хотите сделать что-то очень чувствительное, а затем вернуться к режиму с низкой чувствительностью, вам понадобится где-нибудь граница процесса. Одной из причин этого является безопасность - неизвестный код или код, который может содержать недостатки безопасности, может быть несколько помещен в «песочницу», а меньшее количество кода, которое не ограничено, может быть подвергнуто более тщательному анализу. Другая причина заключается в том, что операционная система обеспечивает выполнение определенных аспектов вашего проекта.
• Драйверы. В общем случае драйвер устройства управляет общим доступом к уникальному системному ресурсу. Как и в случае с возможностями, ограничение этого доступа одним процессом драйвера означает, что вы можете запретить его всем остальным процессам. Например, IIRC TrueCrypt в Windows устанавливает драйвер с расширенными разрешениями, которые позволяют ему регистрировать зашифрованный контейнер с буквой диска, а затем действовать как любая другая файловая система Windows. Графическая часть приложения работает в обычном пользовательском режиме. Я не уверен, что драйверы файловой системы в Windows действительно нуждаются в связанном процессе, но драйверы устройств в целом могут подойти, поэтому, даже если это не хороший пример, надеюсь, это даст идею.

Еще одна потенциальная причина использования процессов заключается в том, что это упрощает анализ вашего кода. В многопоточном коде вы полагаетесь на инварианты всех ваших классов, чтобы сделать вывод, что доступ к определенному объекту сериализован: если ваш код не многопоточный, то вы знаете, , что это [*]. Конечно, это можно сделать и с многопоточным кодом, просто убедитесь, что вы знаете, какой поток «владеет» каждым объектом, и никогда не обращаетесь к объекту из потока, который не является его владельцем. Границы процесса усиливают это, а не просто проектируют для этого. Опять же, не уверен, что это мотивация, но, например, клиент World Community Grid может использовать несколько ядер. В этом режиме он запускает несколько процессов с совершенно разными задачами в каждом, поэтому он имеет преимущества в производительности дополнительных ядер без необходимости параллелизации какой-либо отдельной задачи или кода для любой задачи, которая должна быть поточно-ориентированной.

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

Answer 2

Я бы сказал, что у потоков ограниченный стек, что дает вам ограничение на объем работы, которую вы можете выполнять с ними.Бот OTH позволяет очень просто обмениваться данными, используя общую память и потоки сообщений.Имея 10 потоков, каждый из которых выполняет простую задачу, довольно легко управлять даже на базовом компьютере.

Управлять процессами, на мой взгляд, сложнее, потому что вам приходится иметь дело спередача данных между родителем и ребенком.Вы должны использовать каналы, очереди сообщений и т. Д., И передача памяти обходится намного дороже, чем в потоках.Остановка процесса предполагает отправку SIG_KILL.OTH вы получаете защиту от сбоев: сбой процесса не займет ваше основное приложение.

примеры потоков
- Обработка чтения / записи ввода / вывода: вы передаете буфер,поток уведомляет вас о завершении записи / чтения - умножение матриц: вы можете разбить матричные вычисления по строкам или столбцам, и задача довольно проста

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

tl; dr
ИМХО:
- Использовать процессов , если задача сложная.
- Использовать потоков , если такт невелик.

Answer 3

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

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

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

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