В мультипроцессорной/ядерной системе thread scheduler отвечает за распределении процессорного времени между процессами.
JVM по-умолчанию пользуется услугами системного TS, линукс и виндоус работают по схеме преемптив мультизадачности.
У каждого процессора/ядра, есть свой планировщик, но для обобщения обычно говорят об одном.
Преемптив планировщик, карантирует, каким бы низким приоритетом не обладал поток и какие высокоприоритетные потоки не ожидали рядом с ним, он гарантированно получит доступ к выполнению.
Да, первыми идут на выполнение высокоприоритетные процессы, но все они работают не больше определенного в системе количества квантов времени - квант равняется нескольким тикам часов процессора/ядра. Если процесс отработал свой лимит он будет сохранен со своим контекстом(состоянием регистров и текущей точкой выполнения в стеке) и отправлен в конец(или в какое-то место другое - наверняка есть алгорит вычисления места в очереди на основании состояния ждущий и их приоритетов) очереди процессов на выполнение. И следующий процесс из очереди получит доступ к процессору/ядру.
У процессов есть неслько состояний: раннабл, вейтинг, нью - вейтинг процесс не получит доступ даже если подошла его очередь - он ожидает какое-то событие и это будет холостое переключение контекста.
События могут менять приоритет в очереди - если например пришло I/O событие, что запрошенные байты были прочитаны с переферии и могут быть получена с этого момент с памяти в регистры - так процесс пробудится в ближайший момент, но его приоритет резко увеличивается и он уже находится среди высокоприоритетных тредов.
Переключение контекста очень дорогая штука(в сравнение с временем в котором живет процессор) - поэтому нужно акуратно проектировать взаимодействие между процессами и уходить от частого переключение контекста.
JVM по-умолчанию пользуется услугами системного TS, линукс и виндоус работают по схеме преемптив мультизадачности.
У каждого процессора/ядра, есть свой планировщик, но для обобщения обычно говорят об одном.
Преемптив планировщик, карантирует, каким бы низким приоритетом не обладал поток и какие высокоприоритетные потоки не ожидали рядом с ним, он гарантированно получит доступ к выполнению.
Да, первыми идут на выполнение высокоприоритетные процессы, но все они работают не больше определенного в системе количества квантов времени - квант равняется нескольким тикам часов процессора/ядра. Если процесс отработал свой лимит он будет сохранен со своим контекстом(состоянием регистров и текущей точкой выполнения в стеке) и отправлен в конец(или в какое-то место другое - наверняка есть алгорит вычисления места в очереди на основании состояния ждущий и их приоритетов) очереди процессов на выполнение. И следующий процесс из очереди получит доступ к процессору/ядру.
У процессов есть неслько состояний: раннабл, вейтинг, нью - вейтинг процесс не получит доступ даже если подошла его очередь - он ожидает какое-то событие и это будет холостое переключение контекста.
События могут менять приоритет в очереди - если например пришло I/O событие, что запрошенные байты были прочитаны с переферии и могут быть получена с этого момент с памяти в регистры - так процесс пробудится в ближайший момент, но его приоритет резко увеличивается и он уже находится среди высокоприоритетных тредов.
Переключение контекста очень дорогая штука(в сравнение с временем в котором живет процессор) - поэтому нужно акуратно проектировать взаимодействие между процессами и уходить от частого переключение контекста.
Комментариев нет:
Отправить комментарий