Существует множество решений, направленных на реализацию потоков в пользовательском пространстве.Будь то gorang.org goroutines, зеленые потоки python, асинхронность C #, процессы erlang и т. Д. Идея состоит в том, чтобы позволить параллельное программирование даже с одним или ограниченным числом потоков.
Это уровень абстракции.Многим людям легче понять эту концепцию и использовать ее более эффективно во многих сценариях.Это также проще для многих машин (при условии хорошей абстракции), так как во многих случаях модель перемещается от ширины к растяжению.С помощью pthreads (в качестве примера) у вас есть все управление.С другими моделями потоков идея состоит в том, чтобы повторно использовать потоки, чтобы процесс создания параллельной задачи был недорогим, и использовать совершенно другую модель потоков.Намного легче переварить эту модель;есть меньше, чтобы учиться и измерять, и результаты, как правило, хорошие.
Чего я не понимаю, так это то, почему потоки ОС так дороги?На мой взгляд, в любом случае вам нужно сохранить стек задачи (поток ОС или поток пользовательского пространства), который составляет несколько десятков килобайт, и вам нужен планировщик для перемещения между двумя задачами.
Создание потока стоит дорого, а стеку требуется память.Кроме того, если ваш процесс использует много потоков, переключение контекста может снизить производительность.Таким образом, легкие модели потоков стали полезными по ряду причин.Создание потока ОС стало хорошим решением для средних и больших задач, в идеале в небольших количествах.Это ограничительно и требует много времени для обслуживания.
Поток задач / пул / пользовательский поток не должен беспокоиться о переключении контекста или создании потока.Он часто «повторно использует ресурс, когда он становится доступным, если он еще не готов, а также определяет количество активных потоков для этой машины».
Более общеизвестно (IMO), потоки уровня ОС дороги, потому что онине используются корректно инженерами - либо их слишком много, либо переключение контекста на тонну, либо конкуренция за тот же набор ресурсов, либо задачи слишком малы.Требуется намного больше времени, чтобы понять, как правильно использовать потоки ОС и как наилучшим образом применять их в контексте выполнения программы.
ОС предоставляет обе эти функции бесплатно.
Они доступны, но они не бесплатны.Они сложны и очень важны для хорошей производительности.Когда вы создаете поток ОС, ему дается время «скоро» - все время процесса делится между потоками.Это не частый случай с пользовательскими потоками.Задача часто ставится в очередь, когда ресурс недоступен.Это уменьшает переключение контекста, память и общее количество потоков, которые должны быть созданы.Когда задача завершается, поток получает другой.
Рассмотрим эту аналогию распределения времени:
- Предположим, вы находитесь в казино.Есть ряд людей, которым нужны карты.
- У вас есть фиксированное количество дилеров.Дилеров меньше, чем людей, которым нужны карты.
- Не всегда достаточно карт для каждого человека в любой момент времени.
- Людям нужны все карты для завершения своей игры / руки.Они возвращают свои карты дилеру, когда их игра / рука завершена.
Как бы вы попросили дилеров раздавать карты?
В планировщике ОС это будет основано на(поток) приоритет.Каждому человеку будет даваться одна карта за раз (время ЦП), и приоритет будет оцениваться непрерывно.
Люди представляют задачу или работу потока.Карты представляют время и ресурсы.Дилеры представляют темы и ресурсы.
Как бы вы справились быстрее, если бы было 2 дилера и 3 человека?а если было 5 дилеров и 500 человек?Как вы могли бы минимизировать нехватку карт для раздачи?С помощью потоков добавление карт и добавление дилеров - это не решение, которое вы можете предложить «по требованию».Добавление процессоров эквивалентно добавлению дилеров.Добавление потоков эквивалентно тому, что дилеры раздают карты одновременно большему количеству людей (увеличивает переключение контекста).Существует ряд стратегий для более быстрого раздачи карт, особенно после того, как вы избавитесь от потребности людей в картах за определенное время.Разве не было бы быстрее подойти к столу и заключить сделку с человеком или людьми, пока их игра не будет завершена, если соотношение дилера и людей будет 1/50?Сравните это с посещением каждой таблицы в зависимости от приоритета и координацией посещения всех дилеров (подход ОС).Это не означает, что ОС глупа - это означает, что создание потока ОС - это инженер, добавляющий больше людей и больше таблиц, потенциально больше, чем разумно могут обработать дилеры.К счастью, ограничения могут быть сняты во многих случаях с помощью других моделей многопоточности и более высоких абстракций.
Почему потоки ОС должны быть дороже, чем "зеленые" потоки?В чем причина предполагаемого снижения производительности, связанного с выделением отдельного потока ОС для каждой «задачи»?
Если бы вы разработали критичную по производительности библиотеку потоков низкого уровня (например, для pthreads), вы бы узналиважность повторного использования (и реализовать его в своей библиотеке в качестве модели, доступной для пользователей).С этой точки зрения важность моделей многопоточности более высокого уровня - это простое и очевидное решение / оптимизация, основанная на использовании в реальном мире, а также идеал, что полоса входа для принятия и эффективного использования многопоточности может быть снижена.
Этоне то, чтобы они были дорогими - модель и пул облегченных потоков - лучшее решение для многих проблем и более подходящая абстракция для инженеров, которые плохо понимают потоки.Сложность многопоточности значительно упрощена (и часто более производительна в реальном мире) в этой модели.С потоками ОС у вас больше контроля, но необходимо сделать еще несколько соображений, чтобы использовать их как можно более эффективно - учет этих соображений может существенно изменить исполнение / реализацию программы.При использовании абстракций более высокого уровня многие из этих сложностей сводятся к минимуму путем полного изменения последовательности выполнения задач (ширина по сравнению с натяжением).