Выпущена scmRTOS 4.0., Ура, товарищи! :) Опции

[AHTOXA]

Собственно, субж.
Ссылки:

• Что нового (en);
• Migration Guide;
• Download;
• svn (trunk).
• User Manual (русский)
• User Manual (en)

Кроме того, незадолго до этого была выпущена версия 3.11. Это завершающая, багофиксная версия 3.x. Ссылки:

• Download;
• svn.

[dxp]

Отдельные стеки, сохранять контекст каждой задачи, уже не неужно. Соответственно, одна из главных фич многозадачных OS с приходом C++ выглядит ненужной.

Это надо выбить в мраморе и покрасить золотыми буквами. И разместить в аллее троллинга.

" Ни один язык не заменит ОС, тем более убогий С++.

Да уж куда ему до мегаязыка Цэ.

Я согласен, что введение одинаковых приоритетов будет накладно. Просто я прекрасно обходился конечными автоматами, пока не наткнулся на то, что код чужой библиотеки надо было "параллелить" со своими задачами. Срочно пришлось смотреть RTOS, которые имели порты под мой мк - среди них была и ваша. Но, т.к. явно места блокировки в чужой библиотеки указать было затруднительно, пришлось выбрать FREERTOS, задать задачам одинаковый приоритет, переключение контекста 1 мс - и тогда я получил желаемый результат.

Почему бы просто не вынести код этой библиотеки просто в отдельный процесс, и пусть он себе там живёт? Приоритет установить из требований приложения

[Lotor]

Почему бы просто не вынести код этой библиотеки просто в отдельный процесс, и пусть он себе там живёт? Приоритет установить из требований приложения

У меня шел непрерывный поток данных, который надо было писать библиотечными функциями на карту. Я пробовал сделать так, как вы предлагаете - получалось, что отображение и реакция на кнопки тормозилась. Если бы я мог указать в библиотеки места блокировки - расставить семафоры и т.п., то этот вариант сработал. Для меня это единственный случай, когда нужны были одинаковые приоритеты. Но он определил мой выбор RTOS.

[dxp]

У меня шел непрерывный поток данных, который надо было писать библиотечными функциями на карту. Я пробовал сделать так, как вы предлагаете - получалось, что отображение и реакция на кнопки тормозилась. Если бы я мог указать в библиотеки места блокировки - расставить семафоры и т.п., то этот вариант сработал. Для меня это единственный случай, когда нужны были одинаковые приоритеты. Но он определил мой выбор RTOS.

Всё равно не понял. Почему тормозилось? Какой-то более приоритетный код надолго отбирал управление? Или этот код библиотеки тормозил остальное?

Если второе, то не очень понятно, почему ему не понизить приоритет, чтобы кнопки не блокировал?

Не очень-то оно и накладно.

Это что считать наклАдным. Переключение контекста сама по себе приличная по объёму инструкций операция. И отдельный стек. Я понимаю, что при наличие 32К оперативы выделить лишних полкилобайта особых вопросов не вызывает. Но чем это лучше, чем просто выполнять задания по очереди в одном процессе?

Например, TNKernel поддерживает и уровни приоритетов и round-robin в пределах каждого приоритета, а время планирования и переключения контекста такое же (или даже лучше, правда новую версию SCM4.0 я не тестил) как у SCM.

Чудес-то не бывает. Если планировщик более сложный, то и время его работы тоже будет больше. В своё время сранивал с uC-OS/II, там карта процессов состоит из распределённой структуры и приоритет вычисляется в два приёма - время передачи управления было в 2-2.5 раза больше. При прочих равных. Именно время передачи управления, а не переключение контекстов. Время переключения контекстов само по себе зависит от размера контекста, от процессора и его тактовой, но не от ОС.

Другое дело, что кому-то пофиг, что время передачи управления в несколько раз меньше. Например, zltigo прямо говорил, что ему не важно, сколько он там времени тратит, на его задачах всё успевает, а наличие возможностей ему нравится, поэтому его выбор FreeRTOS. Точнее, то, что от неё осталось после его доработок.

И реально этот round-robin используется, недавний конкретный пример - потоки выполнения CGI в HTTP-сервере. С точки зрения системы, как бы не должны обработчики двух одновременных HTTP-запросов между собой по приоритетам отличаться. Или если у процессора два абсолютно одинаковых MAC-а. ИМХО, некрасиво если потоки драйвера одинакового "железа" будут иметь различные приоритеты.

Это почему ещё? Это зависит от приложения. Кто сказал, что МАСи должны иметь одинаковые приоритеты? Если по одному из них трафик большой, а по второму малый, то вот и разница.

[ReAl]

Кто сказал, что МАСи должны иметь одинаковые приоритеты? Если по одному из них трафик большой, а по второму малый, то вот и разница.

Та не™, у Вячеслава по обеим (одинаково) большой :-)

[dxp]

Та не™, у Вячеслава по обеим (одинаково) большой :-)

Тем более, зачем тут лишние накладняки на передачу управления в непредсказуемый момент?

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

Внешне ситуация понятна. Но внутри-то всегда особенности. Скажем, вот обработка кнопок управления - она выполняется очень периодически. Т.е. там большие паузы между реальной работой. Поэтому, передвинув, задачу в приоритет выше, чем у той, которая пишет на карту, никаких проблем возникнуть не должно - приоритетная задача выполняется коротко, а скважность большая. Кстати, про задачу, которая пишет на карту, - неужели она съедает там всё время? Ведь сам процесс записи на такой носитель как правило требует значительных циклов ожидания, пока там очередная порция запишется - это ведь не в оперативу писать. И вот в эти моменты и отдавать управление. Или там окончания записи поллингом проверяется?

[Lotor]

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

Поллингом - использовал чужой драйвер, а допиливать "под себя" было некогда. Хотя по идеи, если время переключения контекста мало, то и в поллинге можно вставить небольшие задержки и выкрутиться. Так или иначе с одинаковыми приоритетами решить подобные задачи проще всего, особенно для не очень искушенных людей в подобных вопросах.