Работают ли потоки из нескольких процессов одновременно - PullRequest
3 голосов
/ 04 июня 2010

В операционной системе Windows с 2 физическими процессорами x86 / amd64 (P0 + P1), запущенными 2 процессами (A + B), каждый с двумя потоками (T0 + T1), можно (или даже часто) увидеть следующее:

P0:A:T0 работает одновременно с P1:B:T0

затем, после 1 (или это 2?) Переключения контекста (es?)

P0:B:T1 работает одновременно с P1:A:T1

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

EDIT: Чтобы прояснить глупый пример, представьте, что поток A процесса A: T0 имеет сродство с процессором P0 (и A: T1 к P1), а поток B: T0 процесса B имеет сродство с процессором P1 (и B: T1 к P0). Вероятно, не имеет значения, являются ли эти процессоры ядрами или сокетами.

Существует ли первоклассная концепция переключения контекста процесса? Perfmon показывает переключение контекста под объектом Thread, но не под объектом Process.

Ответы [ 2 ]

6 голосов
/ 04 июня 2010

Да, это возможно, и это случается довольно часто.ОС пытается не переключать один поток между процессорами (вы можете сделать это более сложным, установив потоки предпочтительный процессор , или вы можете даже привязать его к одному процессору через привязку).Процесс Windows сам по себе не является исполнительной единицей - с этой точки зрения он в основном просто контекст для своих потоков.

РЕДАКТИРОВАТЬ (дальнейшие пояснения)

Ничего подобного«переключение контекста процесса».По сути, планировщик ОС назначает потоки с помощью (очень адаптивного) алгоритма циклического перебора любому свободному процессору / ядру (как позволяет сродство), если «предыдущий» процессор не доступен сразу, независимо от процессов (что означаетмногопоточные процессы могут украсть гораздо больше ресурсов процессора).

Этот «скачок» может показаться дорогим, учитывая, что по крайней мере кэши L1 (а иногда и L2) относятся к ядру (кроме разных процессоров слотов / пакетов), но это все же дешевле, чем задержки, вызванные ожиданием «правильного» процессора и неспособностью выполнить сложную балансировку нагрузки (что делает возможной схема «прыжков»).Это может не применяться к архитектуре NUMA, но при этом учитывается гораздо больше соображений (например, адаптация всех выделений памяти для привязки к потокам - и и избегание как можно большего количества состояния / памятисовместное использование по возможности).

Что касается сходства: вы можете установить маски сходства для каждого потока или для каждого процесса (который заменяет параметры всех потоков процесса), но ОС применяет как минимум один логический процессор, связанный с потоком (вы никогда не получат нулевую маску).

Маска сходства процесса по умолчанию наследуется от его родительского процесса (что позволяет создавать одноядерные загрузчики).для проблемных устаревших исполняемых файлов) и потоки наследуют маску от процесса, которому они принадлежат.

Вы можете , а не установить привязку потоков к процессору за пределами привязки процесса, но вы можете дополнительно ограничить его.

Любой поток с помощьюпо умолчанию будет переходить между доступными логическими процессорами (особенно если это приводит к выходу, вызовам ядра и т. д.), может переходить, даже еслидля него установлен предпочтительный процессор , но только если это необходимо, но он НЕ перейдет к процессору за пределами маски сродства (что может привести к значительнымзадержки).

Я не уверен, видит ли планировщик какую-либо разницу между физическим и гиперпоточным процессорами, но даже если это не так (что я предполагаю), последствия в большинстве случаев непроблема, то есть не должна быть значительной разницей между несколькими потоками, совместно использующими физические или логические процессоры, если число потоков точно такое же.Несмотря на это, есть некоторые сообщения о перегрузке кеша в этом сценарии, в основном в высокопроизводительных многопоточных приложениях, таких как SQL-сервер или виртуальные машины .NET и Java, которые могут или не могутВыгода от использования HyperThreading отключена.

2 голосов
/ 05 июня 2010

Я в целом согласен с предыдущим ответом, однако все сложнее.

Хотя процессы не являются исполнительными блоками, потоки, принадлежащие одному и тому же процессу , должны обрабатываться по-разному. Для этого есть две причины:

  1. То же адресное пространство. Значит - при переключении контекста между такими потоками нет необходимости настраивать регистры преобразования адресов.
  2. Потоки одного и того же процесса гораздо чаще обращаются к одной и той же памяти.

(2) оказывает большое влияние на состояние кэша. Если потоки читают одну и ту же ячейку памяти - они повторно используют кэш L2, следовательно, все ускоряется. Однако есть и недостаток: когда поток изменяет расположение в памяти - этот адрес становится недействительным как в кеше L2, так и в кеше L2 обоих процессоров, так что другой процессор также делает недействительным свой кэш.

Так что есть плюсы и минусы в одновременном запуске потоков одного и того же процесса (на разных процессорах). Кстати, у этой ситуации есть название: «Gang scheduling».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...