Благодарю за ответ! Формулы эти я просто для себя писал, чтоб хоть какую-то модель в голове построить.
Отдельное спасибо за то, что подсветили и другие возможные проблемы. Оказывается, то, о чем я писал в вопросе - всего лишь одно из возможных последствий.
Saboteur, это ясное дело) Тут вопрос именно в планировании. Хотелось понять, что все-таки реально планирует ОС и откуда подгружает инструкции для выполнения. Судя из ответов, она планирует именно потоки, ну а процессы - действительно некоторые контейнеры, адресное пространство и другие ресурсы которого разделяют потоки. Хотя, признаться, мне все еще кажется, что я не полностью пониманию всю полезность и важность процессов. Неужто только для группировки потоков и предоставления им адресного пространства?
Justa Gain, я знаю, что это разные абстракции. Тут речь вовсе не об ЯП, а об абстракциях ОС. ЯП тут мало фигурируют. И это никак не поясняет, почему ты снова сказал, что я смешал все в кучу.
Я знаю, что у каждого потока свои instruction pointer и значения регистров, но в разных источниках пишут также то, что на скрине выше. Из-за этого возникает некоторая путаница с пониманием назначения потоков и процессах. Во многих лекциях и статья так вообще через слеш пишут - "когда ОС планирует поток/процесс..", что-то вроде такого.
И можете, пожалуйста, привести хотя бы один небольшой пример, где замешаны процессы? Например, небольшой пример, как ОС использует этот учет ресурсов?
Justa Gain, объясни конкретно, что именно я смешал? Разве возможно это полностью разделить и изолировать друг от друга? Я не системный программист, я занимаюсь бэкендом, но мне просто интересно понять, построить хотя бы упрощенную модель, которая передаст суть и основные принципы работы ОС и планировщика.
Я не думаю, что смешал все в кучу, ведь все взаимосвязано. Разве не ОС занимается управлением ресурсов системы (ЦП, память, периферия и др.)? Ты лучше бы с высоты своих знаний не насмехался над вопросами, а помог бы разобраться и сделал коммьюнити чуть лучше. Пока что я вижу, что ты только и можешь задавать этот свой вопрос)
Vamp, огромное спасибо, прям внесли ясность) Я почитал, все-таки в Python для каждого потока создается именно нативный поток, управляемый ОС. Истинного параллелизма в Python нет потому, что присутствует механизм GIL - глобальный блокировщик интерпретатора. Я смотрел англоязычную лекцию на ютубе, и там прям говорилось, что GIL контролирует не то, когда засыпать потокам, а то, когда им просыпаться.
При запуске .py-файла запускается однопоточный процесс, в котором запускается Сишная функция main, которая работает в 3 шага:
Инициализация интерпретатора
Компилирование Python-кода в платформонезависимый байт-код
Бесконечный цикл с гигантским switch'ем всех возможных байт-код инструкций
И вот допустим у нас есть два потока. ОС выполняет сразу два потока параллельно, но один из потоков действительно выполняется и делает полезную работу, а другой поток (помним, что мы находимся в моменте, когда работает два потока одновременно, ОС так решила) тоже выполняется, но он каждые несколько миллисекунд (зависит от настройки интерпретатора) пытается захватить GIL. И вот если GIL захвачен и установленное интерпретатором время еще не вышло, действительно работающий поток не отдает GIL, а когда время выходит, GIL захватывает другой поток и так по кругу.
Эта проверка в потоках, которые как бы работают на процессоре, но Python не позволяет им заниматься обработкой Python-переменных, выполняется в том самом бесконечном цикле перед switch'ем. Конечно, потоки работают не всегда, т.к. пока работает основной поток, операционная система может второй поток уже усыпить и разбудить несколько раз. Однако если время пробуждения, установленное в интерпретаторе, еще не вышло, этот поток так и будет пытаться захватить GIL.
Еще раз большое Вам спасибо за столь подробный и терпеливый ответ)
P.S. Опять же, это связано именно с CPU-bound задачами. В I/O-bound задач Python-потоки реально могут работать параллельно, т.к. на блокирующих системных вызовах поток отпускает, а после выполнения операции снова захватывает GIL. То же самое и на тяжелых CPU-bound задач с помощью вызовов Си-функций. С этим я пока еще не разобрался.
Прошу прощения, надо бы мне снова взять в привычку все ссылки сразу упорядочивать..
Смог найти только такую схему
Здесь в принципе и отражено то, что я имел в виду. Использование только зеленых потоков, сопоставление каждому зеленому потоку поток я пространстве ядра и комбинированный подход.
А подскажите пожалуйста насчет userspace-потоков. Я в одной статье читал, что иногда таким потокам может сопоставляться kernelspace-поток. И также в той статье было сказано, что (здесь могу неточно выразиться) userspace-потоки не могут выполняться на разных ядрах, т.к. (вроде бы) у них нет контекста, а вот kernelspace-потоки - могут. Можете этот момент подробнее рассказать?
Это самый лучший ответ, спасибо большое, что так подробно разжевали все) После просмотра небольшого курса по архитектуре ОС Ваш ответ еще больше мне раскрыл глаза, как все устроено на самом деле.
Большое Вам спасибо, хороший ответ! Теперь появилась какая-то устойчивая базовая картина и отправная точка для дальнейшего исследования. То, что я и хотел, в целом :)
hint000, спасибо, что объяснили "на пальцах", стало попонятнее немного) Насчет бреда, почему же. Что плохого, что у меня на данный момент нет полных знаний? Тем более это не моя профильная область, мне просто хочется понять чуть лучше внутреннее устройства ОС и принципы работы ЦП. Вопросы задавал в силу своего (не)понимания.
Евгений Шатунов, большое спасибо за план и за книгу! Поизучаю. Насчет каши, ну, вероятно вы правы) Затем и обратился к знающим людям, чтоб эту кашу помогли переварить)
Юрий, я понимаю, я его упомянул лишь из-за библиотеки threading, т.к. в одной из статей сказано, что такие библиотеки и позволяют создавать kernelspace-потоки, либо я что-то не так понял. На асинхронность.. почему же, все равно ведь этот подход базируется на неблокирующих I/O-операциях, делегируя чтение/запись как раз-таки ядру, что и позволяет асинхронному Python-коду заниматься выполнением других полезных задач, разве нет?
mayton2019, спасибо за комментарий! Да, я знаю, что довольно много сомнительных формулировок. Попытался максимально точно описать то, как я все это понял.
Как только kernel (thread) обращатеся к памяти или к внешним устройствам - тут нет никакого параллелизма.
Становимся в ожидание пока устройство ответит.
Но ведь это в рамках одного ядра, верно? Другие ядра могут совершать другие действия параллельно относительно друг друга, разве нет?
Justa Gain, в кучу я ничего не мешал, просто пытаюсь собрать общую картину происходящего. Это не разные вопросы, а подвопросы по одной теме. Вопрос обширный, я лишь указал пробелы в своих знаниях.
