Как я могу иметь 1805 потоков, когда у меня только 4 виртуальных процессора?


10

Мне было интересно, если кто-то может объяснить мне, как в моем мониторе активности он говорит, что у меня в настоящее время 1805 потоков Снимок экрана OS X Activity Monitor

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

РЕДАКТИРОВАТЬ: причина, по которой я думаю, что на моей машине может быть только 4 потока, вытекает из этого ответа . Я считаю, что мое недоразумение связано с тем, что слово «нить» используется в другом контексте.


Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
bmike

Ответы:


24

планирование

Ваши 1805 потоков не работают одновременно . Они обмениваются. Одно ядро ​​запускает часть потока, а затем откладывает его для выполнения части другого потока. Другие ядра делают то же самое. Круглые и круглые потоки выполняются постепенно, а не все сразу.

Основная ответственность операционной системы (Darwin и macOS) - это планирование того, какой поток должен выполняться на каком ядре и как долго.

У многих потоков нет работы, поэтому они остаются бездействующими и незапланированными. Аналогично, многие потоки могут ожидать некоторого ресурса, такого как данные, которые будут извлечены из хранилища, или сетевое соединение, которое должно быть завершено, или данные, которые будут загружены из базы данных. Практически ничего не делая, кроме проверки состояния ожидаемого ресурса, такие потоки планируются довольно кратко, если вообще.

Программист приложения может помочь в этой операции планирования, спя ее поток на определенное время, когда он знает, что ожидание внешнего ресурса займет некоторое время. И если выполняется «жесткий» цикл, который требует интенсивной загрузки ЦП и не требует ожидания на внешних ресурсах, программист может вставить вызов добровольцу, чтобы ненадолго отложить его, чтобы не перегружать ядро ​​и тем самым позволить другим потокам выполняться.

Для более подробной информации, смотрите страницу Википедии для многопоточности .

Одновременная многопоточность

Что касается вашего связанного вопроса , темы там действительно такие же, как здесь.

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

Некоторые производители процессоров разработали технологию, позволяющую сократить это время, чтобы значительно ускорить переключение между двумя потоками. Intel называет свою технологию Hyper-Threading . Известен как одновременная многопоточность (SMT) .

Хотя пара потоков фактически не выполняется одновременно, переключение происходит настолько плавно и быстро, что оба потока кажутся практически одновременными. Это работает так хорошо, что каждое ядро ​​представляет собой пару виртуальных ядер для ОС. Так, например, центральный процессор с поддержкой SMT с четырьмя физическими ядрами будет представлен ОС как восьмиъядерный процессор.

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

Таким образом, в микропрограмме ЦП есть опция, при которой системный администратор может включить переключатель на машине, чтобы отключить SMT, если она решит, что это принесет пользу ее пользователям, работающим с приложением, которое необычно связано с ЦП и имеет очень мало возможностей для приостановки.

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


Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
bmike

Кроме того, никто не помещает yield()системные вызовы в свои потоки, интенсивно использующие процессор (если это не устаревший код от совместной многозадачности на классических MacOS). Упреждающее многозадачное расписание перепланируется после того, как поток использует свой временной интервал.
Питер Кордес

Ваше описание гиперпоточности неверно. Аппаратные потоки! = Программные потоки, это контексты выполнения / логические ядра. Оба логических ядра на физическом ядре действительно выполняют свои инструкции одновременно. Внешний интерфейс чередуется между потоками (каждый цикл), но ядро ​​выполнения вне очереди может выполнять инструкции / мопы из обоих потоков в одном и том же цикле. Это подвергает параллелизм на уровне команд от двух потоков выполнению OoO, чтобы лучше поддерживать исполнительные блоки загруженными работой (это в основном точка SMT). Это не просто «оптимизированное переключение контекста».
Питер Кордес


7

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

введите описание изображения здесь

Теперь - из-за разницы во времени - процессор и кэш работают так быстро по сравнению с получением данных из хранилища или сети - что тысячи потоков могут приходить и уходить, пока один поток ожидает, пока www.google.com доставит пакет или два данных, поэтому вы видите гораздо больше потоков, чем фактический процессор.

Если вы преобразуете операции с потоками, которые выполняются в черно-синей шкале времени, и конвертируете их в одну секунду = 1 нс, то, что нас волнует, больше похоже на дисковый ввод-вывод, то 100 микросекунд равны 4 дням, а двусторонняя передача в Интернет за 200 мс - это 20-летняя задержка, если считать секунды на шкале времени процессора. Как и многие из десяти упражнений , почти во всех случаях - процессор простаивает в течение «месяцев» в ожидании значимой работы из очень, очень медленного внешнего мира.

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

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


Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
bmike

1

Вы не задаете, возможно, более фундаментальный вопрос: «Как я могу иметь 290 процессов, когда мой процессор имеет только четыре ядра?» Этот ответ - немного истории, которая может помочь вам понять общую картину, даже если на конкретный вопрос уже дан ответ. Таким образом, я не собираюсь давать версию TL; DR.

Когда-то давно (вспомним, 1950–60-е годы) компьютеры могли делать только одно за раз. Они были очень дорогими, занимали целые комнаты, и нам нужен был способ их эффективного использования, разделяя их между несколькими людьми. Первым способом сделать это была пакетная обработка , при которой пользователи отправляли задачи на компьютер, и их ставили в очередь, выполняли одну за другой, а результаты отправляли обратно пользователю. Это было нормально, но это означало, что, если вы хотите сделать расчет, который займет пару дней, никто другой не сможет использовать компьютер в течение этого времени.

Следующим нововведением (вспомним, 1960–70-е годы) стало разделение времени . Теперь вместо выполнения всей одной задачи, а затем всей следующей, компьютер будет выполнять часть одной задачи, затем приостанавливать ее и выполнять следующую часть, и так далее. Таким образом, у компьютера создается впечатление, что он выполняет несколько процессов одновременно. Большим преимуществом этого является то, что теперь вы можете запускать вычисления, которые займут несколько дней, и, хотя теперь это займет еще больше времени, поскольку он продолжает прерываться, другие люди все еще могут использовать машину в течение этого времени.

Все это было для огромных компьютеров в стиле мэйнфреймов. Когда персональные компьютеры начали становиться популярными, они изначально были не очень мощными и, эй, поскольку они были личными, для них казалось нормальным, что они могут выполнять только одну вещь - запускать одно приложение - сразу (вспомним, 1980-е). Но по мере того, как они становились все более влиятельными (представьте, 1990-е годы), люди хотели, чтобы их персональные компьютеры тоже делили время.

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.