1 процесс (1 запущенное приложение) может содержать 1 и более кол-во потоков. поток != процесс. потоки можно паралелить в пределах процессоров. для выполнения одновременно 2х приложений, нужно переключать контексты, что приводит к задержкам.
не нужно путать тёплое с мягким.
Точно.
Чтобы гарантированно не запутаться, нужно определить термины.
Давай подробно всё распишем:
- Процесс для ОС - это набор ресурсов, как то память, список привязанных процессоров (как минимум 1), список выполняющихся потоков (как минимум 1), объекты синхронизации, файлы/внешние устройста. Возможны ещё разные ресурсы, типа оконных и ресурсных дескрипторов в винде и других ресурсов разных АПИ.
- Поток для ОС - это набор комманд процессора + набор регистров + стек + доп.память потока. Так же возможны дополнительные ресурсы ОС и библиотек.
- Объекты синхронизации - всяческие симофоры, мютексы, условные переменные. Так же часто файлы и устройства могут являтся явными или неявными объектами синхронизации.
- Диспетчер выполнения (планировщик) - подсистема в ОС, которая распределяет время выполнения потоков на процессорах с учётом объектов синхронизации.
В каждом процессе должен быть хотя бы один поток - главный.
При запуске процесса ОС выделяет нужные процессу и главному потоку ресурсы и запускает на выполнение главный поток.
Главный поток, во время выполнения, явно или не явно, создаёт нужное количество вторичных потоков, которые тоже, в свою очередь, тоже могут создавать потоки.
Потоки, явно или не явно используют объекты синхронизации для синхронизации.
Диспетчер выполнения следит за тем, чтобы всем потокам в системе досталось нужное количество времени.
Как это происходит:
- При активизации менеджера он проверяет должен ли текущий поток выполнятся дальше.
- Если нет - поток ставится в ожидание (засыпает), и время процессора отдаётся другим претендентам.
Каким же образом активизируется диспетчер?
Видятся основных 3 варианта:
- Каждый поток явно отдаёт управление диспетчеру.
- По таймеру или событию от внешнего устройства прерывается текуший поток и выполнение переключается на поток диспетчера.
- Поток диспетчера выполняется на отдельном процессоре. Когда он решает, что текущему потоку на другом проце пора отдахнуть - он его останавливает.
Первый вариант называется «кооперативная многозадачность». Она применялась в Win3.x, Nowell Netware, DOS Tsr, и различных Дос расширителях.
Кроме того, при запуске потока posix thread его можно сконфигурировать на похожий такой режим; так же есть Fiber-ы в WinApi. В этих 2х случаях дочерние кооперативные потоки выполняются в рамках запустившего обычного.
Второй вариант интереснее. Что происходит в момент
прерывания потока для пункта 2.
Процессор сохраняет все текущие регистры в доп. память текущего потока и переключается на выполнение потока диспетчера, восстанавливая значение регистров из его доп.памяти. Так же тут происходят сбросы кешей - ведь их значения бессмысленны для другого потока.
Вот мы и добрались до того самого «долгого сохранения/восстановления».
В варианте 3
остановка и возобновление потока происходит практически так же.
А теперь, сможешь описать где именно получает выигрыш виртуальная машина Java (JVM) при многозадачности?
В каком месте она оптимизирует работу по сохранению/восстановлению регистров и сбросу кешей?
Ну, или можешь описать самостоятельно всю механику указав где ошибочно моё описание.
П. С. Я не расписывал управление приоритетами и работу с объектами синхронизации - это влияет на стратегию выбора диспетчером какие процессы должны заснуть/проснутся, но не на сам механизм засыпания/просыпания.