sheduler and micro-sheduler problem

Здравствуйте

Все мы, программируя embedded устройства, рано или поздно сталкиваемся с разными инструментальными средствами (шедулерами), которые позволяют организовать многозадачность.

Это и горячо любимый в народе UCOS от товарища Лабросса, и другие похожие средства. Чаще всего они выпускаются в виде библиотек.

Эти шедулеры среди прочего предоставляют сервис по созданию задач и средства для межзадачной синхронизации/коммуникации. Чаще всего средства для межзадачной синхронизации называются семафорами. Эти же семафоры используются и для синхронизации задач с внешними событиями (прерываниями).

Работая с некоторыми из таких шедулеров я постоянно натыкался на следующую проблему: задача может ждать семафора ( т.е.события), но не может ждать двух и более семафоров (событий), объединеных какой-либо логической функцией.

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

Более общий случай - ожидания трех событий, объединенных по ИЛИ. Например, ИЛИ нажатие кнопки, ИЛИ приход команды по сети, ИЛИ прерывание по таймеру.

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

Вопросы:

  1. Знает ли кто-нибудь, как правильно надо построить работу при необходимости синхронизовать задачу не с одним, а с несколькими семафорами?

  1. Есть ли какие-нибудь шедулеры, которые позволяют ждать нескольких событий, связанных произвольной логической функцией?

  2. В виндах и юниксе тоже нет средств для объединения нескольких событий на системном уровне. Может быть я хочу странного и эта проблема решается как-то по-другому?

Спасибо Basil.

Reply to
Basil Burtakov
Loading thread data ...
Reply to
Andy Mozzhevilov

BB>> Более общий случай - ожидания трех событий, объединенных по ИЛИ. BB>> Hапример, ИЛИ нажатие кнопки, ИЛИ приход команды по сети, ИЛИ BB>> прерывание по таймеру.

AM> А флаги в uCOS - это не то, что тебе нужно?

AM> icq 44341220

Что за флаги? Последняя версия uCOS, которую я использовал это 2.04. В ней были sempahores, message mailboxes and message queues и еще мьютексы. А что такое флаги? Это что-то новое в uCOS-строении?

Reply to
Basil Burtakov
Reply to
Andy Mozzhevilov

Fri Nov 11 2005 14:04, Basil Burtakov wrote to All:

BB> Все мы, программируя embedded устройства, рано или поздно BB> сталкиваемся с разными инструментальными средствами (шедулерами),

Шедулер --> планировщик.

BB> 2. Есть ли какие-нибудь ########, которые позволяют ждать нескольких BB> событий, связанных произвольной логической функцией?

Произвольной? А на кой это надо?

BB> 3. В виндах и юниксе тоже нет средств для объединения нескольких событий BB> на системном уровне. Может быть я хочу странного и эта проблема BB> решается как-то по-другому?

man select || WaitForMultipleObjects

Reply to
Kirill Frolov
Reply to
Sergey Zabelin
Reply to
Vladimir Vassilevsky

Здравствуйте, Уважаемый Basil!

Fri Nov 11 2005 14:04, Basil Burtakov wrote to All:

BB> Работая с некоторыми из таких шедулеров я BB> постоянно натыкался на следующую проблему: задача может ждать семафора BB> ( т.е.события), но не может ждать двух и более семафоров (событий), BB> объединеных какой-либо логической функцией.

Почему-то сразу думается, что ожидание трех семафоров означает неправильное разбиение общей задачи на параллельные процессы. Может, разбить помельче, чтоб в каждой задаче оказалось по одному месту, где она ожидает Trigg? Hо, если Вы считаете такое невозможным, то обращаю Ваше внимание на процедуры из UCOS, которые работают без ожидания внешнего события. Зато возвращают результат опроса каждого конкретного семафора. Вполне можно разобраться, какой из многих сработал.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova
Reply to
Andy Mozzhevilov
Reply to
Alex Mogilnikov

Здравствуйте, Уважаемый Andy!

Sun Nov 13 2005 09:29, Andy Mozzhevilov wrote to Olga Nonova:

AM> Флаги в uCOS-II спасут мать русской демократии.

А просто в uCOS, без "-II" ? Человек по-моему спрашивал про первую редакцию uCOS. Кроме того, опрос флагов, по-нашему наверное "полинг", в цикле такого опроса все равно придется вставить ожидание чего-то из арсенала uCOS, иначе такой полинг флагов наглухо заблокирует другие задачи.

Всего Вам Хорошего Ольга

Reply to
Olga Nonova
Reply to
Andy Mozzhevilov

AM>>> Флаги в uCOS-II спасут мать русской демократии.

ON>> А просто в uCOS, без "-II" ? Человек по-моему спрашивал про первую ON>> редакцию uCOS. Кроме того, опрос флагов, по-нашему наверное "полинг", в ON>> цикле такого опроса все равно придется вставить ожидание чего-то из ON>> арсенала uCOS, иначе такой полинг флагов наглухо заблокирует другие ON>> задачи.

В том то и идея, чтобы избавиться от поллинга. Даже если это поллинг семафоров. :-)

AM> Чтение документации также обычно избавляет от выдвижения собственных AM> версий AM> и нелепых догадок.

Да, похоже флаги это то, что нужно. Только функция ожидания у них жестко задана - либо анд, либо ор. Однако можно, наверное, доработать напильником и ввести параметр - маску ожидания. Или набраться наглости и Лаббросу написать.

Reply to
Basil Burtakov
Reply to
Andy Mozzhevilov

BB>> Да, похоже флаги это то, что нужно. Только функция ожидания у них жестко BB>> задана - либо анд, либо ор. Однако можно, наверное, доработать BB>> напильником и ввести параметр - маску ожидания. Или набраться наглости и BB>> Лаббросу написать.

AM> Где реально может потребоваться ожидание более сложной логической функции

Да где угодно. Зависит от построения системы и от задачи. Более общий случай лучше менее общего, тем более, что получается он почти бесплатно.

AM> ? Hасколько я помню, можно делать OR или AND функцию для заданной маски. AM> То есть можно конструировать 2 вида событий: AM> 1.ожидание сброса или установки хотя бы одного из списка (маски). AM> 2.ожидание сброса или установки всех событий из списка (маски).

AM> OS_FLAGS OSFlagPend (OS_FLAG_GRP *pgrp, OS_FLAGS flags, INT8U wait_type, AM> INT16U timeout, INT8U *err)

AM> flags - список (aka маска) ожидаемых флагов AM> wait_type - AM> OS_FLAG_WAIT_CLR_ALL You will wait for ALL bits in 'mask' to be clear AM> (0) OS_FLAG_WAIT_SET_ALL You will wait for ALL bits in 'mask' to be set AM> (1) OS_FLAG_WAIT_CLR_ANY You will wait for ANY bit in 'mask' to be AM> clear (0) OS_FLAG_WAIT_SET_ANY You will wait for ANY bit in 'mask' to AM> be set (1)

Надо в поле flags передавать не признак сравнения, а саму искомую маску поля флагов. А внутри функции OSFlagPend сравнивать ее по условию "равно-не равно" с текущим состоянием.

Reply to
Basil Burtakov
Reply to
Andy Mozzhevilov

AM>>> Где реально может потребоваться ожидание более сложной логической AM>>> функции

BB>> Да где угодно.

AM> Это не ответ. AM> Hапример, я использовал флаги для ожидания любого события из AM> определенного набора в одной задаче, с последующим анализом флагов и AM> обслуживанием этого события. Если бы сервиса флагов не было, нужно было AM> бы искусстенно, например заводить переменную битовых флагов, и связывать AM> ее изменение с семафором. Либо делать queue и пихать в нее не указатели, AM> а прямо маски событий, и разгребать в задаче. Это не очень красиво, AM> флаги удобнее. AM> Реального примера, где бы могло понадобиться ожидание флагов, AM> установленных AM> в определенной комбинации, я придумать не могу.

Например есть 3 релейных сигнала. Приходят асинхронно от внешних датчиков (от объекта управления). Сигналы такие: температура превысила порог, давление привысило порог и заглушка открыта-закрыта. Задачу надо запускать если два сигнала true а третий false.

Типовое решение - в прерываниях устанавливаем семафоры (флаги). А задача ждет нужной комбинации. Причем сложность лог. ф-ции может быть и больше. Не зря у Лабросса до 32 флагов.

BB>> Зависит от построения системы и от задачи. Более общий BB>> случай лучше менее общего, тем более, что получается он почти бесплатно.

AM> Более универсальные решения требуют больших ресурсов, в общем случае. AM> Hужно где-то провести границу, и сказать - что дальнейший универсализм не AM> имеет смысла в 99% случаев, и утяжеление механизма ради 1% неоправдано.

AM>>> ? Hасколько я помню, можно делать OR или AND функцию для заданной AM>>> маски. То есть можно конструировать 2 вида событий: AM>>> 1.ожидание сброса или установки хотя бы одного из списка (маски). AM>>> 2.ожидание сброса или установки всех событий из списка (маски).

BB>> Hадо в поле flags передавать не признак сравнения, а саму искомую маску BB>> поля флагов.

AM> Так и делается.

BB>> А внутри функции OSFlagPend сравнивать ее по условию BB>> "равно-не равно" с текущим состоянием.

AM> Имхо, в полне достаточно тех 4 режимов сравнения, которые заложены. AM> Под них можно уже причесать всю остальную логику установки/сброса флагов.

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

AM> icq 44341220

Reply to
Basil Burtakov
Reply to
Andy Mozzhevilov
Reply to
Dmitry Lyokhin

Здравствуйте, Уважаемый Andy!

Mon Nov 14 2005 10:07, Andy Mozzhevilov wrote to Olga Nonova:

AM>>> Флаги в uCOS-II спасут мать русской демократии.

ON>> А просто в uCOS, без "-II" ? Человек по-моему спрашивал про первую ON>> редакцию uCOS. Кроме того, опрос флагов, по-нашему наверное "полинг", в ON>> цикле такого опроса все равно придется вставить ожидание чего-то из ON>> арсенала uCOS, иначе такой полинг флагов наглухо заблокирует другие ON>> задачи.

AM> Чтение документации также обычно избавляет от выдвижения собственных AM> версий и нелепых догадок.

Я и прочитала в своей версии uCOS, что нет там никаких флагов. А есть варианты функций без ожидания. Что делать? Следовать Вашему нелепому в своем менторстве совету и продолжать изучать документацию?

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.