@R71MT

Тут зависит от того, какое это ядро..
Потоками управляет только компилятор, для чего предусмотрена API-функция CreateThread. Возвращённый ею дескриптор наследуют все дочерние процессы (если таковые имеются), а сам поток выполняется только в виртуальной памяти родительского процесса. То есть потоки порождает процесс, а у каждого процесса свой стек и свои регистры.

Любой поток выполняется только на одном конвейере ядра, и не может выполнятся на другом конвейере по простым причинам - процессор не сможет контролировать разные участки одной программы, т.е. не сможет обеспечить поддержку когерентности потока. В наше время зоопарк процессоров имеет такой вид, и на вход каждого из конвейеров 'Pipeline' приходит один софтовый поток:



Инструкции выполняются с предварительной их загрузкой в кэш - беспорядочно. Для этого в ядре процессора имеется блок переименования регистров 'Registers-Rename', который расширяет фактическое кол-во регистров(РОН) процессора до 256 и более штук. Это позволяет конвейеру предварительно выполнять поток инструкций не дожидаясь, когда освободится тот-или-иной регистр. На выходе из конвейера инструкции опять выстраиваются в первоначальную очередь (см.рис.ниже).

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

На данный момент потоками управляет компилятор через дескриптор, возвращённый функцией CreateThread. По этому дескриптору, внутри конвейера потоки разделяются и выполняются каждый на своей линии примерно по такой схеме:



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

При запуске файла на исполнение, системный загрузчик считывает только "заголовок исполняемого РЕ-файла", остальная часть дискового файла логически разбивается на страницы, которые подгружаются динамически, по исключению 'Page-Fault'. Системному диспетчеру памяти вообще фиолетово, что именно находится внутри этой страницы - его дело только загрузить затребованную страницу с диска в память. Система не исполняет код страниц, поэтому физически не может определить, поток там или ещё-чёрт-знает что - этим занимается процессор, а заставляет его это делать компилятор, по дескриптору 'CreateThread'.

Вернуться к обсуждению:
Как система распределяет нагрузку по потокам ? Процессоры

1