- •2. Операционная система как расширенная машина
- •3. Операционная система как менеджер ресурсов
- •4. Обзор современных ос Операционные системы мэйнфреймов
- •Серверные операционные системы
- •Операционные системы для персональных компьютеров
- •Операционные системы реального времени
- •Встроенные операционные системы
- •Операционные системы для смарт-карт
- •5. Аппаратный состав персонального компьютера
- •6. Процессоры
- •7. Память
- •8. Устройства ввода-вывода
- •9. Шины
- •10. Понятия операционной системы
- •11. Процессы
- •12. Взаимоболокировка
- •13. Управление памятью.
- •14. Ввод-вывод данных
- •15. Файлы
- •16 Безопасность
- •17 . Оболочка.
- •18. Системный вызов
- •19. Windows Win32 api
- •20. Структура операционной системы
- •21 Монолитные системы
- •22 Многоуровневые системы
- •23. Виртуальные машины.
- •24. Экзоядро.
- •25. Модель клиент-сервис.
- •26. Модель процесса.
- •27 Создание процесса
- •28 Завершение процесса
- •29. Иерархия процессов
- •30. Состояние процессов
- •31. Реализация процессов
- •32. Потоки
- •33. Модель потока.
- •34. Использование потоков.
- •35. Реализация потоков в пространстве пользователя.
- •36. Реализация потоков в пространстве ядра.
- •37 Смешанная реализация
- •38 Активация планировщика
- •39 Всплывающие потоки
- •40 Состояние состязания
- •41. Критические области
- •42. Взаимное исключение с активным ожиданием
- •43. Примитивы межпроцессного взаимодействия
- •Проблема производителя и потребителя
- •44. Семафоры
- •45 Мьютексы
- •46 Монитор
- •47 .Передача сообщений
- •48. Барьеры
- •49. Сокеты
- •50. Планирование
- •52. Планирование в интерактивных системах
- •53. Планирование в системах реального времени
- •54.Политика и мезанизм.
- •57 Условие взаимоблокировки
- •58 Моделирование взаимоблокировок
- •59. Страусовский алгоритм
- •60. Обнаружение и устранение взаимоблокировок и обнаружение взаимоблокировки при наличии одного ресурса каждого типа
- •61. Обнаружение взаимоблокировок при наличии нескольких ресурсов каждого типа
- •1)Восстановление при помощи принудительной выгрузки ресурса
- •2) Восстановление путем уничтожения процессов
- •63. Избежание взаимоблокировок
- •64 Алгоритм банкира
- •65 Алгоритм банкира для несколько видов ресурсов
- •66. Предотвращение взаимоблокировок
- •67 Двухфазовое блокирование, тупики без ресурсов и голодание
- •68 Программный ввод-вывод
- •69: Управляемый прерываниями ввод-вывод
- •70: Ввод-вывод с использованием dma(Direct Memory Access).
- •71. Программные уровни ввода-вывода
- •72. Обработчики прерываний
- •73. Драйверы устройств
- •74. Аппаратная часть таймеров
- •75 Программное обеспечение таймеров
- •76 Мягкие таймеры
- •77. Транслятор
- •78. Компилятор
- •79 Понятие прохода. Многопроходный и однопроходные компиляторы
- •80 Интерпретаторы. Особенности построения интерпретаторов
- •81. Трансляторы с языка ассемблера („ассемблеры“ )
- •82.Макроопределения и макрокоманды
- •83. Отладчики
- •84. Компоновщик. Его назначение и функции
12. Взаимоболокировка
Когда взаимодействуют два или более процессов, они могут попадать в патовые ситуации, из которых невозможно выйти без посторонней помощи. Такая ситуация называется тупиком, тупиковой ситуацией или взаимоблокировкой.
Взаимоблокировки или тупиковые ситуации формально можно определить так:
Группа процессов находится в тупиковой ситуации, если каждый процесс из группы ожидает события, которое может вызывать только другой процесс из той же группы. Так как все процессы находятся в состоянии ожидания, ни один из них не будет причиной какого-либо события, которое могло бы активировать любой другой процесс в группе, и все процессы продолжают ждать до бесконечности. В этой модели мы предполагаем, что процессы имеют только один поток и что нет прерываний, способных активизировать заблокированный процесс. Условие отсутствия прерываний необходимо, чтобы предотвратить ситуацию, когда тот или иной заблокированный процесс активизируется, скажем, по сигналу тревоги и затем приводит к событию, которое освободит другие процессы в группе.
В большинстве случаев событием, которого ждет каждый процесс, является возврат какого-либо ресурса, в данный момент занятого другим участником группы. Другими словами, каждый участник в группе процессов, зашедших в тупик, ждет доступа к ресурсу, принадлежащему заблокированному процессу. Ни один из процессов не может работать, пи один из них не может освободить какой-либо ресурс и ни один из них не может возобновиться. Количество процессов и количество и вид ресурсов, имеющихся и запрашиваемых, здесь не важны. Результат остается тем же самым для любого вида ресурсов, аппаратных и программных.
Пример тупиковой ситуации: Представьте себе компьютер с накопителем на магнитной ленте и записывающим компакт-диски устройством (СD-гесогdег). Теперь представьте, что каждому из двух процессов нужно записать данные с ленты на компакт-диск. Процесс 1 запрашивает и получает в пользование устройство с лентой. Затем процесс 2 запрашивает и получает устройство для записи компакт-дисков. После этого процесс 1 запрашивает устройство для записи компакт-дисков и приостанавливается до тех пор, пока процесс 2 не освободит его. Наконец, процесс 2 запрашивает устройство с лентой и также останавливается на время, потому что магнитофон уже занят процессом 1. Перед нами типичный тупик, из которого нет выхода.
Сюда также можно включить вопросы: 57 – 63
13. Управление памятью.
В каждом компьютере есть оперативная память, используемая для хранения выполняемых программ. В очень простых операционных системах в конкретный момент времени в памяти может находиться только одна программа. Для запуска второй программы сначала нужно удалить из памяти первую и загрузить на ее место вторую.
Более изощренные системы позволяют одновременно находиться в памяти нескольким программам. Для того, чтобы они не мешали друг другу и операционной системе, необходим некий защитный механизм. Хотя этот механизм располагается в аппаратуре, он управляется операционной системой.
Вышеизложенная точка зрения имеет отношение к управлению оперативной памятью компьютера и ее защите. Другой, но не менее важный, связанный с памятью вопрос — это управление адресным пространством процессов. Обычно под каждый процесс отводится некоторый набор адресов, которые он может использовать, чаще всего начинающийся с 0 и продолжающийся до некоего максимума. В простейшем случае максимальная величина адресного пространства для процесса меньше основной памяти. Тогда процесс может заполнить свое адресное пространство, и памяти хватит на то, чтобы содержать его целиком.
Однако на многих компьютерах адресация 32- или 64-разрядная, что дает для пространства адресов 2^32 и 2^64 байта соответственно. Что произойдет, если адресное пространство процесса окажется больше, чем оперативная память компьютера, и процесс захочет использовать его целиком? На первых компьютерах подобным процессам просто не везло. В наши дни существует метод, называемый виртуальной памятью, при котором операционная система держит часть адресов в оперативной памяти, а часть на диске, и меняет их местами при необходимости.
Системы управления памятью можно разделить на два класса: перемещающие процессы между оперативной памятью и диском во время их выполнения (то есть осуществляющие подкачку целиком) или использующие строчную подкачку и те, которые этого не делают.
Ввод-вывод данных.
Во всех компьютерах есть физическое устройство для получения входных данных и вывода информации. Например, клавиатуры, принтеры, мониторы и т.д. Всеми ими должна управлять операционная система.
Каждая система имеет свою подсистему ввода-вывода для управления устройствами ввода-вывода. Некоторые из программ ввода-вывода являются независимыми от устройств, то есть их можно применить ко многим или ко всем устройствам ввода-вывода. Другая часть программного обеспечения ввода-вывода, в которую входят драйверы устройств, предназначена для определенных устройств ввода-вывода.