процессы и потоки
помогите пожалуйста разобраться с понятиями процесса и потока в самом общем виде. я понимаю их так:
1. процессы существуют на уровне операционной системы. она при создании очередного потока выделяет ему ресурс, в первую очередь в виде кусочка оперативной памяти.
2. если в системе существуют несколько процессов, то они не могут взаимодействовать.
3. например если в одном процессе запущен браузер, а во втором процессе запущена игра, то игра никак не может узнать какие вкладки браузера открыты в данный момент.
4. при этом если процесс браузера породит дочерний поток(например в виде отдельного окна для диспетчера задач браузера), то они могут взаимодействовать потому что связаны отношением «родитель-наследник».
5. потоки создаются средствами языка программирования и существуют в пределах процесса.
6. при этом они могут взаимодействовать в пределах своего процесса.
7. например иметь доступ к переменной: менять её, удалять и т.д.
8. а также получать друг от друга сигналы типа mutex, semafor и т.д.
9. при этом потоки, которые живут в разных процессах не могут взаимодействовать.
10. если завершается процесс, то завершаются все его потоки тоже.
11. процессы выполняются по очереди. ОС выделяет каждому определённое время. в это время он выполняется, а остальные процессы не активны. далее по очереди каждый процесс становится активным, а остальные неактивными
12. ОС сама решает по какому принципу усыплять и оживлять процессы. в зависимости от типа ОС этот принцип бывает разный
если я что-то неправильно понимаю, то пожалуйста укажите на это и, если можно, посоветуйте что почитать чтобы вополнить пробел.
Если забанили в гугле , то восполняем пробел . Их много у него. 🙂 https://m.youtube.com/watch?v=Ni8udz5bRmU
Таненбаум в помощь — у него все это подробно описано
Всё не то чтобы так, у тебя очень много теоретических допущений, которые на практике диаметрально противоположны оказываются. Лучше посмотри как это на самом деле реализовано и работает, скажем, на примере си и линукса (это лишь 1 из вариантов, точнее даже несколько).
1.И тот и другой регистрируются в ОС, процесс более сложен — память, образ на диске, переменные окружения, командная строка и проч. 2. нет
4.просто могут, не потому что
5.создаются вызовом ОС, это объект для ОС, не языка
Поток содержит код и данные. Процесс выполняет код выбранный из потока
Не путай человека, и сам не путайся
Тема обширная, чтобы тут расписывать, но пожалуй стоит сказать, что на уровне железа и процесс, и поток существуют. Для проца оба являются одним и тем же «задачей» (task), и разница только в том, какие области памяти и ресурсы ядра «видят» две/три/15 разных задач. Могут иметь общую память, а могут не иметь, смотря кому что отмапит ядро ос. На уровне ос разница уже существеннее, т.к. процесс это еще и учетная единица, где есть главный поток, есть ресурсы ядра вроде дескрипторов или примитивов синхронизации, есть состояние навроде cwd, есть ipc — shm, mmap, etc. Это ос создает различие на базе одного общего механизма многозадачности, которому самому абсолютно похрен на это все. Можешь рассматривать процесс как некую структуру в ядре, у которой есть не менее одного потока (на самом деле не менее нуля, если считать zombie за процессы). И потоки внутри процесса шарят как эту «структуру», так и память и прочее.
В теории можно написать такую ос, где можно было бы создать межпроцессный поток, который видел бы память и ядерные ресурсы двух процессов, а они (их главные потоки) друг друга не видели бы, но отдельным процессом он бы не был. И жил бы он пока оба процесса не кончились. Но так не делают. Но например низкоуровневый отладчик вроде gdb такое легко провернул бы, если бы захотел, прямо на линуксе.
3. например если в одном процессе запущен браузер, а во втором процессе запущена игра, то игра никак не может узнать какие вкладки браузера открыты в данный момент.
Сфига-ли? Хэндлы окон совершенно не против, чтобы их перехватывали и творили там что угодно, хоть член нарисуй в натуральную величину.
Ну, если лезть в дебри программирования. То есть два класса: Process и Thread. Чем они отличаются? Свойствами, вестимо. Я не знаю как ты, а я с первого раза в гугле нашел, чем отличается поток от процесса. Процесс — не лезет в другие участки памяти, кроме выделенного своего. Иначе- BSoD. Поток — лезет в участки памяти, но только своих приложений, которых может быть несколько. Ну, это грубо говоря.
Всё равно что инкапсуляцию и полиморфизм обьяснять на пальцах. Один хрен, не поймут.
В случае с Linux потоки — это тоже процессы, просто у потоков одного процесса есть общие сегменты памяти.
Процесс создаётся через системный вызов clone() (можно через fork(), но glibc’шный враппер fork() использует clone()), поток создаётся через clone(). Почитай ман этого системного вызова, там описано, какие части контекста процесса можно шарить.
Процессы и нити в Линукс
Чем отличаются процессы и нити в Линукс? В книге Дмитрия Кетова я прочитал, что процесс состоит из нитей. Но ведь у нитей тоже есть PID и свойства, как у обычных процессов, и порождать другие нити они тоже могут.
2 ответа 2
Определение
Раз уж говорим о *nix системах, то не лишним будет опираться на определения POSIX (вольный перевод):
Thread (досл. нить, она же поток ¹ ) — это один из потоков выполнения (flow control) в составе процесса. У каждой нити есть свой thread ID, приоритет и политика планировщика, errno , своё обособленное хранилище формата ключ/значение, и необходимые ресурсы, чтобы поддерживать поток выполнения. Любой объект, адрес которого может определить нить будет доступен всем нитям данного процесса, включая, но не ограничиваясь, статическими переменными, памятью, полученным посредством malloc() , другим областям памяти, к которым возможен прямой доступ по адресу, и автоматическим переменным.
Процесс — адресное пространство с одной или более нитью, исполняющейся в контексте оного, а также необходимые ресурсы для данных нитей.
Замечание: многие системные ресурсы разделяются (используются совместно) разными нитями одного процесса. В том числе различные идентификаторы (PID, PPID, PGID, SSID, различные SUID’ы и SGID’ы), текущий рабочий каталог, корневой каталог, umask и файловые дескрипторы.
Отсюда вырисовываются следующие ассоциации ресурсов.
- Адресное пространство (включая код, а также статические и динамические данные программы)
- Одна или более нить
- Таблица файловых дескрипторов
- Другие системные ресурсы и идентификаторы
При этом у каждой нити процесса также есть:
- Поток выполнения, на практике это значит:
- Свой стек и, как следствие, свои локальные переменные.
- Свои регистры процессора
Особенности реализации потоков в Linux.
Фактически, потоки в Linux реализованы, как «легковесные процессы». Другими словами со стороны ядра linux нет чёткого разграничения между оными: все они представляются в ядре, как задачи task_struct , при этом, например, task->mm указывает на дескриптор адресного пространства ( mm_struct ), а task->files на таблицу файловых дескрипторов ( files_struct ) и для потоков одного процесса оба эти указателя будут просто указывать на один объект. ИМХО прежде всего это сделано в силу исторических причин, хотя такая реализация и не лишена своей красоты.
И всё бы ничего, но это породило просто невообразимую терминологическую кашу. Например, со стороны пользовательского пространства идентификатор процесса (то что возвращает getpid() , он должен быть одинаковый для всех потоков процесса) называется PID; но на стороне ядра под pid ‘ом подразумевается идентификатор задачи, а вызов getpid() возвращает то что называется tgid (thread group ID, ID группы потоков). Но при этом через /proc экспортируется информация именно в терминах ядра.
Также такая реализация предполагает определённые ухищрения, частично на стороне ядра, частично на стороне пользовательского пространства, например, системный вызов setuid(2) в linux устанавливает только EUID потока, поэтому приходится прибегать к сложным манипуляциям в обёртке в libc, чтобы добиться поведения соответствующего POSIX и, как следствие, возникают проблемы с реализацией этой функции в языках независимых от Си, например Rust или Go.
Но ведь у нитей тоже есть PID и свойства, как у обычных процессов,
Не совсем так: единственное, что у них есть — это приоритет и политика в планировщике. всё остальное — баги и/или особенности реализации.
и порождать другие нити они тоже могут.
Да, но здесь стоит заметить, что в отличии от порождения процесса, «родителем» новой нити становится исходный процесс, а не тот что породил нить.
¹я предпочитаю термин «поток», но дабы не разгребать терминологическую путаницу с flow буду использовать «нить» в данном разделе
Что из этого является потоками?
Доброго времени суток. Не могу разобраться, что из этого является именно потоками, и как их вообще отличать от процессов. Самой системы Linux на PC нет, опираюсь на скриншоты. Именно этот сделан в командной строке с «top H». Очень надеюсь на Вашу помощь, т.к. сам разобраться не смог, да и в сети что-то так и не нашел однозначного ответа на то, как их отличать.
Всё что вы видите это потоки — кто вам такое сказал . Читаем man: The top program provides a dynamic real-time view of a running system. It can display system summary information as well as a list of processes or threads А опция H означает, что треды печаются отдельно, а НЕ суммируются внутри процесса: *H — Instructs top to display individual threads. Without this command-line option a summation of all threads in each process is shown. Later this can be changed with the `H’ interactive command.
@Sergey: да, каждая строчка это поток — всё что вы видите (каждая строчка в таблице) это потоки. Я тоже man процитировать могу: «top -H :Threads-mode operation Instructs top to display individual threads. Without this command-line option a summation of all threads in each process is shown.» [выделение моё]¶ Используйте \@-синтаксис, если хотите, чтобы мне уведомления о вашем комментарии приходили.
Вы как раз и процитировали то место, в котором говорится, что ооция -H показывать треды отдельно. Т.е. можно показывать треды внутри процесса-хозяина, а можно — отдельно. Но далеко не все процессы содержат треды. Процесс — первичен, а тред — вторичен.
@Sergey: каждый процесс содержит как минимум один поток, поэтому каждой строчке в таблице соответствует поток¶ У вас похоже проблемы с чтением как документации так и комментариев — даже после подсказки не способны \@-синтаксис использовать.
