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

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

Я не уверен, какие «аппаратные» и «программные» потоки вы имеете в виду. Потоки - это функция операционной среды, а не функция ЦП (хотя ЦП обычно выполняет операции, которые делают потоки эффективными).

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

An application consists of one or more processes. A process, in the simplest terms, is an executing program. One or more threads run in the context of the process. A thread is the basic unit to which the operating system allocates processor time. A thread can execute any part of the process code, including parts currently being executed by another thread. A fiber is a unit of execution that must be manually scheduled by the application. Fibers run in the context of the threads that schedule them.

Похищено с здесь.

И потоки, и процессы являются атомарными единицами распределения ресурсов ОС (т.е. существует модель параллелизма, описывающая, как время ЦП распределяется между ними, и модель владения другими ресурсами ОС). Есть разница в:

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

Выше Грег Хьюгилл был прав относительно значения слова «процесс» в Erlang, и здесь обсуждается, почему Erlang может облегчить процессы.

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

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

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

Эта информация была найдена в Microsoft Docs здесь: О процессах и потоках

Microsoft Windows supports preemptive multitasking, which creates the effect of simultaneous execution of multiple threads from multiple processes. On a multiprocessor computer, the system can simultaneously execute as many threads as there are processors on the computer.

Процесс:

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

Нить:

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

Приведенную выше информацию я позаимствовал из Квест знаний! блог.

1. Поток выполняется в общем пространстве памяти, но процесс выполняется в отдельном пространстве памяти.
2. Поток - это легкий процесс, но процесс тяжелый.
3. Поток - это подтип процесса.

Чтобы объяснить больше в отношении параллельного программирования

1. Процесс имеет автономную среду выполнения. Обычно процесс имеет полный частный набор основных ресурсов времени выполнения; в частности, каждый процесс имеет собственное пространство памяти.

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

Пример для среднего человека:

На вашем компьютере откройте Microsoft Word и веб-браузер. Мы называем эти два процессы.

В Microsoft Word вы что-то вводите, и это автоматически сохраняется. Теперь вы заметили, что редактирование и сохранение происходят параллельно - редактирование в одном потоке и сохранение в другом потоке.

Процесс: выполняемая программа известна как процесс

Нить: Поток - это функция, которая выполняется с другой частью программы на основе концепции «один с другим», поэтому поток является частью процесса.

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

A thread is another mechanism for splitting the workload into separate execution streams. A thread is lighter weight than a process. This means, it offers less flexibility than a full blown process, but can be initiated faster because there is less for the Operating System to set up. When a program consists of two or more threads, all the threads share a single memory space. Processes are given separate address spaces. all the threads share a single heap. But each thread is given its own stack.

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

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

Например:

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

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

• Каждый процесс - это поток (первичный поток).
• Но каждый поток - это не процесс. Это часть (сущность) процесса.

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

У нас есть следующее в разделе 2.2.2 Классическая модель резьбыСовременные операционные системы 3e Таненбаума:

The process model is based on two independent concepts: resource grouping and execution. Sometimes it is use­ful to separate them; this is where threads come in....

Он продолжает:

One way of looking at a process is that it is a way to group related resources together. A process has an address space containing program text and data, as well as other resources. These resource may include open files, child processes, pending alarms, signal handlers, accounting information, and more. By putting them together in the form of a process, they can be managed more easily. The other concept a process has is a thread of execution, usually shortened to just thread. The thread has a program counter that keeps track of which instruc­tion to execute next. It has registers, which hold its current working variables. It has a stack, which contains the execution history, with one frame for each proce­dure called but not yet returned from. Although a thread must execute in some process, the thread and its process are different concepts and can be treated sepa­rately. Processes are used to group resources together; threads are the entities scheduled for execution on the CPU.

Далее он приводит следующую таблицу:

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        |

Разберемся с проблемой аппаратная многопоточность. Классически ЦП будет поддерживать один поток выполнения, поддерживая состояние потока через один счетчик команд (ПК) и набор регистров. Но что происходит, когда происходит промах кеша? Извлечение данных из основной памяти занимает много времени, и пока это происходит, ЦП просто бездействует. Итак, у кого-то возникла идея в основном иметь два набора состояний потока (ПК + регистры), чтобы другой поток (может быть, в том же процессе, может быть, в другом процессе) мог выполнять работу, пока другой поток ожидает в основной памяти. Существует несколько названий и реализаций этой концепции, например Hyper Threading и одновременная многопоточность (сокращенно SMT).

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

1. Потоки пользовательского пространства
2. Потоки ядра
3. Комбинация двух

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

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

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

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

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

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

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

Here’s a summary of the differences between threads and processes:

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

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

3. Потоки считаются легкими, потому что они используют далеко меньше ресурсов, чем процессов.

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

5. Процесс может состоять из нескольких потоков.

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

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

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

1. Потоки совместно используют одно и то же пространство памяти, что означает, что поток может получать доступ к памяти из памяти других потоков. Процессы нормально не могут.
2. Ресурсы. Ресурсы (память, дескрипторы, сокеты и т. д.) Освобождаются при завершении процесса, а не при завершении потока.
3. Безопасность. У процесса есть фиксированный токен безопасности. С другой стороны, поток может олицетворять разных пользователей / токены.

Если вы хотите большего, ответ Скотта Лэнгема охватывает почти все. Все это с точки зрения операционной системы. Разные языки могут реализовывать разные концепции, такие как задачи, легкие потоки и так далее, но это всего лишь способы использования потоков (волокон в Windows). Нет аппаратных и программных потоков. Есть аппаратное и программное обеспечение исключения и прерывает, или пользовательский режим и ядро ​​потоки.

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

Процесс

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

Нить

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

- Взято из операционной системы Гэлвином.

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

Многоядерные системы могут выполнять несколько потоков выполнения, поэтому Python должен поддерживать многопоточность. Но Python - это не компилируемый язык, а интерпретируемый язык ¹. Это означает, что программа должна быть интерпретирована для запуска, и интерпретатор не знает о программе до того, как она начнет выполнение. Однако он знает правила Python и затем динамически применяет эти правила. Оптимизация в Python должна быть в основном оптимизацией самого интерпретатора, а не кода, который должен быть запущен. Это отличается от компилируемых языков, таких как C++, и имеет последствия для многопоточности в Python. В частности, Python использует глобальную блокировку интерпретатора для управления многопоточностью.

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

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

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

В Python данные защищены от одновременного доступа разными потоками с помощью Global Interpreter Lock. Это требует, чтобы в любой программе Python в любой момент мог выполняться только один поток. С другой стороны, можно запускать несколько процессов, поскольку память для каждого процесса изолирована от любого другого процесса, и процессы могут выполняться на нескольких ядрах.

¹ Дональд Кнут дает хорошее объяснение процедур интерпретации в книге «Искусство компьютерного программирования: фундаментальные алгоритмы».

Исходя из мира встраиваемых систем, я хотел бы добавить, что концепция процессов существует только в «больших» процессорах (настольные процессоры, ARM Cortex A-9), которые имеют MMU (блок управления памятью), и операционных системах, поддерживающих использование MMU (таких как Linux). В маленьких / старых процессорах и микроконтроллерах и небольшой операционной системе RTOS (операционная система реального времени), такой как freeRTOS, нет поддержки MMU и, следовательно, нет процессов, а есть только потоки.

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

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

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

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

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

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

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

Попытка ответить на него из обзора ОС ядра Linux

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

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

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

Внутри ядра каждый поток имеет свой собственный стек ядра вместе со структурой task_struct, которая определяет поток. Таким образом, ядро ​​рассматривает потоки одного и того же процесса как разные объекты, и их можно планировать сами по себе. Потоки в одном процессе имеют общий идентификатор, называемый идентификатором группы потоков (tgid), также у них есть уникальный идентификатор, называемый идентификатором процесса (pid).

Пример реального мира для процесса и потокаЭто даст вам общее представление о потоке и процессе.

Я позаимствовал приведенную выше информацию из ответа Скотта Лэнгхэма. - спасибо

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

Процесс:

1. Процесс - это тяжелый процесс.
2. Процесс - это отдельная программа, которая имеет отдельную память, данные, ресурсы и т. д.
3. Процесс создается с помощью метода fork ().
4. Переключение контекста между процессами занимает много времени.
   

Пример:
Скажем, открытие любого браузера (Mozilla, Chrome, IE). На этом этапе начнется выполнение нового процесса.

Потоки:

1. Потоки - это легковесные процессы, которые объединяются внутри процесса.
2. У потоков есть общая память, данные, ресурсы, файлы и т. д.
3. Потоки создаются с помощью метода clone ().
4. Переключение контекста между потоками занимает не так много времени, как Process.
   

Пример:
Открытие нескольких вкладок в браузере.

Лучший ответ, который я нашел до сих пор, - Майкл Керриск "Интерфейс программирования Linux":

In modern UNIX implementations, each process can have multiple threads of execution. One way of envisaging threads is as a set of processes that share the same virtual memory, as well as a range of other attributes. Each thread is executing the same program code and shares the same data area and heap. However, each thread has it own stack containing local variables and function call linkage information. [LPI 2.12]

Эта книга - источник большой ясности; Джулия Эванс упомянула его помощь в выяснении того, как группы Linux на самом деле работают в эта статья.

Для тех, кому удобнее учиться посредством визуализации, вот удобная диаграмма, которую я создал для объяснения процессов и потоков. Я использовал информацию из MSDN - О процессах и потоках

http://lkml.iu.edu/hypermail/linux/kernel/9608/0191.html

Linus Torvalds ([email protected])

Tue, 6 Aug 1996 12:47:31 +0300 (EET DST)

Messages sorted by: [ date ][ thread ][ subject ][ author ]

Next message: Bernd P. Ziller: "Re: Oops in get_hash_table"

Previous message: Linus Torvalds: "Re: I/O request ordering"

On Mon, 5 Aug 1996, Peter P. Eiserloh wrote:

We need to keep a clear the concept of threads. Too many people seem to confuse a thread with a process. The following discussion does not reflect the current state of linux, but rather is an attempt to stay at a high level discussion.

NO!

There is NO reason to think that "threads" and "processes" are separate entities. That's how it's traditionally done, but I personally think it's a major mistake to think that way. The only reason to think that way is historical baggage.

Both threads and processes are really just one thing: a "context of execution". Trying to artificially distinguish different cases is just self-limiting.

A "context of execution", hereby called COE, is just the conglomerate of all the state of that COE. That state includes things like CPU state (registers etc), MMU state (page mappings), permission state (uid, gid) and various "communication states" (open files, signal handlers etc). Traditionally, the difference between a "thread" and a "process" has been mainly that a threads has CPU state (+ possibly some other minimal state), while all the other context comes from the process. However, that's just one way of dividing up the total state of the COE, and there is nothing that says that it's the right way to do it. Limiting yourself to that kind of image is just plain stupid.

The way Linux thinks about this (and the way I want things to work) is that there is no such thing as a "process" or a "thread". There is only the totality of the COE (called "task" by Linux). Different COE's can share parts of their context with each other, and one subset of that sharing is the traditional "thread"/"process" setup, but that should really be seen as ONLY a subset (it's an important subset, but that importance comes not from design, but from standards: we obviusly want to run standards-conforming threads programs on top of Linux too).

In short: do NOT design around the thread/process way of thinking. The kernel should be designed around the COE way of thinking, and then the pthreads library can export the limited pthreads interface to users who want to use that way of looking at COE's.

Just as an example of what becomes possible when you think COE as opposed to thread/process:

• You can do a external "cd" program, something that is traditionally impossible in UNIX and/or process/thread (silly example, but the idea is that you can have these kinds of "modules" that aren't limited to the traditional UNIX/threads setup). Do a:

clone(CLONE_VM|CLONE_FS);

child: execve("external-cd");

/* the "execve()" will disassociate the VM, so the only reason we used CLONE_VM was to make the act of cloning faster */

• You can do "vfork()" naturally (it meeds minimal kernel support, but that support fits the CUA way of thinking perfectly):

clone(CLONE_VM);

child: continue to run, eventually execve()

mother: wait for execve

• you can do external "IO deamons":

clone(CLONE_FILES);

child: open file descriptors etc

mother: use the fd's the child opened and vv.

All of the above work because you aren't tied to the thread/process way of thinking. Think of a web server for example, where the CGI scripts are done as "threads of execution". You can't do that with traditional threads, because traditional threads always have to share the whole address space, so you'd have to link in everything you ever wanted to do in the web server itself (a "thread" can't run another executable).

Thinking of this as a "context of execution" problem instead, your tasks can now chose to execute external programs (= separate the address space from the parent) etc if they want to, or they can for example share everything with the parent except for the file descriptors (so that the sub-"threads" can open lots of files without the parent needing to worry about them: they close automatically when the sub-"thread" exits, and it doesn't use up fd's in the parent).

Think of a threaded "inetd", for example. You want low overhead fork+exec, so with the Linux way you can instead of using a "fork()" you write a multi-threaded inetd where each thread is created with just CLONE_VM (share address space, but don't share file descriptors etc). Then the child can execve if it was a external service (rlogind, for example), or maybe it was one of the internal inetd services (echo, timeofday) in which case it just does it's thing and exits.

You can't do that with "thread"/"process".

Linus

Различия между процессом и потоком приведены ниже:

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

Из Erlang Programming (2009 г.): Параллелизм в Erlang быстр и масштабируем. Его процессы легковесны, поскольку виртуальная машина Erlang не создает поток ОС для каждого созданного процесса. Они создаются, планируются и обрабатываются в виртуальной машине независимо от базовой операционной системы.

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

Процесс:

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

Нить:

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

ref-https://practice.geeksforgeeks.org/problems/difference-between-process-and-thread

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

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

Процесс - Программа выполняется

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

Например, вы хотите вычислить умножение матриц, вы напишете программу для 3 циклов внутри main и выполните ее. Теперь это ваш процесс.

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

В обоих случаях результат будет одинаковым.

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

Потоки запускают в параллели в области разделяемой памяти (процесса, который их создал):

Thread 1              Thread 2              Thread 3
   | 
   | 
   |
                         |
                         |
                                               |
                                               |
                                               |
   |
                         |
                         | 
                         |            
Complete             Complete              Complete

Примечание: приведенное выше можно интерпретировать как процесс (т.е. один процесс с 3 потоками).

Процессы работают с параллельно и одновременно:

Process 1              Process 2              Process 3
    |                      |                      |
    |                      |                      |
    |                      |                      |
    |                      |                      |
    |                      |                      |
    |                      |                      |
Complete               Complete               Complete

Thread - это легкий процесс, в то время как процесс является автономной средой выполнения.

Что подразумевается под «автономным процессом выполнения»? Частный набор основных ресурсов времени выполнения.

Что подразумевается под «частным набором основных ресурсов времени выполнения»? Пространство, выделенное из памяти для запуска процесса (просто пространство в памяти).