В вычислениях переключение контекста — это процесс сохранения состояния процесса или потока , чтобы его можно было восстановить и возобновить выполнение в более поздней точке, а затем восстановить другое, ранее сохраненное состояние. [1] Это позволяет нескольким процессам совместно использовать один центральный процессор (ЦП) и является важной особенностью многопрограммной или многозадачной операционной системы . В традиционном ЦП каждый процесс (исполняемая программа) использует различные регистры ЦП для хранения данных и текущего состояния выполняющегося процесса. Однако в многозадачной операционной системе операционная система переключается между процессами или потоками, чтобы обеспечить одновременное выполнение нескольких процессов. Для каждого переключения операционная система должна сохранить состояние текущего процесса, а затем загрузить состояние следующего процесса, который будет выполняться в ЦП. Эта последовательность операций, которая сохраняет состояние запущенного процесса и загрузку следующего запущенного процесса, называется переключением контекста.
Точное значение фразы «переключение контекста» варьируется. В контексте многозадачности это относится к процессу сохранения состояния системы для одной задачи, чтобы задачу можно было приостановить и возобновить другую задачу. Переключение контекста также может произойти в результате прерывания , например, когда задаче требуется доступ к дисковому хранилищу , освобождая время ЦП для других задач. В некоторых операционных системах также требуется переключение контекста для переключения между задачами пользовательского режима и режима ядра . Процесс переключения контекста может оказать негативное влияние на производительность системы. [2] : 28
Переключение контекста обычно требует больших вычислительных ресурсов, и большая часть конструкции операционных систем направлена на оптимизацию использования переключателей контекста. Переключение с одного процесса на другой требует определенного времени на администрирование — сохранение и загрузку регистров и карт памяти, обновление различных таблиц и списков и т. д. Что на самом деле происходит при переключении контекста, зависит от архитектуры, операционной системы и количество общих ресурсов (потоки, принадлежащие одному и тому же процессу, совместно используют много ресурсов по сравнению с несвязанными несотрудничающими процессами).
Например, в ядре Linux переключение контекста предполагает загрузку соответствующего блока управления процессом (PCB), хранящегося в таблице PCB в стеке ядра, для получения информации о состоянии нового процесса. Информация о состоянии ЦП, включая регистры, указатель стека и счетчик программ , а также информация управления памятью, такая как таблицы сегментации и таблицы страниц (если старый процесс не использует память совместно с новым), загружаются из печатной платы для нового процесса. Чтобы избежать неправильной трансляции адресов в случае, когда предыдущий и текущий процессы используют разную память, резервный буфер трансляции (TLB) должен быть очищен. Это отрицательно влияет на производительность, поскольку каждая ссылка на TLB в памяти будет пропущена, поскольку после большинства переключений контекста он пуст. [3] [4]
Более того, аналогичное переключение контекста происходит между пользовательскими потоками , особенно зелеными потоками , и часто является очень легким, сохраняя и восстанавливая минимальный контекст. В крайних случаях, таких как переключение между горутинами в Go , переключение контекста эквивалентно выходу сопрограммы , что лишь незначительно дороже, чем вызов подпрограммы .
Существует три потенциальных триггера переключения контекста:
Чаще всего в рамках некоторой схемы планирования один процесс должен быть отключен от ЦП, чтобы мог работать другой процесс. Это переключение контекста может быть вызвано тем, что процесс становится невыполнимым, например, в результате ожидания завершения операции ввода-вывода или синхронизации . В системе с вытесняющей многозадачностью планировщик также может отключать процессы, которые все еще могут выполняться. Чтобы предотвратить нехватку процессорного времени другими процессами, упреждающие планировщики часто настраивают прерывание таймера на срабатывание, когда процесс превышает свой интервал времени . Это прерывание гарантирует, что планировщик получит контроль над переключением контекста.
Современные архитектуры управляются прерываниями . Это означает, что если ЦП запрашивает данные, например, с диска, ему не нужно ждать, пока чтение закончится; он может отправить запрос (устройству ввода-вывода) и продолжить выполнение другой задачи. Когда чтение завершено, процессор может быть прерван (в данном случае аппаратным обеспечением, которое отправляет запрос прерывания на PIC ) и предоставить чтение. Для прерываний устанавливается программа, называемая обработчиком прерываний , и именно обработчик прерываний обрабатывает прерывание с диска.
Когда происходит прерывание, аппаратное обеспечение автоматически переключает часть контекста (по крайней мере, достаточно, чтобы позволить обработчику вернуться к прерванному коду). Обработчик может сохранять дополнительный контекст, в зависимости от деталей конкретного аппаратного и программного обеспечения. Часто меняется лишь минимальная часть контекста, чтобы минимизировать время, затрачиваемое на обработку прерывания. Ядро не создает и не планирует специальный процесс для обработки прерываний, вместо этого обработчик выполняется в контексте (часто частичном), установленном в начале обработки прерывания . После завершения обслуживания прерывания контекст, действовавший до возникновения прерывания, восстанавливается, так что прерванный процесс может возобновить выполнение в своем надлежащем состоянии.
Когда система переходит из пользовательского режима в режим ядра , переключение контекста не требуется; смена режима сама по себе не является переключением контекста. Однако в зависимости от операционной системы в это время также может произойти переключение контекста.
Состояние текущего выполняющегося процесса должно быть сохранено, чтобы его можно было восстановить при перепланировании выполнения.
Состояние процесса включает в себя все регистры, которые может использовать процесс, особенно счетчик программ , а также любые другие данные, специфичные для операционной системы, которые могут потребоваться. Обычно это хранится в структуре данных, называемой блоком управления процессом (PCB) или коммутатором .
Плата может храниться в стеке каждого процесса в памяти ядра (в отличие от стека вызовов пользовательского режима ), или для этой информации может существовать некоторая определенная операционной системой структура данных. Дескриптор платы добавляется в очередь процессов, готовых к запуску, часто называемую очередью готовности .
Поскольку операционная система фактически приостановила выполнение одного процесса, она может затем переключить контекст, выбрав процесс из очереди готовности и восстановив его плату. При этом счетчик программ с платы загружается, и, таким образом, выполнение может продолжаться в выбранном процессе. Приоритет процесса и потока может влиять на то, какой процесс будет выбран из очереди готовности (т. е. это может быть приоритетная очередь ).
Рассматривая общую арифметическую операцию сложения A = B+1. Команда сохраняется в регистре команд , а счетчик программы увеличивается. A и B считываются из памяти и сохраняются в регистрах R1, R2 соответственно. В этом случае вычисляется B+1 и записывается в R1 как окончательный ответ. Эта операция, поскольку выполняется последовательное чтение и запись и не используется ожидание вызовов функций , поэтому в этом случае не происходит переключения/ожидания контекста.
Однако для некоторых специальных инструкций требуются системные вызовы , требующие переключения контекста для процессов ожидания/засыпания. Обработчик системных вызовов используется для переключения контекста в режим ядра . Функция display(data x) может потребовать данные x с диска и драйвер устройства в режиме ядра, поэтому функция display() переходит в спящий режим и ожидает операции READ, чтобы получить значение x с диска , в результате чего программа для ожидания и ожидания вызова функции для освобожденной настройки текущего оператора, чтобы перейти в спящий режим, и дождаться, пока системный вызов разбудит его. Однако для поддержания параллелизма программе необходимо снова повторно выполнить новое значение и спящий процесс.
Само по себе переключение контекста снижает производительность из-за запуска планировщика задач , очистки TLB и косвенно из-за совместного использования кэша ЦП между несколькими задачами. [5] Переключение между потоками одного процесса может происходить быстрее, чем между двумя отдельными процессами, поскольку потоки используют одни и те же карты виртуальной памяти , поэтому очистка TLB не требуется. [6]
Время переключения между двумя отдельными процессами называется задержкой переключения процессов . Время переключения между двумя потоками одного и того же процесса называется задержкой переключения потоков . Время от момента генерации аппаратного прерывания до момента его обслуживания называется задержкой прерывания .
Переключение между двумя процессами в одной операционной системе с одним адресным пространством может происходить быстрее, чем переключение между двумя процессами в операционной системе с частными адресными пространствами для каждого процесса. [7]
Переключение контекста может осуществляться преимущественно программным или аппаратным способом. Некоторые процессоры, такие как Intel 80386 и его преемники, [8] имеют аппаратную поддержку переключения контекста за счет использования специального сегмента данных, называемого сегментом состояния задачи (TSS). Переключение задач может быть явно инициировано с помощью инструкции CALL или JMP, нацеленной на дескриптор TSS в глобальной таблице дескрипторов . Это может произойти неявно, когда срабатывает прерывание или исключение, если в таблице дескрипторов прерываний (IDT) есть шлюз задачи . Когда происходит переключение задачи, ЦП может автоматически загрузить новое состояние из TSS.
Как и в случае с другими задачами, выполняемыми аппаратно, можно было бы ожидать, что это будет довольно быстро; однако основные операционные системы, включая Windows и Linux , [9] не используют эту функцию. В основном это связано с двумя причинами:
TS включается автоматически , что приводит к сбою при выполнении инструкций с плавающей запятой и дает ОС возможность сохранить и восстановить состояние с плавающей запятой по мере необходимости).CR0 Переключение контекста лежит в основе процесса жонглирования. Он состоит из остановки текущего вычисления, сохранения достаточного количества информации, чтобы его можно было перезапустить позже, и перезапуска другого процесса.