[AHTOXA 14]

Наверное вы не поняли, что задачей в моем случае является ISR, которая оформлена в виде защищенного метода в классе с защищенными данными. Никто туда, кроме методов самого класса добраться не может. Какие такие "конкурентные потоки"? Можете представить конкретный пример?

Да я-то понял. Это вы никак не можете понять, что совершенно неважно, каким образом вы обращаетесь к данным - напрямую или же из защищённого метода. Если вы обращаетесь к ним из разных потоков выполнения (ISR в вашем случае), то необходима синхронизация. И никакие защищённые методы её обеспечить не могут.

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

[VslavX 0]

Давайте всё же уточним, что это не Пастернак, а сильно допиленное чудовище Франкенштейна, причём в данный момент никем, кроме самого Франкенштейна не проверяемое :)

О как завернули. Да не вопрос - приглашаю в гости на демонстрацию, если, канешна, Франкенштейна не боитесь :). Ну еще могу, например, уважаемого ReAl в гости пригласить в качестве независимого арбитра :). Или скажете, что я арбитра пивом напоил и он не те цифры подтвердит?

 

ЗЫ. У меня, кстати, получилось 2.55 мкс (scmRTOS 4.0/GCC).

Да, GCC (начиная с 4.x) очень неплохой компилятор, и я очень серьезно думаю о переходе на него. Но это не завтра, но как поробую - отпишусь о результатах.

Вы мне лучше скажите почему SCM такая медленная? Я тут почитал Пастернака посмотрел исходники - перевод процесса из NonReady->Ready делается действительно коррекцией битовой маски. TNKernel же делает кучу работы - удаляет процесс из списка синхрообъекта, где тот коротал время в состоянии non-runnable, переносит в список активных диспетчера, и все равно - разницы во времени даже несчастных 40 процентов нету

 

[AHTOXA 14]

О как завернули. Да не вопрос - приглашаю в гости на демонстрацию, если, канешна, Франкенштейна не боитесь :). Ну еще могу, например, уважаемого ReAl в гости пригласить в качестве независимого арбитра :). Или скажете, что я арбитра пивом напоил и он не те цифры подтвердит?

Да не, я не о том:) Я верю вам и так. Но это не TNKernel, вернее, не тот TNKernel, который можно скачать и поковырять.

Вы мне лучше скажите почему SCM такая медленная? Я тут почитал Пастернака посмотрел исходники - перевод процесса из NonReady->Ready делается действительно коррекцией битовой маски. TNKernel же делает кучу работы - удаляет процесс из списка синхрообъекта, где тот коротал время в состоянии non-runnable, переносит в список активных диспетчера, и все равно - разницы во времени даже несчастных 40 процентов нету

~180 циклов - медленная? Тут скорее вопрос - как это TNKernel умудряется сделать такую кучу работы за столь короткий промежуток! :)

ЗЫ. А ReAl-а пивом - напоИте, это дело благое:)

 

[Сергей Борщ 119]

ЗЫ. А ReAl-а пивом - напоИте, это дело благое:)

Пробовал. Не получается :) Он предпочитает коньяк или хороший чай.

 

[lotor 0]

ну, наверное, можно запилить в scmTROS сущность, которой скармливается лишь битовая маска процессов которым надо карусель устроить и эта сущность каждые N системных тиков будет на время насильно усыплять очередной процесс из этой маски если он активен, таким образом давая поработать другим хоть и с меньшим приоритетом, таким образом чужие библиотеки которые внутри что-то поллят вполне могут работать по очереди? или так не получится?

накладных расходов на такой псевдо round-robbin вроде никаких.

Интересная идея, спасибо - надо будет попробовать. Но опять-таки "сущность" не так прозрачна как одинаковые приоритеты.

[dxp 34]

Возвращаясь к scmRTOS, жесткое использование приоритета как идентификатора процесса имеет еще один недостаток - приоритет не может быть динамически изменен. Значит все протоколы управления приоритетами, предназначенные для борьбы с инверсией приоритетов, также не могут быть реализованы даже теоретически :(.

Дык, если время блокировки объекта соизмеримо или меньше затрат на инверсию приоритетов (это довольно накладное действие), то зачем это делать. А обработка шарных ресурсов, где нужна гарантия того, что время обработки было минимальным, делается опять же через делегирование действий foreground процессу, в документации этот приём подробно описан.

 

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

[VslavX 0]

Дык, если время блокировки объекта соизмеримо или меньше затрат на инверсию приоритетов

Софт все сложнее и сложнее делается, поэтому кусочки кода надо стараться по возможности делать изолированными, независимыми и универсальными. А в таких условиях все сложнее и сложнее оценивать "время блокировки объекта". Tот же сетевой стек - нельзя же сказать заранее какие у него будут клиенты, а вот внутри мало-мальски сложного стека блокировки есть, никуда отних не деться, и стековые клиенты от этих внутренних блокировок будут зависеть. Вот для таких случаев и нужны универсальные рецепты типа протоколов управления приоритетов. Возможно не очень оптимально и затратно, но зато - универсально.

 

Нет, scmRTOS мне очень нравится - красиво и талантливо написана, очень шустрая, опять-таки на C++ (подтверждает тот факт что "кошек надо уметь готовить"). Но некоторые архитектурные ограничения - расстраивают. Понятно почему так сделано и откуда оно появилось. Но дальше, имхо, будет становиться печальнее - 32-битники уже серьезно на рынке, давят в том числе ценой тоже. Мелкобитники, конечно, не умрут, но ниша их пожмется хорошо так. И архитектурные ограничения принятые ради мелкобитников будут расстраивать все сильнее и сильнее :(. Поэтому я в своих портах TNKernel на мелкобитники сознательно "забил" - тоже свого рода ограничение.

 

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

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

 

[aprox 0]

CGI это несколько более широкая концепция. Имхо, под CGI следует понимать такое - поступает HTTP-запрос, сервер принимает заголовок запроса, определяет имя ресурса. Если это имя является именем скрипта (неважно на каком языке написанном - Ява, Перл, Питон, ПХП, или это вообще может быть приложение на С/С++), то сервер запускает этот скрипт и дальнейший поток данных ..

Насколько я понял, вы реализуете готовые приемы, написанные дизайнерами сайтов? Может, в этом случае проще обратиться к готовым решениям на базе Linux для микроконтроллеров, а не тратить время на scmRTOS, предназначенную для малых кристаллов c ограниченными возможностями?

 

Так вот, веберы (разработчики сайтов) поднакопили некоторый багаж алгоритмов и опыт разработки таких скриптов, принудить их поддерживать явный кооператив сложновато.

Вот этого я не понял. С ответом на запрос по-моему в жизни никто особенно не торопит. Так зачем тогда все эти "приоритеты и вытеснения" именно для скриптов? Торопиться здесь надо только в одном месте- там, где входящие пакеты вываливаются из MAC, их нужно фильтровать, сортировать и выделять непосредственно http-query. А потом, с интерпретатором и скриптами, уже никакой гонки нет.

 

К тому же обычно из этих скриптов (во встраиваемом сервере это просто процедуры на C/C++ выполняемые в отдельном порожденном потоке) требуется доступ к аппаратуре или внутренним базам данных устройства, например, оно как выдаст "SELECT к внутреннему SQL-серверу" - какой уж тут кооператив.

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

 

 

Да я-то понял. Это вы никак не можете понять, что совершенно неважно, каким образом вы обращаетесь к данным - напрямую или же из защищённого метода. Если вы обращаетесь к ним из разных потоков выполнения (ISR в вашем случае), то необходима синхронизация. И никакие защищённые методы её обеспечить не могут.

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

 

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

Как и обычно делают провайдеры, когда идет перепрошивка сайта- останавливают на какое-то время работу web-сервера, клиентам на запросы он выдает ошибку 500- busy, и занимаются переконфигурацией сколько надо времени. Вот, и вся синхронизация.

 

[VslavX 0]

Насколько я понял, вы реализуете готовые приемы, написанные дизайнерами сайтов? Может, в этом случае проще обратиться к готовым решениям на базе Linux для микроконтроллеров, а не тратить время на scmRTOS, предназначенную для малых кристаллов c ограниченными возможностями?

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

сортировать и выделять непосредственно http-query. А потом, с интерпретатором и скриптами, уже никакой гонки нет.

Пример. Один клиент HTTP-сервера просто через CGI скрипты запрашивает состояние датчиков и строит на экране диспетчеру графики параметров в реальном времени. Второй клиент в это время хочет получить статистическую выборку из внутренней базы данных устройства. Эта база может быть где угодно, ну допустим даже не крайний случай - на SD-карте лежит. Чтобы сделать выборку надо прочесть с карты полста мегабайт данных, обработать и вернуть коротенький результат. Или другой вариант - по запросу прорулить исполнительным устройством, которое вообще через-какой нить удаленный SCADA-шлюз управляется. В любом случае - скрипт CGI отдает управление стороннему коду, и надолго, на секунды/десятки секунд. И люди которые писали этот сторонний код ни про какой кооператив ни сном ни духом. Что делать с первым клиентом? Прекратить диспетчеру графики давать, потому что сторонний запрос надолго и "некооперативно" забрал управление? В-общем, мое мнение, кооператив - это ограниченное решение для ограниченных условий, когда мы всем можем прорулить и учесть все факторы. Трудно расширяемое и неуниверсальное, поэтому я перед применением кооператива долго и нудно думаю - что нужно сейчас, а что затребуют прицепить потом, а как надо поделить время между разнородными задачами и т.д. В общем же случае - кооператив вообще нормально не работает (вспоминаем Win16).

 

[AHTOXA 14]

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

И как же она обеспечивается в вашем случае?

Как и обычно делают провайдеры, когда идет перепрошивка сайта- останавливают на какое-то время работу web-сервера, клиентам на запросы он выдает ошибку 500- busy, и занимаются переконфигурацией сколько надо времени. Вот, и вся синхронизация.

:) Вы издеваетесь, да? Вы перегружаете контроллер после каждой команды по UART?

[MrYuran 16]

Насколько я понял, вы реализуете готовые приемы, написанные дизайнерами сайтов? Может, в этом случае проще обратиться к готовым решениям на базе Linux для микроконтроллеров, а не тратить время на scmRTOS, предназначенную для малых кристаллов c ограниченными возможностями?

Попробуйте запустить линукс на MSP430 или Cortex M0

Алсо, попробуйте заставить ваш линукс работать месяц (хотя бы) от пальчиковой батарейки в портативном приборе/устройстве

 

50-150р за камень и двухслойка - тоже не последний аргумент.

 

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

[aprox 0]

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

Про scmRTOS - понятно. А вот Linux игнорируете напрасно, он специально заточен на описанный вами тип задач.

Пример. Один клиент HTTP-сервера просто через CGI скрипты запрашивает состояние датчиков и строит на экране диспетчеру графики параметров в реальном времени. Второй клиент в это время хочет получить статистическую выборку из внутренней базы данных устройства. Эта база может быть где угодно, ну допустим даже не крайний случай - на SD-карте лежит. Чтобы сделать выборку надо прочесть с карты полста мегабайт данных, обработать и вернуть коротенький результат. Или другой вариант - по запросу прорулить исполнительным устройством, которое вообще через-какой нить удаленный SCADA-шлюз управляется. В любом случае - скрипт CGI отдает управление стороннему коду, и надолго, на секунды/десятки секунд. И люди которые писали этот сторонний код ни про какой кооператив ни сном ни духом.

По-моему, для борьбы со "сторонним кодом" неизвестных людей есть только одно средство - это round robin. От моих задач управления устройством описанное вами довольно далеко, а чтобы сразу несколько клиентов наваливались поуправлять режимами- так совсем невозможный и недопустимый вариант. Поэтому могу лишь посочувствовать и посоветовать обратиться к готовым решениям для серверных приложений. А это, увы, Linux и ему подобные OS.

 

 

 

И как же она обеспечивается в вашем случае?

Мне хватает просто флага готовности, мол сообщение готово- можно забирать и использовать в своих целях. Само сообщение буферизовано задачей-источником, поэтому нет напряга по времени с реакцией на этот флаг.

:) Вы издеваетесь, да? Вы перегружаете контроллер после каждой команды по UART?

Не понял. Может, мы опять о разном говорим? Что вы подразумеваете под "конфигурацией web-сервера" через uart?

 

Попробуйте запустить линукс на MSP430 или Cortex M0

Алсо, попробуйте заставить ваш линукс работать месяц (хотя бы) от пальчиковой батарейки в портативном приборе/устройстве

Потомки Линукса для мобильных устройств, например Android, вполне приличное время работают от батарейки на платформе Cortex M4. Цена конечно выше, но не порядки.

 

[AHTOXA 14]

Мне хватает просто флага готовности, мол сообщение готово- можно забирать и использовать в своих целях. Само сообщение буферизовано задачей-источником, поэтому нет напряга по времени с реакцией на этот флаг.

А если задача-приёмник не одна? Вот тот же самый пример - UART, задача-веб-сервер, и задача - ещё что-нибудь (допустим, опрос датчиков). Здесь, стало быть, задача-источник - это UART, а задачи-приёмники - это веб-сервер и опрос датчиков. Приходит в UART команда. Как с ней быть? Кто должен забирать сообщение по флагу готовности?

Затем, надо же ответить что-то в UART. Как это делается? Здесь уже ситуация "несколько писателей, один читатель". Как вы это разруливаете?

Как вы расставляете приоритеты задач?

 

Я понимаю, что это всё решаемо. Но не так, что "взял C++ и многоуровневую систему прерываний - и стало счастье".

 

Не понял. Может, мы опять о разном говорим? Что вы подразумеваете под "конфигурацией web-сервера" через uart?

Какие-то параметры, влияющие на функционирование веб-сервера. Встроенного конечно. Собственно, это же ваш пример.

[ig_z 0]

Мои пять копеек на счет скорости переключения контекста.

Несколько лет назад в Иаровском компилере для MSP430 была мелкая бага с расположенными подряд деструктором конструктором объекта.

В моем проекте эта бага проявилась при использовании TCritSect.

Написав баг репорт, я решил проэкспериментировать со скоростью выполнения TCritSect.

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

Локальный объект (TCritSect в данном случае) размещался только на стеке, и никак иначе.

Иными словами "Си-шные" ртосы, использующие пару ENTER_CRITICAL_* EXIT_CRITICAL_* всегда будут иметь фору в несколько тактов :).

 

 

Потомки Линукса для мобильных устройств, например Android, вполне приличное время работают от батарейки на платформе Cortex M4. Цена конечно выше, но не порядки.

Имена потомков в студию!

[dxp 34]

Несколько лет назад в Иаровском компилере для MSP430 была мелкая бага с расположенными подряд деструктором конструктором объекта.

В моем проекте эта бага проявилась при использовании TCritSect.

Написав баг репорт, я решил проэкспериментировать со скоростью выполнения TCritSect.

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

Локальный объект (TCritSect в данном случае) размещался только на стеке, и никак иначе.

Иными словами "Си-шные" ртосы, использующие пару ENTER_CRITICAL_* EXIT_CRITICAL_* всегда будут иметь фору в несколько тактов :).

Это только для MSP430 так, для AVR, например, он всегда такие временные объекты создавал в регистре. Да и другие компилеры тоже регистр используют. Т.ч. это конкретный косячок именно EW430, что странно, т.к. в целом очень хороший компилятор.