Comments 19
Можно ли попросить автора идентифицировать себя в этом списке?
Да, конечно, меня зовут Вита (Vita.Loginova), наверное, нетрудно догадаться по моему нику.
На самом деле не все с ходу скажут, что Vita — жизнь.:)
Да, и в этом случае логичнее было бы ожидать LifeL ;)
UFO just landed and posted this here
Спасибо.
Контент полностью оригинальный. На другие языки переводы были, но они не наши, если честно.
Контент полностью оригинальный. На другие языки переводы были, но они не наши, если честно.
UFO just landed and posted this here
Что то академическое тут безусловно есть, поскольку Вита писала диплом «Разработка планировщика ОСРВ с совмещением кооперативной и вытесняющей многозадачности».
А по поводу проприетарности, я думаю Вита (LifeV) будет не против, если статьи будут обладать свободной лицензией.
А по поводу проприетарности, я думаю Вита (LifeV) будет не против, если статьи будут обладать свободной лицензией.
Продолжайте конечно, тема интересная и весьма широкая. еще интересно бы почитать про сравнение шедулеров в популярных ОС (в т.ч. всяких «мелких» RTOS).
Девушка, разбирающаяся в таких темах, довольно редкое явление. Похвально, Вы молодец!
Статься хорошая, спасибо!
Статься хорошая, спасибо!
Почему пишете свою RTOS, тем более кроссплатформенную, а не садитесь на какую-нибудь готовую опенсорсную, например ChibiOS?
Каковы достигнутые конкурентные преимущества вашей RTOS относительно других, ради которых была проведена такая масштабная разработка?
Существует ли пруф корректной работы ядра в части работы с потоками и синхронизационными примитивами?
Однако, в любом случае подобная разработка — чрезвычайно интересное и полезное с точки зрения детального понимания механизмов работы компонетов ОС и взаимодействия их с ресурсами системы. Это, наверное, как художнику большое эпохальное полотно написать — трудно, долго, но очень увлекательно.
PS — я в 95м году написал либу на Си и Ассемблере, реализующую паралеллизм в реальном режиме x86 под Досом — со всеми переключениями контекста процессора и сопроцессора, состояниями процессов, своим менеджером памяти, очередями к нереентерабельным функциям доса и биоса, шедулингом, завязанным на таймер, привязанным другим аппаратным прерываниям (там была машина для управления оборудованием), и софтовым интам. Также был написан монитор состояния процессов на чистом асме с индикацией ресурсов, семафоров и статусов.
Помню, что управление тредами вызывало у меня ассоциацию с законом Мерфи — если уж вы открыли банку с червями… — так как породить тред было сравнительно просто, а вот грамотно придержать на ожидании ресурса, или убить внешними средствами — гораздо сложнее
Каковы достигнутые конкурентные преимущества вашей RTOS относительно других, ради которых была проведена такая масштабная разработка?
Существует ли пруф корректной работы ядра в части работы с потоками и синхронизационными примитивами?
Однако, в любом случае подобная разработка — чрезвычайно интересное и полезное с точки зрения детального понимания механизмов работы компонетов ОС и взаимодействия их с ресурсами системы. Это, наверное, как художнику большое эпохальное полотно написать — трудно, долго, но очень увлекательно.
PS — я в 95м году написал либу на Си и Ассемблере, реализующую паралеллизм в реальном режиме x86 под Досом — со всеми переключениями контекста процессора и сопроцессора, состояниями процессов, своим менеджером памяти, очередями к нереентерабельным функциям доса и биоса, шедулингом, завязанным на таймер, привязанным другим аппаратным прерываниям (там была машина для управления оборудованием), и софтовым интам. Также был написан монитор состояния процессов на чистом асме с индикацией ресурсов, семафоров и статусов.
Помню, что управление тредами вызывало у меня ассоциацию с законом Мерфи — если уж вы открыли банку с червями… — так как породить тред было сравнительно просто, а вот грамотно придержать на ожидании ресурса, или убить внешними средствами — гораздо сложнее
Если позволите, я отвечу вместо Виты. Поскольку главный вопрос «зачем писать свою ОС», скорее ко мне. Хотя вы сами частично ответили на свой вопрос. Разработка чрезвычайно полезная, например, для студентов IT специальностей. Вита, в частности пишет курсовую по теме примитивов синхронизации. Вообще на кафедре системного программирования СПбГУ принято, чисто теоритические знания подкреплять практикой.
Но как не смешно, ОС мы начинали писать потому, что были проблемы с существующими решениями в одном из коммерческих проектов. Правда тогда это была даже не ОС, а скорее оболочка для тестиования и отладки аппаратуры (VHDL). Впоследствии она обрасла всякими полезными вещами. Затем мы подключили студентов, открыли исходики и сейчас вполне себе пусть маленькая, но гордая ОС:)
По поводу доказательство работы. Можно предложить скачать проект собрать его и запустить, Дело максимум 30 минут с установкой всего окружения. Работы с потоками и примитивами синхронизации там хватает. Но если поверите на слово, то у нас портирована Qt и java машина, в которых достаточно хорошо работает многопоточность. Я думаю работа с этими библиотеками является достачно полной проверкой многопоточности системы.
По поводу ожидания ресурса я с вами соглашцсь. Наверное это самая тонкая часть. Я реализовывал ожидание на индексных дескрипторах с помощью тех средств которые Вита разработала и то очень долго отлаживал. А сам принцип это…
Но как не смешно, ОС мы начинали писать потому, что были проблемы с существующими решениями в одном из коммерческих проектов. Правда тогда это была даже не ОС, а скорее оболочка для тестиования и отладки аппаратуры (VHDL). Впоследствии она обрасла всякими полезными вещами. Затем мы подключили студентов, открыли исходики и сейчас вполне себе пусть маленькая, но гордая ОС:)
По поводу доказательство работы. Можно предложить скачать проект собрать его и запустить, Дело максимум 30 минут с установкой всего окружения. Работы с потоками и примитивами синхронизации там хватает. Но если поверите на слово, то у нас портирована Qt и java машина, в которых достаточно хорошо работает многопоточность. Я думаю работа с этими библиотеками является достачно полной проверкой многопоточности системы.
По поводу ожидания ресурса я с вами соглашцсь. Наверное это самая тонкая часть. Я реализовывал ожидание на индексных дескрипторах с помощью тех средств которые Вита разработала и то очень долго отлаживал. А сам принцип это…
Антон, спасибо за развернутый ответ — в образовательных целях построение многозадачной ОС — это незаменимый боевой опыт, к тому же сильно вдохновляющий самих участников процесса.
Насчет доказательства корректной работы — все имхо тут сложнее, ибо даже многочасовой многопоточный прогон в стрессовых для механизмов синхронизации условиях не гарантирует абсолютную корректность работы. А испортить ее можно одним неосторожным коммитом, причем функциональные тесты при этом могут и не упасть — например, вложенным вызовом функций, запрещающих и затем разрешающих прерывания внутри своих критических секций, или наоборот — расчет на выполнение сервиса ОС в обработчике прерывания, которое оказывается при какой-то комбинации условий запрещенным — в обоих случаях, вуаля — прощай, стабильное ядро. И все это — кроссплатформенно.
И еще — аппаратная основа многопоточности — это возможность оставить свой контекст *целиком и без искажения* в стеке. Насколько я помню, некоторые архитектуры не позволяют это сделать иначе, как посредством аппаратного прерывания (возможность это сделать для последнего очевидна в силу самого принципа прерываний). Отсюда вывод, что алгоритмы ядра в части перехода процесса в ожидание, его реактивации (особенно по условию) и терминирования для таких архитектур должны быть реализованы с учетом этого факта — в частности, моментальные просыпания ожидающего события потока могут и не поддерживаться иначе, как симуляцией аппаратного прерывания например, через GPIO. Интересно, у вас этим моментам уделено внимание?
Насчет доказательства корректной работы — все имхо тут сложнее, ибо даже многочасовой многопоточный прогон в стрессовых для механизмов синхронизации условиях не гарантирует абсолютную корректность работы. А испортить ее можно одним неосторожным коммитом, причем функциональные тесты при этом могут и не упасть — например, вложенным вызовом функций, запрещающих и затем разрешающих прерывания внутри своих критических секций, или наоборот — расчет на выполнение сервиса ОС в обработчике прерывания, которое оказывается при какой-то комбинации условий запрещенным — в обоих случаях, вуаля — прощай, стабильное ядро. И все это — кроссплатформенно.
И еще — аппаратная основа многопоточности — это возможность оставить свой контекст *целиком и без искажения* в стеке. Насколько я помню, некоторые архитектуры не позволяют это сделать иначе, как посредством аппаратного прерывания (возможность это сделать для последнего очевидна в силу самого принципа прерываний). Отсюда вывод, что алгоритмы ядра в части перехода процесса в ожидание, его реактивации (особенно по условию) и терминирования для таких архитектур должны быть реализованы с учетом этого факта — в частности, моментальные просыпания ожидающего события потока могут и не поддерживаться иначе, как симуляцией аппаратного прерывания например, через GPIO. Интересно, у вас этим моментам уделено внимание?
Мы сталкнулись с этой проблемой. У нас поддеживаются несколько архитектур и когда кто нибудь коммитит то он врядли может проверить все полностью. Например, у нас переодически отваливалось Qt на ARM. При этом на x86 могло все работать и довольно большое количество тестов на потоки и средства синхронизации проходили успешно. Нужно было именно ручками вызывать прерывания и тогда можно было поймать, что события терялись. К счастью у нас есть заказчики, которые довольно быстро поднимали шум, если у них что-то ломалось. По сути дела они были нашими тестерами:)
Вообще, тема тестирования системного и встроенного ПО отдельная большая проблема. Мы в проекте ей стараемся заниматься и прогресс есть, но хотелось бы лучше.
На данный момент в проекте, есть билд сервер, который не только проверяет, что система собирается под всеми архитектурами, но и запускает все это на QEMU с соответствующей архитектурой. При этом мы даже пытаемся, если есть возможность, протестировать удаленно, по сети, всяческие службы.
Еще у нас есть инструмент для написание unit тестов. И в идеале прежде чем сделать функциональность, нужно написать на нее тесты. Пока это только в идеале.
Кстати, у нас в этом году один студент пишет диплом, на тему тестирования встроенных устройст. Он просто часто наталкивался на эти грабли с неработающим ядром:)
Вообще, тема тестирования системного и встроенного ПО отдельная большая проблема. Мы в проекте ей стараемся заниматься и прогресс есть, но хотелось бы лучше.
На данный момент в проекте, есть билд сервер, который не только проверяет, что система собирается под всеми архитектурами, но и запускает все это на QEMU с соответствующей архитектурой. При этом мы даже пытаемся, если есть возможность, протестировать удаленно, по сети, всяческие службы.
Еще у нас есть инструмент для написание unit тестов. И в идеале прежде чем сделать функциональность, нужно написать на нее тесты. Пока это только в идеале.
Кстати, у нас в этом году один студент пишет диплом, на тему тестирования встроенных устройст. Он просто часто наталкивался на эти грабли с неработающим ядром:)
Одним из методов увеличения вероятности обнаружения ошибок синхронизации может являться метод искусственного расширения критических секций, например, вставкой специальных вызовов, регистрирующих последовательность выполнения и/или осуществляющих временную задержку, после каждого оператора секции. Это можно сделать средствами условной компиляции (сильно визуально загромождает код), или специального препроцессинга.
очень интересная статья, довольно подробно обьясняет эволюцию вариантов многозадачности. Есть хорошие примеры. Ну и конечно ваша система неплохо сделана (смотрел ещё когда то давно). Считаю, что каждая уважаюшая себя кафедра системного программирования должна написать свою ось или принимать активное участие в какой-нибудь открытой оси.
Sign up to leave a comment.
Организация многозадачности в ядре ОС