СОС зачёт ответы
.pdf
1.Значения регистров процесса записываются в Stack этого же процесса в оперативной памяти. Таким образом, процесс в своей памяти хранит свой же контекст.
2.Контекст планировщика появляется на процессоре, выполняет анализ имеющихся процессов.
3.Переключает процессор на контекст уже другого, нового процесса.
Вцелом, смена контекста происходит между состояниями «Готов», «Ожидает» и
«Исполняется».
Критические секции и блокировки
Одна из основных проблем, с которыми может столкнуться такая система с вытесняющей многозадачностью — порядок доступа процессов к их общим ресурсам.
Возникают, так называемые, критические секции – участки исполняемого кода программы, в которых производится доступ к общему ресурсу (данным или устройству), который не должен быть одновременно использован более чем одним потоком выполнения.
Рис 12. Критические секции в потоках процесса
Может возникнуть такая ситуация, когда один поток, «потребитель», начинает использовать данные, которые должен подготовить другой поток, «производитель», но этот производитель ещё не закончил их подготовку и снялся с исполнения. Таким образом, «потребитель» использует некорректные данные, что с высокой долей вероятности приведёт к ошибке.
Данная проблема решается с помощью механизма блокировок – когда поток, получивший доступ к ресурсу, блокирует его, не давая другим потокам пользоваться этим захваченным ресурсом до разблокировки. То есть, если один поток хочет захватить
(заблокировать) ресурс, а он уже занят другим потоком, то первый будет ожидать пока этот другой поток-владелец сам не освободит этот ресурс.
Все эти механизмы обеспечиваются операционной системой
Чтобы лучше это понять, можно обратиться к аналогии с туалетом — им может пользоваться только один человек. Если другой хочет им воспользоваться, то ему нужно дождаться, когда его освободит уже им пользующийся.
24. Что такое дедлок?
Из-за блокировки, захвата ресурса может возникнуть другая проблема: Deadlock - взаимная блокировка.
Рис 13. Аналогия пробки на перекрёстке с Deadlock
Deadlock — ситуация, при которой несколько потоков находятся в состоянии ожидания ресурсов, занятых друг другом, и ни один из них не может продолжать свое выполнение.
Пример Deadlock’a на псевдокоде
Шаг |
|
Поток 1 |
|
Поток 2 |
|
|
|
|
|
|
|
|
|
|
0 |
|
Хочет захватить A и B, начинает с A |
|
Хочет захватить A и B, начинает с B |
|
|
|
|
|
|
|
|
|
|
1 |
|
lock(A) — Захват А |
|
lock(B) — Захват B |
|
|
|
|
|
|
|
|
||
2 |
|
lock(B) — Ожидает освобождения ресурса B |
|
lock(A) — Ожидает освобождения ресурса A |
|
|
|
|
|
…
DEADLOCK –> Далее код не выполнится, так как произошел Deadlock в коде выше
n |
|
unlock(A) — освобждение A |
|
unlock(B) — освобждение B |
|
|
|
|
|
|
|
|
|
|
n+1 |
|
unlock(B) — освобждение B |
|
unlock(A) — освобждение A |
|
|
|
|
|
Схематично, Deadlock можно изобразить так:
Рис 14. Deadlock
Проблема Deadlock-ов решаема и существует множество способов сделать это - начиная от недопущения подобных ситуаций в самом коде программы, заканчивая механизмами операционной системы, которые разрешают подобные ситуации. Но, однозначно исключить вероятность возникновения подобных ситуаций нельзя. Однако, это отдельная достаточно большая тема.