sheduler and micro-sheduler problem

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View

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

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

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

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

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

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

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

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

Вопросы:

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

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

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

Спасибо
Basil.


sheduler and micro-sheduler problem
Fri Nov 11 2005 14:04, Basil Burtakov wrote to All:

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

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

icq 44341220


sheduler and micro-sheduler problem

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

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

 AM> icq 44341220

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


sheduler and micro-sheduler problem
Fri Nov 11 2005 14:52, Basil Burtakov wrote to Andy Mozzhevilov:

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

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

начиная с версии 2.52 в ucos есть такой сервис - флаги
http://www.ucos-ii.com/contents/support/downloads/an1007a.pdf

icq 44341220


sheduler and micro-sheduler problem
Fri Nov 11 2005 14:04, Basil Burtakov wrote to All:

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

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

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

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

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

  man select || WaitForMultipleObjects


Re: sheduler and micro-sheduler problem

Hello, Basil!
You wrote to All on Fri, 11 Nov 2005 12:04:40 +0000 (UTC):


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

   Да, да, я знаю :-) Это многократно описаная у классиков проблема - задачам А
и В
требуются ресурсы 1 и 2. Задача А захватывает ресурс 1 и ждет освобождения
ресурса 2, задача В захватывает ресурс 2 и ждет освобождения ресурса 1 -
классический
deadlock.
  Поэтому тут дело не в средствах ОС или "шедулера", а в правильном назначении
семафоров ресурсам. Задача, захватив один ресурс, не должна ждать освобождения
другого - надо отработать этот ресурс, освободить его и только после этого ждать
освобождения другого. Если же тебе во что бы то ни стало необходимы сразу два
ресурса,
то должен быть объявлен семафор, сидетельствующий о занятости сразу обоих
ресурсов,
и работать через него. Конечно, может быть написана програма с нарушением этого
правила, но это потенциальные грабли, и ждать поддержки ОС такого режима, мне
кажется,
не стоит. Такие ситуации разруливаются только вручную, применительно к
конкретной задаче.
  Если совсем никак не разруливается (такое возможно в очень сложных системах) -
можно
ограничить время ожидания ресурса, так сделано, например, в Win - т.н.
"спин-блокировка" может
быть не более 25 мс, иначе снимается. Но опыт показывает, что злоупотребление
подобным
способами разрешения конфликтов рано или поздно все равно приводит к BSOD :-)

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

With best regards, Sergey Zabelin.  E-mail: snipped-for-privacy@telemak.ru



Re: sheduler and micro-sheduler problem
Sat Nov 12 2005 01:15, Sergey Zabelin wrote to Basil Burtakov:

 
 SZ> Задача А захватывает ресурс 1 и
 SZ> ждет освобождения ресурса 2, задача В захватывает ресурс 2 и ждет
 SZ> освобождения ресурса 1 - классический deadlock.
 SZ> Поэтому тут дело не в средствах ОС или "шедулера", а в правильном
 SZ> назначении семафоров ресурсам.
 SZ> Такие ситуации разруливаются только вручную,
 SZ> применительно к конкретной задаче.

 Ресурсы делаются в виде серверов. Задачи встают в очередь запросов
 к серверам. Все успешно разруливается.

 VLV

 "Зачем стадам дары свободы? Их надо резать или стричь"  (Пушкин)


sheduler and micro-sheduler problem
Здравствуйте, Уважаемый Basil!

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


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

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

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


sheduler and micro-sheduler problem
Sat Nov 12 2005 20:15, Olga Nonova wrote to Basil Burtakov:

 BB>> объединеных какой-либо логической функцией.

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

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

wbr, Andy (2:5080/76.6)


sheduler and micro-sheduler problem
Здравствуйте, Уважаемый Andy!

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

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

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

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


sheduler and micro-sheduler problem
Mon Nov 14 2005 09:37, Olga Nonova wrote to Andy Mozzhevilov:


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

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

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

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

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

icq 44341220


sheduler and micro-sheduler problem

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

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

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

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

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


sheduler and micro-sheduler problem
Mon Nov 14 2005 11:26, Basil Burtakov wrote to Andy Mozzhevilov:

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

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

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

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

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

icq 44341220


sheduler and micro-sheduler problem

 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 сравнивать ее по условию "равно-не равно"
с текущим состоянием.


sheduler and micro-sheduler problem
Mon Nov 14 2005 13:50, Basil Burtakov wrote to Andy Mozzhevilov:

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

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

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

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

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

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

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


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

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

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

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

icq 44341220


sheduler and micro-sheduler problem

 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


sheduler and micro-sheduler problem
Mon Nov 14 2005 14:47, Basil Burtakov wrote to Andy Mozzhevilov:

 AM>> Реального примера, где бы могло понадобиться ожидание флагов,
 AM>> установленных
 AM>> в определенной комбинации, я придумать не могу.

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

Если ты имеешь ввиду в этом примере, что 2 первых сигнала == 1, а третий
сигнал == 0, но ничего не стоит проинвертировать третий сигнал в нужном
разряде флагов, и свести задачу к ожиданию события установки всех флагов.
Если ты имеешь ввиду ожидание установки любых двух флагов из трех (или в
более общей постановке, любых K из N), то это уже не совсем задача
комбинаторной логики, то есть она конечно может таковой быть,
но в общем случае более оптимально решается таблично. Такой возможности
в сервисе флагов ucos нет, и я считаю, что такая возможноть излишня, во
всяком случае я не могу придумать примеров, где это может потребоваться.

wbr, Andy (2:5080/76.6)


sheduler and micro-sheduler problem
Здравствуйте, Уважаемый Basil!

Mon Nov 14 2005 14:47, Basil Burtakov wrote to Andy Mozzhevilov:

 AM>> в определенной комбинации, я придумать не могу.

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

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

Самое простое и надежное видится так- задача сканирования, которая с
максимально возможным периодом времени просто опрашивает все три сигнала
(полинг без всяких прерываний!) и сравнивает с порогами. Когда выполняется
нужное условие - посылает ОДИH семафор на запуск другой, аварийной задаче.
Затем останавливает сканирование и переходит в режим ожидания перезапуска.  

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


sheduler and micro-sheduler problem
Hello Andy.

Mon Nov 14 2005 15:07, Andy Mozzhevilov wrote to Basil Burtakov:

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

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

Можно callback на пользовательскую функцию анализа флагов.  Для ОС - почти
бесплатно. :)


Dimmy.


sheduler and micro-sheduler problem
Здравствуйте, Уважаемый 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, что нет там никаких флагов. А есть варианты
функций без ожидания. Что делать? Следовать Вашему нелепому в своем менторстве
совету и продолжать изучать документацию?

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


Site Timeline