Потоки по сравнению с процессами в Linux

Чтобы еще больше усложнить ситуацию, существует такая вещь, как локальное хранилище потоков и общая память Unix.

Локальное хранилище потоков позволяет каждому потоку иметь отдельный экземпляр глобальных объектов. Я использовал его только при создании среды эмуляции в linux / windows для кода приложения, работающего в ОСРВ. В ОСРВ каждая задача была процессом с собственным адресным пространством, в среде эмуляции каждая задача была потоком (с общим адресным пространством). Используя TLS для таких вещей, как синглеты, мы смогли создать отдельный экземпляр для каждого потока, точно так же, как в «реальной» среде RTOS.

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

Другие обсуждали соображения.

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

Linux использует модель потоков 1-1, в которой (для ядра) нет различий между процессами и потоками - все это просто работоспособная задача. *

В Linux системный вызов clone клонирует задачу с настраиваемым уровнем общего доступа, среди которых:

• CLONE_FILES : использовать одну и ту же таблицу дескрипторов файлов (вместо создания копия)
• CLONE_PARENT : не устанавливать родительско-дочерние отношения между новой задачей и старой (в противном случае, дочерняя getppid () = родительская getpid () )
• CLONE_VM : совместно использовать то же пространство памяти (вместо создания копии COW )

fork () вызывает клон ( наименьшее совместное использование ) и pthread_create () вызывает клон ( большинство разделяющих ) . **

fork стоит чуть больше, чем pthread_create , из-за копирования таблиц и создания отображений COW для памяти, но разработчики ядра Linux постарались (и преуспели) в минимизации этих затрат.

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

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

* Упрощено. CLONE_THREAD вызывает совместное использование доставки сигналов (для этого требуется CLONE_SIGHAND , который разделяет таблицу обработчиков сигналов).

** Упрощено. Существуют как SYS_fork , так и SYS_clone syscalls, но в ядре, sys_fork и sys_clone оба являются очень тонкими оболочками вокруг одного и того же функция do_fork , который сам является тонкой оболочкой вокруг copy_process . Да, термины process , thread и task используются довольно взаимозаменяемо в ядре Linux ...

How about git reset?

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

Рассмотрим программу веб-сервера, которая состоит из двух этапов:

1. Чтение данных конфигурации и времени выполнения
2. Служить запросам страниц

Если вы используете потоки, шаг 1 будет выполнен один раз, а шаг 2 - в нескольких потоках. Если вы использовали «традиционные» процессы, шаги 1 и 2 должны были бы повторяться для каждого процесса, а память для хранения данных конфигурации и времени выполнения дублировалась. Если вы использовали fork (), то вы можете выполнить шаг 1 один раз, а затем fork (),

Я должен согласиться с тем, что вы слышали. Когда мы тестируем наш кластер ( xhpl и т. Д.), Мы всегда получаем значительно лучшую производительность с процессами над потоками.

Если вам нужно совместно использовать ресурсы, вам действительно следует использовать потоки.

Также учтите тот факт, что переключение контекста между потоками намного дешевле, чем переключение контекста между процессами.

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

Это зависит от множества факторов. Процессы более тяжелые, чем потоки, и имеют более высокую стоимость запуска и завершения работы. Межпроцессное взаимодействие (IPC) также сложнее и медленнее, чем межпотоковое взаимодействие.

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

Итак, если модули вашего приложения могут работать в основном независимо при небольшом обмене данными, вам, вероятно, следует использовать процессы, если вы можете позволить себе затраты на запуск и завершение работы. Падение производительности IPC будет минимальным, и вы будете немного безопаснее от ошибок и дыр в безопасности. Если вам нужен каждый бит производительности, который вы можете получить или иметь много общих данных (таких как сложные структуры данных), используйте потоки.

Решение между потоком / процессом немного зависит от того, для чего вы будете его использовать. One of the benefits with a process is that it has a PID and can be killed without also terminating the parent.

For a real world example of a web server, apache 1.3 used to only support multiple processes, but in in 2.0 they added an abstraction so that you can swtch between either. Comments seems to agree that processes are more robust but threads can give a little bit better performance (except for windows where performance for processes sucks and you only want to use threads).

How tightly coupled are your tasks?

If they can live independently of each other, then use processes. If they rely on each other, then use threads. That way you can kill and restart a bad process without interfering with the operation of the other tasks.

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

В современном Linux (2.6.x) нет большой разницы в производительности между переключением контекста процесса по сравнению с поток (только MMU является дополнительным для потока). Существует проблема с общим адресным пространством, что означает, что ошибочный указатель в потоке может повредить память родительского процесса или другого потока в том же адресном пространстве.

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

Я бы обычно использовал процессы (небольшие накладные расходы на переключение контекста в Linux, но защита памяти из-за MMU) , но pthreads, если бы мне понадобился класс планировщика реального времени, который представляет собой совсем другое дело.

Как вы думаете, почему потоки имеют такой большой прирост производительности в Linux? У вас есть какие-то данные по этому поводу или это всего лишь миф?

Для большинства случаев я бы предпочел процессы, а не потоки. Потоки могут быть полезны, когда у вас есть относительно меньшая задача (накладные расходы на процесс >> время, затрачиваемое каждой разделенной единицей задачи) и есть необходимость разделения памяти между ними. Вспомните большой массив. Кроме того (оффтопик), обратите внимание, что если загрузка вашего процессора составляет 100% или близка к этому, то многопоточность или обработка не принесут никакой пользы. (на самом деле это только ухудшит ситуацию)