CC BY
44
с того момента, когда руководство компании на деле признает его одним из ресурсов компании, таким как персонал, финансы и т. п. Интернет не только позволяет, но и требует
// университета
[ЖУРНАЛ в о д н ы х /_/ коммуникации
автоматизации ряда ключевых действий со стороны менеджеров компаний, что впрямую влияет на повышение конкурентоспособности турфирмы.
Список литературы
1. Авинаш К. Веб-аналитика. Анализ информации о посетителях веб-сайтов (+ CD-ROM). — М.: Вильямс, 2009. — 28 с.
2. Ашманов И., Иванов А. Оптимизация и продвижение сайтов в поисковых системах (+ CD-ROM). — СПб.: Питер, 2008. — 163 с.
3. Плотникова Н. И. Комплексная автоматизация туристского бизнеса. — М.: Советский спорт, 2000. — Ч. I, II. — 162 с.
4. Овчинников Р., Сухов С. Корпоративный веб-сайт на 100 %. — СПб.: Питер, 2009. — 84 с.
5. Яковлев Г. А. Экономика и статистика туризма: учеб. пособие. — М.: РДЛ, 2002. — 377 с.
6. http://www.fom.ru.
7. http://www.cnews.ru.
8. http://revolution.allbest.ru.
К. С. Ушаков,
аспирант, СПбГУ
АВТОМАТИЗАЦИЯ АНАЛИЗА СИТУАЦИЙ ВЗАИМНЫХ БЛОКИРОВОК
ОПЕРАЦИОННЫХ СИСТЕМ
AUTOMATION OF ANALYSIS OF DEADLOCKS OF OPERATING SYSTEMS
Одной из ключевых проблем разработки операционных систем является предотвращение ситуаций взаимных блокировок. В работе рассмотрен механизм lockdep, проанализированы его сильные и слабые стороны. Предложено улучшение, позволяющее уменьшить изменение временных вариаций и вычислительную сложность.
One of main problems of operating system development process is to avoid deadlocks. Paper describes lockdep validation system, analyze weak and strong points. Extra timing reducing and calculation complexity improvements are suggested.
Ключевые слова: валидация, взаимные блокировки, операционные системы, временная логика, проверка моделей, LTL, верификация.
Key words: validation, deadlock, operating systems, time logic, model checking, LTL, software verification.
о X 3
ОВРЕМЕННЫЕ компьютерные системы невозможно представить без параллелизма в том или ином виде, будь то полноценный параллелизм для
нескольких процессоров или псевдопараллелизм, обеспеченный распределением процессорного времени между различными задачами, исполняемыми на компьютере. Отслежи-
<ч ж
вать и контролировать работу параллельно работающих процессов достаточно сложно, поэтому разработчики операционных систем (и прикладные разработчики) ввели концептуальную модель последовательных процессов, значительно упрощающую данную работу. В рамках модели у каждого процесса существует свой независимый центральный процессор и свой счетчик команд, несмотря на то что в системе реально может быть только один процессор со своим счетчиком. Такая модель очень удобна для разработчика, однако не следует забывать, что физически в системе некоторые ресурсы представлены в единственном числе, например физическая память. Это приводит нас к проблеме одновременного доступа к ресурсам системы.
За реализацию многозадачной среды отвечает операционная система. Она решает большинство задач, таких как:
— распределение процессорного времени и памяти;
— приоритезация процессов;
— организация и обработка прерываний (служебных или же прерываний от периферийных устройств);
— защита адресного пространства от несанкционированного доступа;
— распознавание сбоев и зависаний, их последующая обработка;
— разрешение конфликтов доступа к ресурсам, предотвращение и разрешение тупиковых ситуаций.
Данная работа рассматривает подходы к анализу тупиковых ситуаций, их прогнозированию и предотвращению.
Конфликты доступа и тупиковые ситуации достаточно сложно обнаружить в процессе тестирования. Это связано с тем, что:
— окружение, в котором происходит процесс тестирования, может отличаться (и чаще всего отличается) от окружения, в котором будет работать готовая система;
— даже при наличии ошибки в програм-68 мном коде программы она может приводить к
реальной ситуации тупика с очень маленькой вероятностью;
— в случае операционной системы обнаружение сильно зависит от аппаратной составляющей тестовой конфигурации.
Таким образом, для обнаружения потенциальных тупиковых ситуаций в коде программы и, в частности, в коде операционной системы должны применяться другие методы, альтернативные традиционным методам обеспечения качества (симуляции, модульному тестированию).
Прежде всего, необходимо понять, когда достигается состояние взаимной блокировки (тупик). Это происходит, когда нарушается простейшее правило: замки доступа должны браться всегда в одном и том же порядке. Если имеется ресурс A, работа с которым может осуществляться только при захвате замков доступа L1 и L2, ясно, что если эти замки будут захватываться в произвольном порядке, то возможна ситуация, когда процесс P1 захватил замок L1 и ожидает L2, а процесс P2 в свою очередь захватил L2 и ожидает L1. Однако такая ситуация не возможна, если все захватывают замки в одинаковом порядке.
Первый из рассматриваемых подходов основан на динамической валидации правил доступа, то есть динамической проверки корректности производимых действий. Он был предложен Инго Молнаром (Ingo Molnar) в 2006 г. и позднее развит Аряном ван дер Веном (Arjan van der Ven) в [6]. Подход реализован в ядре операционной системы Linux начиная с версии 2.6.18, выпущенной в сентябре 2006 г.
Для этого вводится понятие «тип замка», то есть тип объекта, доступ к которому обеспечивает данный замок доступа. Примерами может служить блокировка узла файловой системы, так называемого inode. Количество узлов в работающей системе — сотни тысяч, однако они все обрабатываются по похожим «сценариям», им соответствует один тип замка доступа. Каждому типу замка доступа в системе сопоставляется уникальный ключ. Для статически определенных — это адрес замка в памяти. Для динамически создаваемых — адрес уникальной переменной, статически создаваемой при первой инициализации замка посредством переопределения функции инициализации (считается, что при правильной архитектуре инициализация динамически выделяемых замков доступа происходит в одном файле), например:
# define spin_lock_init(lock) \ do { \
static struct lockdep_type_key __key; \ __spin_lock_init((lock), #lock, &__key); \ } while (0)
Основная валидация происходит при попытке доступа к защищенному объекту.
1. Валидатор анализирует все замки доступа, которые уже взяты в момент доступа к данному, и проверяет, была ли ранее ситуация, в которой данные замки брались при уже взятом новом. Это означает, что в системе нарушаются правила порядка взятия замков доступа, что может приводить к тупику.
2. Замки доступа должны освобождаться в строго обратном порядке относительно порядка взятия.
3. Замки доступа, которые берутся в обработчике прерываний, не могут удерживаться вне контекста прерывания.
Последний пункт должен быть рассмотрен подробнее. Прерывание — еще один потенциальный источник проблем. Допустим, мы взяли замок доступа в коде, который может быть прерван в случае аппаратного (или программного) прерывания, случившегося на данном процессоре. В случае попытки взять этот же замок из контекста прерывания возникнет ситуация тупика, ибо единственный контекст, способный освободить запрашиваемый замок, был вытеснен прерыванием с данного процессора.
Прежде всего требуется подчеркнуть, что данный подход не гарантирует корректности системы при отсутствии ошибок ва-лидации. Однако он предоставляет ряд значительных улучшений процесса отладки контроля доступа к разделяемым объектам. Заметим, что состоянию блокировки совсем не обязательно случиться, чтобы система ва-лидации обнаружила его потенциальную возможность.
Система валидаторов доказывает, что для каждой простой последовательности взятия замков доступа, которая встречалась в процессе работы ядра системы, не существует такого стечения обстоятельств (подбора временных вариаций), что данная последовательность взятия замков доступа приведет
II университета
[ЖУРНАЛ в о д н ы х /_/ коммуникации
к блокировке системы. Сложные сценарии, включающие несколько процессоров и несколько параллельно работающих процессов, не обязательно должны встретиться на практике для обнаружения потенциальной ошибки операционной системы. Примером
может служить ошибка, которая требовала
/ „
экзотических временных условий и наличия хотя бы трех процессоров, обнаруженная на однопроцессорной системе. Еще раз подчеркнем, что ситуация реального тупика при этом не случается (конечно, возможен элемент везения, когда это может произойти, однако это «удачные» ошибки в системе, которые достаточно просто обнаружить на этапе отладки и модульного тестирования). Отсутствие реального тупика означает, что система полностью сохраняет свою работоспособность.
Из недостатков следует упомянуть:
1. Временные задержки при анализе корректности взятия замков доступа. Эта проблема частично решается однократностью проверки корректности каждого сценария. Для этого перед каждой проверкой считыва-ется 64-битный хеш текущего стека замков и определяется, производился ли анализ данного стека (сценария).
2. Значительное изменение временных вариаций, что мешает воспроизведению некоторых сценариев взятия замков доступа.
Предлагаемый подход позволяет частично разрешить эти проблемы, а также позволяет производить анализ сценариев, встречающихся в процессе работы системы.
Альтернативой традиционным методам обеспечения качества являет формальный подход, то есть формальное доказательство соответствия программы предоставленной спецификации. Формальные методы доказательства корректности программ начались с работы Хоара 1969 г. [4] и со временем получили достаточно большое распространение. Одним из подходов к формальной проверке корректности является проверка моделей программ, предложенная Пнуели [5]. Существует целый ряд полностью автоматических систем, проверяющих корректность на модели заданных формул временных логик.
Одна из основных проблем в формальных методах в целом и проверки моделей в
<ч ж
частности — трудоемкость построения модели программы. Существующие попытки построения модели по исходному коду, такие как [2], могут применяться только к достаточно простым и не объемным задачам. Также имеются подходы по генерации различных представлений программ в некоторой модели вычислений, например [3] позволяет строить модель связей между событиями в системе. Построение полной модели операционной системы на данном этапе — практически не реализуемая задача.
Однако, как было показано на примере валидации корректности операций с замками доступа, полное формальное доказательство не всегда является необходимым. Его наличие, несомненно, делает систему надежной и гарантированно корректной, однако опыт применения динамической валидации замков доступа, в частности динамика количества ошибок, связанных с блокировкой системы, показывает, что «предсказания» большинства ситуаций некорректной работы может быть достаточно для локализации и исправления значительного числа проблем.
Рассмотрим некоторое сужение модели системы, описывающее только замки доступа, а точнее операции с типами замков доступа в смысле, введенном выше. Формально, модель программы есть структура Крипке
M = (S, R, L),
ш
170J
где: S — множество состояний;
Я — подмножество S X S — множество переходов;
£ : S ^ 2АР— функция, которая помечает каждое состояние множеством атомарных суждений, истинных в данной вершине [1].
Формальное определение строящейся структуры Крипке:
— S — множество всевозможных сценариев блокировки, то есть множество всевозможных состояний системы с точки зрения используемых замков доступа и разрешения/ запрещения аппаратных и программных прерываний. Отметим, что разрешение и запрещение прерываний можно рассматривать как взятие и отдачу замка доступа к контроллеру прерываний. Это позволяет избавить формальную модель от лишних сущностей;
— для любых двух состояний Sj и S 2 переход из Sj в S2 существует тогда и только тогда, когда симметрическая разность множеств замков доступа, использующихся в Sj и S2, содержит ровно один элемент, и существует такой сценарий работы системы, при котором за одну операцию взятия/отдачи замка доступа множество использующихся замков переходит из состояния Sj в состояние S2;
— L помечает состояния S множеством формул {f }U \fl} таких, что fl истинна в состоянии S тогда и только тогда, когда замок доступа lt взят в состоянии S, а fI истинна, если в данном состоянии разрешены прерывания.
Первым этапом валидации является построение структуры Крипке, представляющей модель программы. Для этого, аналогично подходу системы lockdep, производится подмена примитивов работы с замками доступа, однако вместо проверок корректности происходит сохранение информации о переходе состояния системы. Для этого ведется журнал переходов, который первоначально хранится в циклическом буфере, а позднее (в фоновом режиме) сбрасывается в энергонезависимую память. Отложенное сохранение журнала позволяет обеспечить темпоральную целостность регистрируемого следа событий.
В результате мы получаем некоторую структуру Крипке, описывающую переходы состояния системы, происходившие в процессе работы. Эта структура не является полной моделью системы, однако предоставляет значительный объем информации для анализа. Полученная модель передается для обработки автоматической системе проверки моделей NuSMV. Система позволяет проверить для модели выполнение некоторых формул темпоральных логик.
Теорема: правила работы с замками доступа, описанные выше, могут быть выражены в логике LTL.
Утверждение 1: Замки доступа должны освобождаться в строго обратном взятию порядке.
Для каждой пары формул flj и fl2:
yields ч
G (((А & ! fl2 ) & х (Д & fl2 )) Д и ! fl2 ).
Утверждение 2: Любые два замка доступа должны всегда браться в одном и том же порядке.
Для каждой пары формул fl и fl2:
. ч yields , s
(Д &!fl2 & Xfl2 ! F (fl2&! Д & Xflx).
Утверждение 3: Замки доступа, удерживаемые в коде, работа которого может быть прервана обработчиком прерываний, не должны запрашиваться в контексте обработчика прерываний.
Для каждой формулы flг:
(Д&!Д ) y^s! F (fI & Xflx).
Таким образом, валидация, производимая в системе lockdep в динамическом режиме, может быть произведена в процессе стати-
ческого анализа автоматически построенной модели системы. При этом процесс записи переходов, который происходит при построении модели, не вносит значительных изменений во временные вариации, что приводит к более точному воспроизведению реального окружения анализируемой системы.
Из минусов подхода следует отметить невозможность проведения записи в журнал в случае реальной ситуации тупика, так как система будет недоступна. Однако опыт применения системы 1оск^ер показывает, что подавляющее число найденных ошибок — это «предсказания», то есть нарушения правил работы с замками доступа, а не «воспроизведение» ситуаций тупика на тестируемой системе.
Список литературы
1. Model Checking / E. Clarke, Jr., O. Grumberg, D. Peled. — MIT Press, 1999.
2. CMC: A Pragmatic Approach to Model Checking Real Code / A. Chou, D. Dill, D. Engler, M. Musuvathi, D. Park // Proceedings of the Fifth Symposium on Operating System Design and Implementation. — 2002. December.
3. Automatic Model Generation for Black Box Real-Time Systems / T. Huining Feng, L. Wang, W. Zheng, S. Kanajan, S. A. Seshia // Design, Automation and Test in Europe (DATE) Conference. — 2007. April.
4. Hoare C. A. An axiomatic basis for computer programming // Commun. ACM 12. — 1969. 10 Oct. — P. 576-580.
5. Pnueli A. The Temporal Logic of Programs // In proceedings of the 18th IEEE Symposium Foundations of Computer Science. — FOCS, 1977. — P. 46-57.
6. Документация ядра ОС Linux / Ingo Molnar, Arjan van der Ven // Runtime locking correctness validator [Электронный ресурс]. Электрон. дан. Режим доступа: http://www.mjmwired.net/ kernel/ Documentation/lockdep-design.txt, свободный. — Загл. с заглавия файла.
