Контекстные коммутаторы для спальных/ожидающих потоков

Question

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

В одном запросе на модель потока, скажем, веб-приложение на основе сервлета 2.5, если 499 потоков ждут ввода-вывода базы данных, и только один поток нуждается в работе, переключается ли контекст ОС между всеми этими 500 потоками, пытаясь найти тот, который нуждается в работе? Для выполнения контекстного переключателя операционная система должна сохранять состояние текущего потока и восстанавливать состояние следующего потока. После этого ОС обнаружит, что ему не требуется никакого времени процессора, и будет поддерживать контекстное переключение до тех пор, пока не найдет поток, который нуждается в работе. Также, как это выглядит с точки зрения использования сервера? Является ли процессор низким, поскольку он в основном просто связан с затратами на обмен информацией об обмене контекстами внутри и снаружи, а не фактически что-то вычисляет?

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

Answer 1

если 499 потоки ожидают базы данных ввода-вывода, и только один поток должен работу, делает переключение контекста OS между всеми этими 500 потоков пытаются найти тот, который нуждается в работе?

Нет, если планировщик ОС имеет разумную конструкцию; итерация по всем потокам системы все время была бы ужасно неэффективной.

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

Если ЦПУ низкий, поскольку он в основном связан только с затратами на обмен в контекстами и выходами вместо того, чтобы фактически что-то делать?

Предполагая, что вы не исчерпали ОЗУ, нет ввода-вывода, задействованного в переключении контекстов потоков; контекстная коммутация включает только CPU и RAM. Если использование ЦП низкое, наиболее вероятной причиной является то, что сами алгоритмы ваших потоков связаны с привязкой ввода/вывода (например, большинство из них на вашей сетевой карте или жестком диске ждет, чтобы читать или писать данные в большинстве случаев). Если ваши потоки на самом деле не делают никаких операций ввода-вывода, и вы все еще связаны с I/O, это может быть признаком того, что ваш компьютер исчерпал всю доступную оперативную память и составляет thrashing - не хорошее состояние