Представленный материал является образцом учебного исследования, примером структуры и содержания учебного исследования по заявленной теме. Размещён исключительно в информационных и ознакомительных целях.
Workspay.ru оказывает информационные услуги по сбору, обработке и структурированию материалов в соответствии с требованиями заказчика.
Размещение материала не означает публикацию произведения впервые и не предполагает передачу исключительных авторских прав третьим лицам.
Материал не предназначен для дословной сдачи в образовательные организации и требует самостоятельной переработки с соблюдением законодательства Российской Федерации об авторском праве и принципов академической добросовестности.
Авторские права на исходные материалы принадлежат их законным правообладателям. В случае возникновения вопросов, связанных с размещённым материалом, просим направить обращение через форму обратной связи.
ℹ️Настоящий учебно-методический информационный материал размещён в ознакомительных и исследовательских целях и представляет собой пример учебного исследования. Не является готовым научным трудом и требует самостоятельной переработки.
Введение 4
1. Обзор 6
1.1. Статический и динамический анализ 6
1.2. Алгоритмы динамического анализа. Алгоритм Лампорта 10
1.3. Алгоритмы динамического анализа. Алгоритм lockset . . 13
1.4. Направления развития алгоритмов динамического поиска состояния гонки 14
1.5. Динамический анализ в среде ОС z/OS: on-the-fly, post¬mortem 16
1.6. Datacollider 21
2. Реализация прототипа детектора 24
2.1. Общая схема поиска состояний гонки 24
2.2. Инициализатор 25
2.3. Обработчик 29
2.4. Анализатор GTF трассы 31
2.5. Пути развития 33
2.6. Тестирование и границы применимости 33
3. Заключение 37
Список литературы
📖 Введение
Многопоточные приложения становятся все более и более распространенными. Однако ошибки, связанные с параллельным исполнением потоков, являются наиболее неуловимыми и сложными для отладки. А для такой платформы как Mainframe все осложняется тем, что очень многие многопоточные приложения для нее являются достаточно старыми, плохо задокументированными. Тем не менее, их надо поддерживать. Поэтому необходима автоматизация поиска возможных ошибок, связанных с параллельным исполнением потоков. Например, для состояний гонки. Состояние гонки - это ситуация, когда два или более потоков в параллельной программе одновременно обращаются к одной структуре данных в общей памяти, между этими обращениями нет принудительного упорядочивания по времени, и хотя бы одно из этих обращений является записью[1, 20].
Специфика операционной системы z/OS и приложений для нее (в частности, продуктов, разрабатываемых компанией EMC) накладывает определенные ограничения и предъявляет следующие требования к детектору:
• Детектор должен иметь возможность исследовать большие приложения (от миллиона строк кода);
• Детектор должен быть способным находить гонки в приложениях, написанных на языке ассемблера HLASM;
• Детектор должен сохранять реентерабельность исследуемого приложения.
Предполагается, что имеется доступ к исходному коду исследуемого приложения.
Искать состояния гонки можно с помощью либо динамического, либо статического анализа. В данной работе подробно рассматривается динамический анализ кода.
Задачами данной работы являются:
• Анализ способов сбора информации о блокировках и операциях с памятью в среде ОС z/OS;
• Изучение подходов к поиску состояний гонки и реализация прототипа детектора состояний гонки, удовлетворяющего заданным требованиям.
✅ Заключение
В результате выполнения бакалаврской работы были решены следующие задачи:
• Произведен обзор способов сбора информации о блокировках и операциях с памятью в ОС z/OS;
• Изучены подходы к поиску состояний гонки;
• Был выбран подход к поиску состояний гонки исходя из критериев его принципиальной реализуемости и применимости к ассемблерным программам, исполняемым в среде z/OS, реализован прототип приложения для поиска состояний гонки и протестирован на реальном проекте.
Прототип детектора отвечает следующим требованиям:
• Детектор способен находить гонки в приложениях, написанных на языке ассемблера HLASM;
• Есть возможность исследовать большие приложения (от миллиона строк кода);
• Не требуется аннотирование исследуемой программы;
• Детектор сохраняет реентерабельность исследуемого приложения.
Продемонстрирована применимость подхода Datacollider к исследованию ассемблерных программ, исполняемых среде ОС z/OS