Что такое процесс и поток?

Обычно при запуске исполняемого файла, такого как notepad.exe, создается один процесс. Этот процесс может порождать другие процессы, но в большинстве случаев для каждого запускаемого исполняемого файла существует отдельный процесс. Внутри процесса может быть много потоков. Обычно сначала есть один поток, который обычно начинается с «точки входа» программы, которой обычно является функция main. Инструкции выполняются одна за другой по порядку, подобно тому, как человек, имеющий только одну руку, поток может делать только одно действие за раз, прежде чем он перейдет к следующему.

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

Это довольно упрощенное объяснение. Я мог бы вдаваться в подробности, но, вероятно, совпадал бы с тем, что вы найдете в своих учебниках.

РЕДАКТИРОВАТЬ: Вы заметите, что в моем объяснении много «обычно», поскольку иногда встречаются редкие программы, которые делают что-то совершенно по-другому.

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

Итак, что такое нить? Ближе всего я могу объяснить, что это состояние выполнения, например: комбинация регистров ЦП, стека, партии. Вы можете увидеть доказательство этого, взломав отладчик в любой данный момент. Что ты видишь? Стек вызовов, набор регистров. Это почти все. Это нить.

Итак, что это за процесс. Что ж, это что-то вроде абстрактного «контейнера» для запуска потоков. Что касается ОС в первом приближении, это ОС сущности, которая выделяет некоторую виртуальную машину, назначает некоторые системные ресурсы (например, дескрипторы файлов, сетевые сокеты) и т. Д.

Как они работают вместе? ОС создает «процесс», резервируя для него некоторые ресурсы и запуская «основной» поток. Затем этот поток может порождать больше потоков. Это нити в одном процессе. Они более или менее могут так или иначе делиться этими ресурсами (например, им может потребоваться блокировка, чтобы не испортить удовольствие другим и т. Д.). С этого момента ОС обычно отвечает за поддержание этих потоков «внутри» этой виртуальной машины (обнаружение и предотвращение попыток доступа к памяти, которая не «принадлежит» этому процессу), обеспечивая некоторый тип планирования этих потоков, чтобы они могли запускаться. "один за другим, а не один за другим".

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

Их конкретные реализации различаются чрезвычайно.

Сравните, например, процесс Erlang и процесс Windows: процесс Erlang очень легкий, часто менее 400 байт. Вы можете без проблем запустить 10 миллионов процессов на не очень свежем ноутбуке. Они запускаются очень быстро, умирают очень быстро, и ожидается, что вы сможете использовать их для очень коротких задач. С каждым процессом Erlang связан свой собственный сборщик мусора. Процессы Erlang никогда не могут совместно использовать память.

Процессы Windows очень тяжелые, иногда сотни мегабайт. Вы можете запустить, может быть, пару тысяч из них на мощном сервере, если вам повезет. Они запускаются и довольно медленно умирают. Процессы Windows - это единицы приложений, таких как IDE, текстовые редакторы или текстовые процессоры, поэтому обычно ожидается, что они будут жить довольно долгое время (по крайней мере, несколько минут). У них есть собственное адресное пространство, но нет сборщика мусора. Процессы Windows могут совместно использовать память, хотя по умолчанию это не так.

То же самое и с потоками: поток Linux NPTL на x86 может иметь размер всего 4 KiByte, а с помощью некоторых уловок вы можете запустить 800000+ на 32-битной машине x86. Машина, безусловно, будет использоваться с тысячами, а может быть, и с десятками тысяч потоков. Поток .NET CLR имеет минимальный размер около 1 мегабайта, что означает, что всего 4000 из них съедят все ваше адресное пространство на 32-битной машине. Итак, хотя 4000 потоков Linux NPTL обычно не проблема, вы не можете даже запустить 4000 потоков .NET CLR, потому что перед этим у вас закончится память.

Процессы ОС и потоки ОС также по-разному реализуются в разных операционных системах. Основные два подхода: ядро ​​знает только о процессах. Потоки реализуются библиотекой пользовательского пространства без какого-либо знания ядра. В этом случае снова есть два подхода: 1: 1 (каждый поток отображается на один процесс ядра) или m: n (m потоков сопоставляется с n процессами, где обычно m> n и часто n == # процессоров). Это был ранний подход, применявшийся во многих операционных системах после изобретения потоков. Однако он обычно считается неэффективным и был заменен почти во всех системах вторым подходом: потоки реализованы (по крайней мере частично) в ядре, так что теперь ядро ​​знает о двух различных объектах, потоках и процессах.

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

В зависимости от того, как вы устанавливаете эти флаги, вы получаете либо поток (общий доступ почти ко всему), либо процесс (общий доступ ко всем системным ресурсам, таким как системные часы, пространство имен файловой системы, сетевое пространство имен, пространство имен идентификатора пользователя, пространство имен идентификатора процесса, но не разделяют адресное пространство). Но вы также можете получить некоторые другие довольно интересные вещи. Вы можете легко получить тюрьмы в стиле BSD (в основном те же флаги, что и процесс, но не разделяйте файловую систему или сетевое пространство имен). Или вы можете получить то, что другие ОС называют контейнером или зоной виртуализации (например, тюрьмой, но не разделяйте пространства имен UID и PID и системные часы). Пару лет назад с помощью технологии под названием KVM (Kernel Virtual Machine) вы даже можете получить полноценную виртуальную машину (не делитесь ничем, даже таблицами страниц процессора). [Самое замечательное в этом то, что вы можете повторно использовать хорошо настроенный зрелый планировщик задач в ядре для всех этих вещей. Одна из причин, за которую виртуальная машина Xen часто критиковала, была низкая производительность ее планировщика. У разработчиков KVM есть гораздо лучший планировщик, чем у Xen, и самое лучшее, что им даже не пришлось писать для него ни единой строчки кода!]

Итак, в Linux производительность потоков и процессов намного ближе, чем в Windows и многих других системах, потому что в Linux это фактически одно и то же. Это означает, что шаблоны использования очень разные: в Windows вы обычно выбираете между использованием потока и процесса в зависимости от их веса: могу ли я позволить себе процесс или должен ли я использовать поток, даже если я на самом деле не хочу делиться государство? В Linux (и обычно в Unix в целом) вы принимаете решение на основе их семантики: действительно ли я хочу делиться состоянием или нет?

Одна из причин, почему процессы в Unix легче, чем в Windows, заключается в другом использовании: в Unix процессы являются базовой единицей параллелизма и функциональности. Если вы хотите использовать параллелизм, вы используете несколько процессов. Если ваше приложение можно разбить на несколько независимых частей, вы используете несколько процессов. Каждый процесс выполняет только одно и только одно. Даже простой однострочный сценарий оболочки часто включает десятки или сотни процессов. Приложения обычно состоят из множества, часто недолговечных процессов.

В Windows потоки являются основными единицами параллелизма, а компоненты COM или объекты .NET - основными единицами функциональности. Приложения обычно состоят из одного длительного процесса.

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

Практически единственное, что вы можете сказать о потоках и процессах:

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

Я бы сказал, что :

У процесса есть пространство памяти, открытые файлы, ... и один или несколько потоков.

Поток - это поток инструкций, который может быть запланирован системой на процессоре.

Взгляните на подробный ответ, который я дал ранее здесь, на SO < / а>. Это дает представление о структуре игрушечного ядра, отвечающего за поддержку процессов и потоков ...

В чем разница между процессом и потоком

Процесс против потока

Поток и процесс

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

Процесс включает в себя следующее:

• Частное виртуальное адресное пространство
• Программа.
• Список ручек.
• Маркер доступа.
• Уникальный идентификатор процесса.
• Хотя бы одна цепочка.
• Указатель на родительский процесс, независимо от того, существует этот процесс или нет.

При этом процесс может содержать несколько потоков.

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

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

У меня есть пара страниц в моей вики, на которые вы можете взглянуть:

Процесс

Тема

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

Физически:

• Процесс - это структура, которая поддерживает учетные данные владельца, список потоков и список открытых дескрипторов.

• Поток - это структура, содержащая контекст (то есть сохраненный набор регистров + место для выполнения), набор PTE, описывающих, какие страницы отображаются в виртуальное адресное пространство процесса, и владельца.

Это, конечно, чрезвычайно упрощенное объяснение, но оно содержит важные моменты. Фундаментальной единицей выполнения как в Linux, так и в Windows является поток - планировщик ядра не заботится о процессах (сильно). Вот почему в Linux поток - это просто процесс, который совместно использует PTE с другим процессом.

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

Трудно дать краткий ответ, который полностью оправдывает этот вопрос.

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

• Инструкции ЦП низкого уровня (также известные как программа).
• Состояние выполнения - указатель инструкции (на самом деле, специальный регистр), значения регистров и стек.
• Куча (она же память общего назначения).

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

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

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

С другой стороны, упреждение всего процесса обходится дороже, как вы можете себе представить.

Изменить: идеи применимы и к абстрактным платформам, таким как Java.

Если вы об этом спрашиваете, это не физические отрезки веревки. ;)

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

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

Если вы посмотрите на компьютер физически, вы получите нагромождение электроники, имитирующей то, что машина Тьюринга делает. Попытка сделать что-нибудь полезное с необработанной машиной Truing Machine превратит ваш мозг в желе за пять минут. Чтобы избежать этого неприятного опыта, компьютерщики разработали набор абстракций для разделения различных аспектов вычислений. Это позволяет вам сосредоточиться на интересующем вас уровне абстракции, не беспокоясь обо всем остальном, поддерживающем его. Некоторые вещи были встроены в схемы (например, сумматоры и т.п.), что делает их физическими, но подавляющее большинство того, с чем мы работаем, основано на заданных абстракциях. Как правило, используемые нами абстракции имеют некоторую математическую основу. Вот почему стеки, очереди и «состояние» играют такую ​​важную роль в вычислениях - вокруг этих абстракций существует хорошо обоснованный математический набор, который позволяет нам опираться на их манипуляции и рассуждать о них.

Виртуальная память: http://en.wikipedia.org/wiki/Virtual_memory можно пройти через связь.

Поэтому, когда процесс выводится из состояния выполнения планировщиком, его состояние, содержащее значения, хранящиеся в регистрах, его стек, куча и многое другое, сохраняется в структуре данных.

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

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

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

Поток управляется процессом, процесс управляется операционной системой

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

В Windows, по крайней мере, после прохождения Win 3.1 операционная система (ОС) содержит несколько процессов, каждый со своим собственным пространством памяти, и не может взаимодействовать с другими процессами без ОС.

У каждого процесса есть один или несколько потоков, которые совместно используют одно и то же пространство памяти и не нуждаются в ОС для взаимодействия с другими потоками.

Процесс - это контейнер потоков.

Что ж, я еще не видел ответа на вопрос «Что они собой представляют физически». Так что я попробую.

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

Процесс - это единое целое, например и exe-файл или один jvm. Может быть дочерний процесс родительского процесса, где exe-файл снова запускается в отдельном пространстве. Поток - это отдельный путь выполнения в том же процессе, где процесс контролирует, какой поток выполнять, останавливать и т. Д.

Пытаюсь ответить на этот вопрос, касающийся мира Java.

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

Например:

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

Пример 2: программа может не рисовать изображения, считывая нажатия клавиш. Программа должна уделять все свое внимание вводу с клавиатуры, и отсутствие возможности обрабатывать более одного события одновременно приведет к проблемам. Идеальное решение этой проблемы - непрерывное выполнение двух или более разделов программы одновременно. Threads позволяет нам это делать. Здесь Рисование изображения - это процесс, а чтение нажатия клавиши - это подпроцесс (поток).