Почему бы не пронизывать все?

Есть несколько очень полезных выгод для пронизывания; у нас может быть несколько процессов, бегущих сразу и несколько нитей, бегущих в рамках тех процессов. Так, со всей этой выгодой, почему мы только не используем новые ветви дискуссии для всех наших методов? Это не просто заставило бы все бежать быстро? Не действительно. Фактически, мы будем видеть в этой секции, которая как раз наоборот может произойти, если мы злоупотребляем пронизывание.

Мультипереплетенные заявления требуют ресурсов. Нити требуют, чтобы память сохранила местный нитью контейнер хранения. Как Вы можете предположить, число используемых
нитей ограничено доступным объемом памяти. Память довольно недорога в эти дни, у такого количества компьютеров есть большие объемы памяти. Однако, Вы не должны принимать это дело обстоит так. Если Вы запускаете свое приложение на неизвестной конфигурации аппаратных средств, Вы не можете предположить, что у Вашего заявления будет достаточно памяти. Дополнительно, Вы не можете предположить, что Ваш процесс будет единственным, порождающим нити и потребляющим системные ресурсы. Просто, потому что у машины есть большая память, не означает, что это - все для Вашего заявления.

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


Чтобы сделать это понятие легче понять, возьмите параллельный пример, который Вы найдете вниз в Вашем местном продуктовом магазине. Два кассира просматривают бакалею для своих клиентов. Однако, есть только один мешконасыпатель, кто сменяется, переключаясь между этими двумя кассирами. Мешконасыпатель довольно эффективен при скачке назад и вперед между двумя регистрами и укладыванием в мешки бакалеи, потому что они не накапливаются немного быстрее, чем мешконасыпатель может сложить бакалею в мешок. Однако, если еще два кассира откроют переулки, то станет очевидно, что мешконасыпатель проведет больше времени, подскакивая назад и вперед между регистрами, чем они тратят фактически висящую как мешок бакалею. В конечном счете магазин должен будет получить другой мешконасыпатель. В случае пронизывания думайте о кассирах как о заявлениях - или нити и мешконасыпатель как процессор. Процессор должен переключиться между нитями. Когда "нити" увеличиваются, продуктовый магазин должен добавить другой "процессор", чтобы быть уверенным, что клиенты привлекают внимание, в котором они нуждаются.

Фраза “слишком много нитей” является довольно общим обозначением - и справедливо так. Что составляет, "слишком многие" на одной системе могли быть прекрасными на другом. Так как конфигурации аппаратных средств в основном диктуют число нитей, доступных на системе, "слишком многие" - неисчислимая переменная без определенных деталей конфигурации и большого тестирования.

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