ViKo 1 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Странное утверждение, кнопки с задержкой до окончания обработки чего-то == неправильный подход к программированию. Ну, как же - суперцикл. Запоминается нажатие по прерыванию, а обработка - когда очередь дойдет. Пока доберешься до обработки кнопки... Приходилось обработку сигнала дробить на части, только чтобы быстрее бегать по суперциклу. А с РТОС могу сразу уйти на обработку кнопки, не беспокоясь о состоянии задачи обработки сигнала. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 18 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Мне вот не совсем понятно, зачем обязательно между задачами обмениваться сообщениями, семафорами. А просто иметь глобальные переменные, с флагами и т.д.? Или это уже противоречит принципам разделения на задачи, которые нельзя будет отлаживать поодиночке? А семафор это и есть по сути флаг, означающий занятость какого-либо ресурса. Например, если два потока одновременно пытаются вывести данные в один порт, не зная ничего друг о друге и работая совершенно асинхронно Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Ну, как же - суперцикл. Запоминается нажатие по прерыванию, а обработка - когда очередь дойдет. Пока доберешься до обработки кнопки... Приходилось обработку сигнала дробить на части, только чтобы быстрее бегать по суперциклу. Издеваетесь? А конечные автоматы на что? А распределение задач по тайм-слотам? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба А семафор это и есть по сути флаг, означающий занятость какого-либо ресурса. Мне эти сущности понятны. Изучил и использовал. Но зачем? Типа, чисто терминологическая абстракция? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 18 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Приходилось обработку сигнала дробить на части, только чтобы быстрее бегать по суперциклу. Стандартный подход. Можно ещё и приоритеты ввести, путем continue внутри цикла. То есть, сверху - самые приоритетные задачи, снизу - самые низкоприоритетные. После выполнения любой из задач выполняется continue, который возвращает к началу цикла и соответственно, проверяет флаги задач в порядке убывания приоритета. Каждая из задач в этом случае - конечный автомат с внутренними состояниями, который как можно быстрее возвращает управление обратно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Издеваетесь? А конечные автоматы на что? А распределение задач по тайм-слотам? Ну, вот и приплыли! К ОС. :rolleyes: Какая уже разница - городить собственный конечный автомат, с условиями переходов, если можно взять готовую ОС с переключениями задач по событиям? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 18 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Ну, вот и приплыли! К ОС. :rolleyes: В общем-то, да. И даже для апологетов автоматного проектирования на основе прерываний можно написать такую ось, которая будет в той или иной степени автоматизировать и систематизировать процесс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Ну, вот и приплыли! К ОС. :rolleyes: А, ну если от ТАКОГО берега отчалить, то таки да Насчет семафора - это не только стандартный подход, но и способ не вызывать ожидающую задачу. Например, при give() - внутри этого give() можно спрятать код, который "разбудит" все ожидающие семафор треды , а при take() - процесс, который "наступил" на занятый семафор - будет удален из списка очереди выполнения. Таким образом, "наворот" этот исключает оверхед перебора задач и поллинга. Приплыли к оси? :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Виктория 0 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба А, ну если от ТАКОГО берега отчалить, то таки да Насчет семафора - это не только стандартный подход, но и способ не вызывать ожидающую задачу. Например, при give() - внутри этого give() можно спрятать код, который "разбудит" все ожидающие семафор треды , а при take() - процесс, который "наступил" на занятый семафор - будет удален из списка очереди выполнения. Таким образом, "наворот" этот исключает оверхед перебора задач и поллинга. Приплыли к оси? :) _Pasha, хочется узнать - в противостоянии OC РВ vs bare-metal Вы к какой стороне ближе? Согласна, развитие технологий виртуализации - это ещё один аргумент в поднятии старой темы Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 27 сентября, 2012 Опубликовано 27 сентября, 2012 (изменено) · Жалоба _Pasha, хочется узнать - в противостоянии OC РВ vs bare-metal Вы к какой стороне ближе? Согласна, виртуалазация - это ещё один аргумент в поднятии старой темы Естественно, ближе к оси. Но, скажу другими словами, мне не нравится пропаганда под аргументами "ниже плинтуса", равно как и ничем не оправданные восторги от вытесняющей многозадачности, очередей сообщений и неуёмная жажда тотальной стандартизации. Вот для чего мне, спрашивается, тратить ОЗУ на хранение контекстов, если весь этот контекст сводится к одному указателю, если процесс сам знает, когда ему отдать управление (кооперативная многозадачка), если при использовании примитивов синхронизации у меня есть планировщик, который перебирает очередь выполнения, если железные прерывания у меня обслуживаются точно так же, в общем - если я знаю, что мне нужно, и могу достаточно долго сидеть на одном самом дешевом и доступном камне, потому что ресурсов 100% хватит на всё. И если мне надо установить один бит, то я его таки установлю, а не буду обращаться к системному вызову, или создавать сообщение "установите мне такой-то флаг" или пользоваться какой-либо другой дурковатой обёрткой. То же касается любого API - как известно, он никогда не может быть хорошим. А то - подключил дефолтные сторонние либы - еще ничего не сделал - мама дорогая! Уже нету 20% флеша! Ну это вообще... А там просто всего лишь зависимостей много. Изменено 27 сентября, 2012 пользователем _Pasha Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Ну а ОС РВ мне ещё не была нужна, т.к. это доп-й источник проблем. Пусть их продолжают исп-ть в китайских телефонах, а я воздержусь. Удачи! Ну так тогда может уместнее пойти со своими "аргументами" и "понималками" :bb-offtopic: ... куда-то в другую тему? Потому как здесь тему назвали то: "ОС РВ"... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Виктория 0 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Olej, здравствуйте. 1) Нам нужно понять, что функции ОС РВ ни в коей мере не сводятся к реализации конечного автомата. Хотя это и является одним из критериев выбора инструментария для своего приложения 2) Появление тенденций к сертификации ПО (валидации, верификации, ...). Можно ли сейчас предугать, кто выиграет гонку стандартизации? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба А просто иметь глобальные переменные, с флагами и т.д.? Или это уже противоречит принципам разделения на задачи, которые нельзя будет отлаживать поодиночке? Вообще в любом коде глобальные переменные - это шаг назад. Но когда пишешь ПО для мк с ограниченными возможностями ресурсами, то это вполне оправданный шаг. Вместо ОС-ных няшек использовать глобальные переменные вполне в норме. Если запись/чтение флага (или переменной) есть атомарная операция, то будет всё работать не хуже чем с семафором. А если доступ до флага это есть чтение-модификаци-запись, то тут нужно позаботится о том, чтоб обращение к флагу не было прервано (крит. секции, мютексы, или в конце концов запрет прерываний). А запирать обращение к глобальной переменной каким нить мютексом - уш лучше сразу использовать ОС-ные месаджи и флаги. И флаг глобальный все равно нужно постоянно проверять, а ОС-ный флаг проверяется за кулисами, и программеру не надо об это заботиться. например с ос-ным флагам задачу по гуи можно оформить в 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 27 сентября, 2012 Опубликовано 27 сентября, 2012 (изменено) · Жалоба 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 27 сентября, 2012 Опубликовано 27 сентября, 2012 · Жалоба Очень ценное замечание! (В программах на Форт, в силу "широкого" использования стеков для неименованной передачи параметров их почти нет:) 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 года, ... как-то напомнило даже из Иосифа Бродского: Двадцать лет это срок, Что длиннее и глубже могилы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться