[ViKo 1]

Странное утверждение, кнопки с задержкой до окончания обработки чего-то == неправильный подход к программированию.

Ну, как же - суперцикл. Запоминается нажатие по прерыванию, а обработка - когда очередь дойдет. Пока доберешься до обработки кнопки... Приходилось обработку сигнала дробить на части, только чтобы быстрее бегать по суперциклу.

А с РТОС могу сразу уйти на обработку кнопки, не беспокоясь о состоянии задачи обработки сигнала.

[MrYuran 18]

Мне вот не совсем понятно, зачем обязательно между задачами обмениваться сообщениями, семафорами. А просто иметь глобальные переменные, с флагами и т.д.? Или это уже противоречит принципам разделения на задачи, которые нельзя будет отлаживать поодиночке?

А семафор это и есть по сути флаг, означающий занятость какого-либо ресурса.

Например, если два потока одновременно пытаются вывести данные в один порт, не зная ничего друг о друге и работая совершенно асинхронно

[_Pasha 0]

Ну, как же - суперцикл. Запоминается нажатие по прерыванию, а обработка - когда очередь дойдет. Пока доберешься до обработки кнопки... Приходилось обработку сигнала дробить на части, только чтобы быстрее бегать по суперциклу.

Издеваетесь? А конечные автоматы на что? А распределение задач по тайм-слотам?

[ViKo 1]

А семафор это и есть по сути флаг, означающий занятость какого-либо ресурса.

Мне эти сущности понятны. Изучил и использовал. Но зачем? Типа, чисто терминологическая абстракция?

[MrYuran 18]

Приходилось обработку сигнала дробить на части, только чтобы быстрее бегать по суперциклу.

Стандартный подход.

Можно ещё и приоритеты ввести, путем continue внутри цикла.

То есть, сверху - самые приоритетные задачи, снизу - самые низкоприоритетные.

После выполнения любой из задач выполняется continue, который возвращает к началу цикла и соответственно, проверяет флаги задач в порядке убывания приоритета.

Каждая из задач в этом случае - конечный автомат с внутренними состояниями, который как можно быстрее возвращает управление обратно.

 

[ViKo 1]

Издеваетесь? А конечные автоматы на что? А распределение задач по тайм-слотам?

Ну, вот и приплыли! К ОС. :rolleyes:

Какая уже разница - городить собственный конечный автомат, с условиями переходов, если можно взять готовую ОС с переключениями задач по событиям?

[MrYuran 18]

Ну, вот и приплыли! К ОС. :rolleyes:

В общем-то, да.

И даже для апологетов автоматного проектирования на основе прерываний можно написать такую ось, которая будет в той или иной степени автоматизировать и систематизировать процесс.

[_Pasha 0]

Ну, вот и приплыли! К ОС. :rolleyes:

А, ну если от ТАКОГО берега отчалить, то таки да

Насчет семафора - это не только стандартный подход, но и способ не вызывать ожидающую задачу.

Например, при give() - внутри этого give() можно спрятать код, который "разбудит" все ожидающие семафор треды , а при take() - процесс, который "наступил" на занятый семафор - будет удален из списка очереди выполнения. Таким образом, "наворот" этот исключает оверхед перебора задач и поллинга. Приплыли к оси? :)

 

[Виктория 0]

А, ну если от ТАКОГО берега отчалить, то таки да

Насчет семафора - это не только стандартный подход, но и способ не вызывать ожидающую задачу.

Например, при give() - внутри этого give() можно спрятать код, который "разбудит" все ожидающие семафор треды , а при take() - процесс, который "наступил" на занятый семафор - будет удален из списка очереди выполнения. Таким образом, "наворот" этот исключает оверхед перебора задач и поллинга. Приплыли к оси? :)

 

_Pasha, хочется узнать - в противостоянии OC РВ vs bare-metal Вы к какой стороне ближе?

Согласна, развитие технологий виртуализации - это ещё один аргумент в поднятии старой темы

[_Pasha 0]

_Pasha, хочется узнать - в противостоянии OC РВ vs bare-metal Вы к какой стороне ближе?

Согласна, виртуалазация - это ещё один аргумент в поднятии старой темы

Естественно, ближе к оси. Но, скажу другими словами, мне не нравится пропаганда под аргументами "ниже плинтуса", равно как и ничем не оправданные восторги от вытесняющей многозадачности, очередей сообщений и неуёмная жажда тотальной стандартизации.

 

Вот для чего мне, спрашивается, тратить ОЗУ на хранение контекстов, если весь этот контекст сводится к одному указателю, если процесс сам знает, когда ему отдать управление (кооперативная многозадачка), если при использовании примитивов синхронизации у меня есть планировщик, который перебирает очередь выполнения, если железные прерывания у меня обслуживаются точно так же, в общем - если я знаю, что мне нужно, и могу достаточно долго сидеть на одном самом дешевом и доступном камне, потому что ресурсов 100% хватит на всё. И если мне надо установить один бит, то я его таки установлю, а не буду обращаться к системному вызову, или создавать сообщение "установите мне такой-то флаг" или пользоваться какой-либо другой дурковатой обёрткой.

То же касается любого API - как известно, он никогда не может быть хорошим.

А то - подключил дефолтные сторонние либы - еще ничего не сделал - мама дорогая! Уже нету 20% флеша! Ну это вообще... А там просто всего лишь зависимостей много.

Изменено 27 сентября, 2012 пользователем _Pasha

[Olej 0]

Ну а ОС РВ мне ещё не была нужна, т.к. это доп-й источник проблем. Пусть их продолжают исп-ть в китайских телефонах, а я воздержусь. Удачи!

 

Ну так тогда может уместнее пойти со своими "аргументами" и "понималками" :bb-offtopic: ... куда-то в другую тему?

Потому как здесь тему назвали то: "ОС РВ"...

 

 

[Виктория 0]

Olej, здравствуйте.

 

1) Нам нужно понять, что функции ОС РВ ни в коей мере не сводятся к реализации конечного автомата. Хотя это и является одним из критериев выбора инструментария для своего приложения

 

2) Появление тенденций к сертификации ПО (валидации, верификации, ...). Можно ли сейчас предугать, кто выиграет гонку стандартизации?

[juvf 17]

А просто иметь глобальные переменные, с флагами и т.д.? Или это уже противоречит принципам разделения на задачи, которые нельзя будет отлаживать поодиночке?

Вообще в любом коде глобальные переменные - это шаг назад. Но когда пишешь ПО для мк с ограниченными возможностями ресурсами, то это вполне оправданный шаг.

Вместо ОС-ных няшек использовать глобальные переменные вполне в норме. Если запись/чтение флага (или переменной) есть атомарная операция, то будет всё работать не хуже чем с семафором. А если доступ до флага это есть чтение-модификаци-запись, то тут нужно позаботится о том, чтоб обращение к флагу не было прервано (крит. секции, мютексы, или в конце концов запрет прерываний). А запирать обращение к глобальной переменной каким нить мютексом - уш лучше сразу использовать ОС-ные месаджи и флаги. И флаг глобальный все равно нужно постоянно проверять, а ОС-ный флаг проверяется за кулисами, и программеру не надо об это заботиться.

 

 

например с ос-ным флагам задачу по гуи можно оформить в 1 строчку.

 

void task()
{
for(;;) 
    currentWindow->pressedKey(OSGetMessage(QUEUE_KEY, 0)); 
}

как бы это выглядело с глобальной переменной

void task()
{
    for(;;)
    {
        if(keyCode != 0)
        {
            currentWindow->pressedKey(keyCode);
            keyCode = 0;
        }
        else
            OSTaskDelayMs(50);
    }
}

по мне, так гораздо кошерний первый вариант. по памяти программ и латентности тут оба варианта примерно одинаковы. А вот по памяти данных 2-й выгрывает. По реакции на нажатие клавиши, т.е. на обработку нажатия (можно сказать на скорость выполнения программы) 1 вариант выигрывает. Если у меня найдется свободное озу, я всегда использую 1 вариант.

[Kopa 0]

Sorry, не удержался от частичного офтопика:) но тема подходящая.

Проект призёр 2nd Prize! Philips ARM Design Contest 2005

noPC (сайт разработчика)

Проект на базе LPC2138/2148 автономного "компьютера".

 

P.S. В данном варианте, Форт операционная среда замещает функции операционной системы.

 

Вообще в любом коде глобальные переменные - это шаг назад. Но когда пишешь ПО для мк с ограниченными возможностями ресурсами, то это вполне оправданный шаг.

 

Очень ценное замечание! (В программах на Форт, в силу "широкого" использования стеков для неименованной передачи параметров их почти нет:)

Author: Philip J. Koopman, Jr. WISC Technologies, Inc., Pittsburgh, PA © Copyright 1989

Stack Computers: the new wave, zip-архив, online web version

Philip Koopman's Home Page

 

Изменено 27 сентября, 2012 пользователем Kopa

[Olej 0]

Очень ценное замечание! (В программах на Форт, в силу "широкого" использования стеков для неименованной передачи параметров их почти нет:)

Author: Philip J. Koopman, Jr. WISC Technologies, Inc., Pittsburgh, PA © Copyright 1989

Stack Computers: the new wave, zip-архив, online web version

 

Forth был достаточно интересный проект... Но:

- к чему-либо, что имеет отношение к функциональности ОС РВ (см. имя темы) - он просто неуместен;

- он именно был, у него было мощное community ... но всё это в прошлом - книжка то показанная тоже 1989г. - 23 года, ... как-то напомнило даже из Иосифа Бродского:

Двадцать лет это срок,

Что длиннее и глубже могилы.