Какова техническая разница между процессом и потоком?
Я получаю ощущение, что слово "процесс" чрезмерно используется, а также есть потоки аппаратного и программного обеспечения. Как насчет легких процессов в таких языках, как Erlang? Есть ли определенная причина использовать один термин над другим?
Оба процесса и потоки являются независимыми последовательностями выполнения. Типичное различие заключается в том, что потоки (одного и того же процесса) выполняются в пространстве разделяемой памяти, а процессы выполняются в отдельных пространствах памяти.
Я не уверен, какие "аппаратные" и "программные" потоки вы могли бы иметь в виду. Threads - это функция операционной среды, а не функция CPU (хотя у процессора обычно есть операции, которые делают потоки эффективными).
Эрланг использует термин "процесс", потому что он не предоставляет модель мультипрограммирования с общей памятью. Вызов их "потоков" означает, что они имеют общую память.
Процесс
Каждый процесс предоставляет ресурсы, необходимые для выполнения программы. Процесс имеет виртуальное адресное пространство, исполняемый код, открытые дескрипторы системных объектов, контекст безопасности, уникальный идентификатор процесса, переменные среды, класс приоритета, минимальные и максимальные размеры рабочих наборов и, по крайней мере, один поток выполнения. Каждый процесс запускается одним потоком, который часто называется основным потоком, но может создавать дополнительные потоки из любого из его потоков.
Тема
Поток - это объект внутри процесса, который может быть запланирован для выполнения. Все потоки процесса разделяют его виртуальное адресное пространство и системные ресурсы. Кроме того, каждый поток поддерживает обработчики исключений, приоритет планирования, локальное хранилище потоков, уникальный идентификатор потока и набор структур, которые система будет использовать для сохранения контекста потока до его запланированного. Контекст потока включает набор потоков машинных регистров, стек ядра, блок среды потока и стек пользователя в адресном пространстве процесса потока. Темы могут также иметь свой собственный контекст безопасности, который может использоваться для олицетворения клиентов.
Обнаружено это на MSDN здесь:
О процессах и потоках
Microsoft Windows поддерживает упреждающую многозадачность, что создает эффект одновременного выполнения нескольких потоков из нескольких процессов. На многопроцессорном компьютере система может одновременно выполнять столько потоков, сколько есть процессоров на компьютере.
Обработать:
Нить:
Я заимствовал вышеупомянутую информацию из Quest Quest! блог.
Взято из "Параллельное и распределенное программирование с использованием С++" Кэмерона Хьюза и Трейси Хьюз, Таблица 4-1:
В чем разница между потоками и процессами?
Основные различия между потоками и процессами:
Во-первых, давайте посмотрим на теоретический аспект. Вам необходимо понять, что такое концептуально процесс, чтобы понять разницу между процессом и потоком и тем, что им поделено.
У нас есть следующее из раздела 2.2.2 Модель классической нити в Современные операционные системы 3e от Tanenbaum:
Модель процесса основана на двух независимых концепциях: ресурс группировка и исполнение. Иногда полезно разделить их; это где темы вступают....
Он продолжает:
Одним из способов взглянуть на процесс является то, что это способ группировать связанные ресурсы вместе. Процесс имеет адресное пространство содержащий текст программы и данные, а также другие ресурсы. Эти ресурс может включать открытые файлы, дочерние процессы, ожидающие тревоги, обработчики сигналов, учетная информация и многое другое. Положив их вместе в форме процесса ими можно легче управлять. Другая концепция, которую имеет процесс, - это поток выполнения, обычно сокращен до просто нити. В потоке есть счетчик программ, который хранит отслеживать, какую инструкцию выполнять дальше. У него есть регистры, которые держать свои текущие рабочие переменные. У него есть стек, который содержит история выполнения, с одним кадром для каждой вызванной процедуры, но не пока вернулся из. Хотя поток должен выполняться в каком-то процессе, нить и ее процесс - разные понятия и могут рассматриваться отдельно. Процессы используются для группировки ресурсов; потоки являются объектами, запланированными для выполнения на ЦП.
Далее он предоставляет следующую таблицу:
Per process items | Per thread items
------------------------------|-----------------
Address space | Program counter
Global variables | Registers
Open files | Stack
Child processes | State
Pending alarms |
Signals and signal handlers |
Accounting information |
Давайте разберемся с проблемой аппаратного многопоточности. Классически ЦП будет поддерживать один поток выполнения, поддерживая состояние потока с помощью единого счетчика программ и набора регистров. Но что произойдет, если отсутствует кеш? Для извлечения данных из основной памяти требуется много времени, и пока это происходит, процессор просто бездействует. Таким образом, у кого-то возникла идея в основном иметь два набора состояний потока (ПК + регистры), чтобы другой поток (может быть, в том же процессе, может быть, в другом процессе) мог выполнить работу, пока другой поток ожидает в основной памяти. Существует несколько имен и реализаций этой концепции, таких как HyperThreading и Одновременная многопоточность (SMT для краткости).
Теперь давайте посмотрим на стороне программного обеспечения. Существуют три основных способа реализации потоков на стороне программного обеспечения.
Все, что вам нужно для реализации потоков, - это возможность сохранять состояние процессора и поддерживать несколько стеков, что во многих случаях может быть сделано в пространстве пользователя. Преимущество потоков в пользовательском пространстве заключается в супер-быстром переключении потоков, поскольку вам не нужно захватывать ядро и возможность планировать свои потоки так, как вам нравится. Самый большой недостаток - невозможность блокировать ввод-вывод (который блокировал бы весь процесс и все его пользовательские потоки), что является одной из основных причин, по которым мы используем потоки в первую очередь. Блокировка ввода/вывода с использованием потоков во многих случаях значительно упрощает разработку программы.
Преимущество потоков ядра в том, что они могут использовать блокирующий ввод/вывод, в дополнение к тому, что все проблемы с планированием оставлены для ОС. Но каждое переключение потоков требует захвата в ядро, что потенциально относительно медленно. Однако, если вы переключаете потоки из-за заблокированного ввода-вывода, это на самом деле не проблема, поскольку операция ввода-вывода, вероятно, в любом случае заманила вас в ядро.
Другой подход заключается в объединении двух потоков с несколькими потоками ядра, каждый из которых имеет несколько пользовательских потоков.
Итак, возвращаясь к вашему вопросу о терминологии, вы можете увидеть, что процесс и поток выполнения - это две разные концепции, и выбор того, какой термин использовать, зависит от того, о чем вы говорите. Что касается термина "облегченный процесс", я лично не вижу в этом смысла, поскольку он на самом деле не передает происходящего, а также термин "нить исполнения".
Чтобы объяснить больше в отношении параллельного программирования
Процесс имеет автономную среду исполнения. Обычно процесс имеет полный, частный набор базовых ресурсов времени выполнения; в частности, каждый процесс имеет собственное пространство памяти.
Темы существуют в процессе - каждый процесс имеет хотя бы один. Темы разделяют ресурсы процесса, включая память и открытые файлы. Это обеспечивает эффективную, но потенциально проблематичную связь.
Имея в виду среднего человека,
На компьютере откройте Microsoft Word и веб-браузер. Мы называем эти два процесса.
В слове Microsoft вы вводите что-то, и оно автоматически сохраняется. Теперь вы заметили бы, что редактирование и сохранение происходит параллельно - редактирование в одном потоке и сохранение в другом потоке.
Приложение состоит из одного или нескольких процессов. Процесс, в простейших терминах, является исполняющей программой. Один или несколько потоков выполняются в контексте процесса. Поток - это базовый блок, на который операционная система выделяет процессорное время. Поток может выполнять любую часть кода процесса, включая части, которые в настоящее время исполняются другим потоком. Волокно - это блок выполнения, который должен быть запланирован вручную приложением. Волокна выполняются в контексте потоков, которые их планируют.
Украден из здесь.
Процесс представляет собой набор кода, памяти, данных и других ресурсов. Поток - это последовательность кода, которая выполняется в рамках процесса. Вы можете (обычно) иметь несколько потоков, выполняемых одновременно в рамках одного процесса.
Пример реального мира для процесса и потока
Это даст вам основную идею о потоке и процессе
Я заимствовал вышеупомянутую информацию от Скотта Лангхэма. Ответ - спасибо
Процесс:
Пример:
Скажем, открытие любого браузера (mozilla, Chrome, IE). На этом этапе начнется выполнение нового процесса.
Тема:
Пример:
Открытие нескольких вкладок в браузере.
Процесс - это исполняемый экземпляр приложения. Что это значит? Например, когда вы дважды щелкните значок Microsoft Word, вы запускаете процесс, который запускает Word. Поток - это путь выполнения внутри процесса. Кроме того, процесс может содержать несколько потоков. При запуске Word операционная система создает процесс и начинает выполнять основной поток этого процесса.
Важно отметить, что поток может делать все, что может сделать процесс. Но поскольку процесс может состоять из нескольких потоков, поток можно рассматривать как "легкий процесс". Таким образом, существенная разница между потоком и процессом - это работа, которую каждый из них использует. Темы используются для небольших задач, тогда как процессы используются для более тяжелых задач - в основном, для выполнения приложений.
Другая разница между потоком и процессом заключается в том, что потоки одного и того же процесса имеют одинаковое адресное пространство, тогда как в разных процессах нет. Это позволяет потокам читать и записывать те же структуры данных и переменные, а также облегчает обмен данными между потоками. Связь между процессами - также известная как IPC или межпроцессная коммуникация - довольно сложна и ресурсоемкой.
Оба процесса и потоки являются независимыми последовательностями выполнения. Типичное различие заключается в том, что потоки (одного и того же процесса) выполняются в пространстве разделяемой памяти, а процессы выполняются в отдельных пространствах памяти.
Процесс
Выполняется программа. он имеет текстовую секцию, то есть программный код, текущую активность, представленную значением счетчика программ и содержимого регистра процессоров. Он также включает в себя стек процесса, который содержит временные данные (такие как параметры функции, обратные адреса и локальные переменные) и раздел данных, который содержит глобальные переменные. Процесс может также включать кучу, которая является памятью, которая динамически распределяется во время выполнения процесса.
Тема
Поток - это базовая единица использования ЦП; он содержит идентификатор потока, счетчик программ, набор регистров и стек. он совместно с другими потоками, принадлежащими к одному процессу, является его секцией кода, секцией данных и другими ресурсами операционной системы, такими как открытые файлы и сигналы.
- Взято из операционной системы Galvin
Оба потока и процессы являются атомными единицами распределения ресурсов ОС (т.е. существует модель concurrency, описывающая, как время CPU разделено между ними, и модель владения другими ресурсами ОС). Существует разница в:
Грег Хьюджилл выше был прав относительно значения Эрланга слова "процесс", а здесь обсуждалось, почему Erlang может делать процессы в легком весе.
Попытка ответить на этот вопрос, связанный с миром Java.
Процесс - это выполнение программы, но поток - это одна последовательность выполнения внутри процесса. Процесс может содержать несколько потоков. Поток иногда называют облегченным процессом.
Например:
Пример 1: JVM работает в одном процессе, а потоки в JVM разделяют кучу, принадлежащую этому процессу. Вот почему несколько потоков могут обращаться к одному и тому же объекту. Темы разделяют кучу и имеют собственное пространство стека. Это то, как один поток вызова метода и его локальные переменные сохраняются в потоковом режиме из других потоков. Но куча не является потокобезопасной и должна быть синхронизирована для обеспечения безопасности потоков.
Пример 2: Программа, возможно, не сможет рисовать изображения, читая нажатия клавиш. Программа должна уделять все внимание клавиатурному входу и не иметь возможности обрабатывать более одного события за раз, что приведет к проблемам. Идеальное решение этой проблемы - бесшовное выполнение двух или более разделов программы одновременно. Потоки позволяют нам это делать. Здесь Рисунок рисунка - это процесс, и чтение нажатия клавиши - это подпроцесс (поток).
http://lkml.iu.edu/hypermail/linux/kernel/9608/0191.html
Линус Торвальдс ([email protected])
Вт, 6 авг 1996 12:47:31 +0300 (EET DST)
Сообщения отсортированы по: [дате] [теме] [теме] [автору]
Следующее сообщение: Bernd P. Ziller: "Re: Oops in get_hash_table"
Предыдущее сообщение: Linus Torvalds: "Re: I/O request ordering"
В понедельник, 5 августа 1996 года, Питер П. Эйзерло писал:
Нам нужно четко понимать концепцию потоков. Слишком много людей, похоже, путают нить с процессом. Следующее обсуждение не отражает текущее состояние Linux, а является попыткой остаться на обсуждении высокого уровня.
НЕТ!
Нет никаких оснований полагать, что "потоки" и "процессы" являются отдельными объектами. То, как это традиционно было сделано, но я лично считаю, что это большая ошибка, чтобы думать так. Единственная причина думать, что это исторический багаж.
Оба потока и процессы - это всего лишь одно: "контекст исполнения". Пытаться искусственно различать разные случаи - это просто самоограничение.
"Контекст исполнения", называемый COE, является всего лишь конгломератом всего состояния этого COE. Это состояние включает в себя такие вещи, как состояние процессора (регистры и т.д.), Состояние MMU (отображения страниц), состояние разрешения (uid, gid) и различные "состояния связи" (открытые файлы, обработчики сигналов и т.д.). Традиционно разница между "потоком" и "процессом" в основном заключалась в том, что потоки имеют состояние процессора (возможно, какое-то другое минимальное состояние), в то время как весь другой контекст происходит из процесса. Тем не менее, это всего лишь один способ деления общего состояния СЕ, и нет ничего, что говорило бы, что это правильный способ сделать это. Ограничение себя таким образом просто глупо.
То, как Linux думает об этом (и как я хочу, чтобы все работало), заключается в том, что нет такой вещи, как "процесс" или "поток". Существует только совокупность COE (называемая "задача" Linux). Различные COE могут разделять части своего контекста друг с другом, и один поднабор этого совместного использования является традиционной установкой "поток"/"процесс", но это должно действительно рассматриваться как ТОЛЬКО подмножество (это важное подмножество, но это значение имеет значение не от дизайна, а от стандартов: мы, очевидно, хотим запускать программы, соответствующие стандартам, поверх Linux тоже).
Короче говоря: НЕ проектируйте вокруг потока/процесса мышления. Ядро должно быть спроектировано вокруг метода COE, а затем библиотека pthreads может экспортировать ограниченный интерфейс pthreads для пользователей, которые хотят использовать этот способ просмотра COE.
Как пример того, что становится возможным, когда вы думаете, что COE в отличие от потока/процесса:
- Вы можете сделать внешнюю программу "cd", что традиционно невозможно в UNIX и/или процессе/потоке (глупый пример, но идея в том, что вы можете иметь такие "модули", которые не ограничены традиционной UNIX/threads). Сделайте:
Клон (CLONE_VM | CLONE_FS);
child: execve ("external-cd");
/* "execve()" отключит виртуальную машину, поэтому единственной причиной, по которой мы использовали CLONE_VM, было ускорение процесса клонирования */
- Вы можете сделать "vfork()" естественно (он требует минимальной поддержки ядра, но эта поддержка идеально подходит для CUA):
Клон (CLONE_VM);
child: продолжить выполнение, в конце концов execve()
мать: дождитесь
- вы можете делать внешние "детекторы IO":
клон (CLONE_FILES);
child: открыть файловые дескрипторы и т.д.
мать: используйте fd, который открыл ребенок, и vv.
Все вышесказанное работает, потому что вы не привязаны к процессу мышления нить/процесс. Например, подумайте о веб-сервере, где сценарии CGI выполняются как "потоки выполнения". Вы не можете делать это с помощью традиционных потоков, потому что традиционным потокам всегда приходится делиться всем адресным пространством, поэтому вам нужно будет ссылаться во всем, что вы когда-либо хотели сделать на самом веб-сервере ("поток" не может работать другой исполняемый файл).
Размышляя об этом как о проблеме "контекста исполнения", ваши задачи теперь могут выбрать выполнение внешних программ (= отделить адресное пространство от родителя) и т.д., Если они захотят, или они могут, например, делиться всем с родителем, за исключением файловые дескрипторы (так что потоки sub- "могут открывать множество файлов без родителя, который должен беспокоиться о них: они автоматически закрываются, когда поток sub- завершается, и он не использует fd в родитель).
Например, подумайте о резьбовом "inetd". Вам нужен небольшой накладной fork + exec, поэтому с помощью Linux вы можете вместо использования "fork()" писать многопоточную inetd, где каждый поток создается с помощью только CLONE_VM (обменивайте адресное пространство, но не обменивайтесь файлом дескрипторы и т.д.). Тогда ребенок может выполнить, если это внешняя служба (например, rlogind), или, возможно, это одна из внутренних служб inetd (echo, timeofday), и в этом случае она просто делает это и выходит.
Вы не можете сделать это с помощью "thread"/"process".
Линус
Разница между потоком и процессом?
Процесс - это исполняемый экземпляр приложения, а поток A - это путь выполнения внутри процесса. Кроме того, процесс может содержать несколько потоков. Важно отметить, что поток может делать все, что может сделать процесс. Но поскольку процесс может состоять из нескольких потоков, поток можно рассматривать как "легкий процесс". Таким образом, существенная разница между потоком и процессом - это работа, которую каждый из них использует. Темы используются для небольших задач, тогда как процессы используются для более тяжелых задач - в основном, для выполнения приложений.
Другая разница между потоком и процессом заключается в том, что потоки одного и того же процесса имеют одинаковое адресное пространство, тогда как в разных процессах нет. Это позволяет потокам читать и записывать те же структуры данных и переменные, а также облегчает обмен данными между потоками. Связь между процессами - также известная как IPC или межпроцессная связь - довольно сложна и ресурсоемкой.
Получает резюме различий между потоками и процессами:
Темы легче создавать, чем процессы, поскольку они не требуют отдельного адресного пространства.
Многопоточность требует тщательного программирования, поскольку потоки разделять структуры данных, которые должны быть изменены только одним потоком вовремя. В отличие от потоков процессы не имеют одинаковых адресное пространство.
Потоки считаются легкими, потому что они используют меньше ресурсов, чем процессов.
Процессы независимы друг от друга. Темы, так как они
разделять одно и то же адресное пространство, являются взаимозависимыми, поэтому предостережение
должны быть приняты так, чтобы разные потоки не наступали друг на друга.
Это действительно другой способ заявить № 2 выше.
Процесс может состоять из нескольких потоков.
Вот что я получил из одной из статей The Code Project. Я думаю, это объясняет все, что нужно четко.
Поток - это еще один механизм разделения рабочей нагрузки на отдельные потоки исполнения. Нить легче, чем процесс. Этот означает, что он предлагает меньше гибкости, чем полноценный процесс, но может запускаться быстрее, потому что операционная система меньше настроить. Когда программа состоит из двух или более потоков, все потоки разделяют одно пространство памяти. Процессы имеют отдельные адресные пространства. все потоки разделяют одну кучу. Но каждому потоку предоставляется свой стек.
С точки зрения интервьюера, в основном есть только три основные вещи, которые я хочу услышать, помимо очевидных вещей, таких как процесс может иметь несколько потоков:
Если вы хотите больше, ответ Скотта Лэнгэма в значительной степени охватывает все. Все это с точки зрения операционной системы. Различные языки могут реализовывать различные концепции, такие как задачи, потоки света и т.д., Но это просто способы использования потоков (из волокон в Windows). Нет никаких аппаратных и программных потоков. Существуют аппаратные и программные исключения и прерывания, или пользовательский режим и ядро .
Процесс: исполняемая программа известна как процесс
Тема: Thread - это функциональность, которая выполняется с другой частью программы на основе концепции "один с другим", поэтому поток является частью процесса.
Исходя из встроенного мира, я хотел бы добавить, что концепция процессов существует только в "больших" процессорах (настольных процессорах, ARM Cortex A-9) с MMU (модулем управления памятью) и операционных системах, которые поддерживают используя MMU (например, Linux). С небольшими/старыми процессорами и микроконтроллерами и небольшой операционной системой RTOS (операционная система реального времени), например freeRTOS, нет поддержки MMU и, следовательно, нет процессов, но только потоки.
Темы могут иметь доступ к памяти других пользователей, и они планируются ОС чередующимся образом, поэтому они кажутся запущенными параллельно (или с многоядерными ядрами они работают параллельно).
Процессы, с другой стороны, живут в своей частной песочнице виртуальной памяти, предоставляемой и охраняемой MMU. Это удобно, потому что оно позволяет:
Попытка ответить на него из представления Linux Kernel OS
Программа становится процессом при запуске в память. Процесс имеет собственное адресное пространство, имеющее различные сегменты в памяти, такие как .text segement для хранения скомпилированного кода .bss для хранения неинициализированных статических или глобальных переменных и т.д. Каждый процесс имеет свой собственный счетчик программ и стек пользовательских spcae. Внутри ядра каждый процесс имеет свой собственный стек ядра (который отделен от стека пользовательского пространства для проблем безопасности) и структуру с именем task_struct, которая обычно абстрагируется как блок управления процессом, сохраняя всю информацию о процессе, таком как его приоритет, состояние, (и целый ряд других фрагментов). Процесс может иметь несколько потоков выполнения.
Приступая к потокам, они находятся внутри процесса и совместно используют адресное пространство родительского процесса вместе с другими ресурсами, которые могут быть переданы во время создания потоков, такие как ресурсы файловой системы, совместное использование ожидающих сигналов, обмен данными (переменными и инструкциями), поэтому потоки легкие и, следовательно, позволяют ускорить переключение контекста. Внутри ядра каждый поток имеет свой собственный стек ядра вместе с структурой task_struct, которая определяет поток. Поэтому ядро просматривает потоки того же процесса, что и разные сущности, и сами по себе планируются. Темы одного и того же процесса имеют общий идентификатор, называемый идентификатором группы потоков (tgid), также они имеют уникальный идентификатор, называемый идентификатором процесса (pid).
Для тех, кто более удобен в обучении с помощью визуализации, вот удобная диаграмма, которую я создал для объяснения процессов и потоков.
Я использовал информацию из MSDN - О процессах и потоках
Процесс:
Процесс в основном программа в исполнении. Это активный субъект. Некоторые операционные системы используют термин "задача" для обозначения выполняемой программы. Процесс всегда хранится в основной памяти, также называемой основной памятью или оперативной памятью. Следовательно, процесс называется активным субъектом. Исчезает, если машина перезагружена. Несколько процессов могут быть связаны с одной и той же программой. В многопроцессорной системе несколько процессов могут выполняться параллельно. В однопроцессорной системе, хотя истинный параллелизм не достигается, применяется алгоритм планирования процессов, и процессор планирует выполнять каждый процесс по одному, создавая иллюзию параллелизма. Пример: выполнение нескольких экземпляров программы ‘Калькулятор. Каждый из экземпляров называется процессом.
Тема:
Поток - это подмножество процесса. Он называется "легковесным процессом", поскольку он похож на реальный процесс, но выполняется в контексте процесса и использует те же ресурсы, которые выделены для процесса ядром. Обычно процесс имеет только один поток управления - один набор машинных инструкций, выполняемых одновременно. Процесс также может состоять из нескольких потоков выполнения, которые выполняют инструкции одновременно. Несколько потоков управления могут использовать истинный параллелизм, возможный в многопроцессорных системах. В однопроцессорной системе применяется алгоритм планирования потоков, и процессор планирует запускать каждый поток по одному. Все потоки, работающие внутри процесса, имеют одинаковое адресное пространство, дескрипторы файлов, стек и другие атрибуты, связанные с процессом. Поскольку потоки процесса совместно используют одну и ту же память, синхронизация доступа к совместно используемым данным внутри процесса приобретает беспрецедентную важность.
ref-https://practice.geeksforgeeks.org/problems/difference-between-process-and-thread
При построении алгоритма в Python (интерпретируемый язык), который включал многопоточность, я был удивлен, увидев, что время выполнения не было лучше, по сравнению с последовательным алгоритмом, который я ранее построил. Чтобы понять причину этого результата, я сделал некоторое чтение, и считаю, что то, что я узнал, предлагает интересный контекст, чтобы лучше понять различия между многопоточными и многопроцессорными процессами.
Многоядерные системы могут выполнять несколько потоков выполнения, поэтому Python должен поддерживать многопоточность. Но Python не является скомпилированным языком и вместо этого является интерпретированным языком 1. Это означает, что программа должна интерпретироваться для запуска, а интерпретатор не знает о программе до ее начала. Однако он знает правила Python и затем динамически применяет эти правила. Оптимизация в Python должна быть главным образом оптимизацией самого интерпретатора, а не кода, который должен быть запущен. Это в отличие от скомпилированных языков, таких как С++, и имеет последствия для многопоточности в Python. В частности, Python использует Global Interpreter Lock для управления многопоточными.
С другой стороны, скомпилированный язык, ну, компилируется. Программа обрабатывается "полностью", где сначала она интерпретируется в соответствии с ее синтаксическими определениями, затем отображается на промежуточное представление агностического языка и, наконец, связана с исполняемым кодом. Этот процесс позволяет очень оптимизировать код, поскольку он доступен во время компиляции. Различные взаимодействия программ и отношения определяются на момент создания исполняемого файла и могут быть приняты надежные решения об оптимизации.
В современных средах интерпретатор Python должен допускать многопоточность, и это должно быть безопасным и эффективным. В этом случае различие между интерпретируемым языком и скомпилированным языком входит в картину. Интерпретатор не должен нарушать внутренние данные из разных потоков и в то же время оптимизировать использование процессоров для вычислений.
Как отмечалось в предыдущих сообщениях, как процесс, так и поток являются независимыми последовательными выполнением, причем основное различие заключается в том, что память распределяется между несколькими потоками процесса, а процессы изолируют их пространства памяти.
В Python данные защищены от одновременного доступа различными потоками с помощью Global Interpreter Lock. Это требует, чтобы в любой программе Python в любой момент можно было выполнить только один поток. С другой стороны, можно запускать несколько процессов, поскольку память для каждого процесса изолирована от любого другого процесса, а процессы могут выполняться на нескольких ядрах.
1 У Дональда Кнута есть хорошее объяснение интерпретационных подпрограмм в "Искусстве компьютерного программирования: фундаментальные алгоритмы".
Нити внутри одного процесса совместно используют память, но каждый поток имеет свой собственный стек и регистры, а потоки хранят данные, зависящие от потока, в куче. Нити никогда не выполняются независимо, поэтому межпоточная связь намного быстрее по сравнению с межпроцессорной связью.
Процессы никогда не используют одну и ту же память. Когда дочерний процесс создает его, он дублирует расположение памяти родительского процесса. Коммуникация процесса выполняется с использованием канала, разделяемой памяти и разбора сообщений. Контекстное переключение между потоками происходит очень медленно.
Они почти такие же... Но главное отличие - поток легкий, а процесс тяжелый с точки зрения переключения контекста, рабочей нагрузки и т.д.