[Kopa 0]

Forth был достаточно интересный проект... Но:

- к чему-либо, что имеет отношение к функциональности ОС РВ (см. имя темы) - он просто неуместен;

- он именно был, у него было мощное community ... но всё это в прошлом - книжка то показанная тоже 1989г. - 23 года, ... как-то напомнило даже из Иосифа Бродского:

- Форт и сейчас, достаточно интересный проект:)

- Зачем "мощное" communty для "экспериментальных" разработок?

 

P.S. Многоядерные процессоры с низким энергопотреблением-Архитектура процессоров SEAforth Как в этом случае "трансформируется" понятие и функционал операционной системы? (сейчас у данных "процессоров" 144-ядра Процессоры GA144)

48-ядерный процессор Intel для "облачных" вычислений. ( 07.12.2009 новости уже около 3-х лет

и что далее?)

Изменено 28 сентября, 2012 пользователем Kopa

[Olej 0]

- Форт и сейчас, достаточно интересный проект:)

Кому и кобыла - невеста.

Так, кажется, это звучало в первоисточнике? :1111493779:

 

[Владимир Е. Зюбин 0]

Доброго здравия всем присутствующим!

 

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

 

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

 

И еще ладно, если задач всего с десяток... а если их тысяча?

 

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

 

[Артём__ 0]

И еще ладно, если задач всего с десяток... а если их тысяча?

Это вы в контексте МК говорите?

Так тысяча это мало, нужно тысяч 10 для начала...

 

 

 

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

Зачем передавать управление, если событие не произошло?

Когда произойдёт тогда и нужно передавать (в соответствии с приоритетом).

[_Pasha 0]

а это непроизводительные расходы: планировщик передает управление некоторой задаче, задача проверяет факт наступления события, а событие не наступает...

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

Вы очень вовремя (как по мне) затронули этот вопрос. Хотел даже тему создать, но спрошу здесь, уже в данном контексте.

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

time = get_tick();
wait(process2->end_packet || (tick_diff(time) > TIMEOUT));

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

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

Если с несчастным process2->end_packet все ясно: можно обернуть все геттером или функцией process2->end_packet() внутри которой спрятать добавление "вопрошающего" в список клиентов, которых надо будить при наступлении события end_packet,

то с таймерами дела обстоят похуже: поллинг никуда не девается, можно лишь уменьшить его накладные расходы.

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

Вот и интересны мнения аудитории по данному кругу вопросов.

[ViKo 1]

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

Плохо понял. У задачи есть переменная, назовем "регистр событий". События, которых задача ожидает, задаются в самой задаче, а устанавливаются в других задачах, которым требуется запустить на выполнение первую. Проверяются же события самой ОС. Если заданное событие наступило, планировщик запустит задачу, если нет более приоритетных.

[Владимир Е. Зюбин 0]

Это вы в контексте МК говорите?

Так тысяча это мало, нужно тысяч 10 для начала...

 

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

 

Что касается десяти тысяч задач, то мне это представляется нереальным для ОС, как впрочем, и

тысяча...

 

Подскажите, где такое встречается, было бы интересно рассмотреть...

 

Зачем передавать управление, если событие не произошло?

Когда произойдёт тогда и нужно передавать (в соответствии с приоритетом).

 

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

 

Например, у вас есть модуль на восемь логических входов... 16 примитивных событий (положительный фронт/отрицательный фронт)... казалось бы... но это же не все возможные события... а если эти входы взаимосвязаны (для простоты это 8-ми разрядный АЦП)... сразу же получаем 256*2 событий. А если на интересуют события типа "вход i-ый в нуле И положительный фронт j-го входа,состояние остальных входов не интересует"? начинается уже комбинаторика... А если вас интересуют временные интервалы и события типа "вход i-ый не сбросился по истечению трех секунд"? и т. д. При этом события, "интересные" с точки зрения конкретной задачи могут изменятся в зависимости от происходящего... это ведь тоже реалии жизни при создании управляющих алгоритмов.

 

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

[_Pasha 0]

А если на интересуют события типа "вход i-ый в нуле И положительный фронт j-й,состояние остальных входов не интересует"? начинается уже комбинаторика...

 

Мы можем пользоваться такими ср-вами, которые позволят осуществить проверку совокупности условий только один раз, когда один из термов меняется. При выполнении условий управление передается в поток, к-рый "заказал" триггер.

 

А если вас интересуют временные интервалы и события типа "вход i-ый не сбросился по истечению трех секунд"? и т. д.

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

Изменено 30 сентября, 2012 пользователем _Pasha

[Владимир Е. Зюбин 0]

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

time = get_tick();
wait(process2->end_packet || (tick_diff(time) > TIMEOUT));

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

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

<...>

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

 

Совершенно согласен с вашими рассуждениями... я тоже не представляю какого-то рационального решения при попытке переноса обработки событий на уровень ОС (я так понимаю, под "реалтаймовостью" подразумевается использование ОС)...

 

Может, специалисты в "реалтаймовости" нам тут подскажут...

[Владимир Е. Зюбин 0]

Мы можем пользоваться такими ср-вами, которые позволят осуществить проверку совокупности условий только один раз, когда один из термов меняется. При выполнении условий управление передается в поток, к-рый "заказал" триггер.

 

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

 

Не могли бы вы дать ссылку, чтобы можно было ознакомиться с таким подходом?

 

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

 

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

 

 

 

Плохо понял. У задачи есть переменная, назовем "регистр событий". События, которых задача ожидает, задаются в самой задаче, а устанавливаются в других задачах, которым требуется запустить на выполнение первую. Проверяются же события самой ОС. Если заданное событие наступило, планировщик запустит задачу, если нет более приоритетных.

 

Я тоже плохо понимаю ваш вопрос. "У задачи есть переменная..." это я понял, а вот "События, которых задача ожидает, задаются в самой задаче".. уже, увы, не понял... записывает в эту переменную код события? а дальше? в общем, теряюсь в догадках... В общем, прошу прощения...

[Виктория 0]

Мы можем пользоваться такими ср-вами, которые позволят осуществить проверку совокупности условий только один раз, когда один из термов меняется. При выполнении условий управление передается в поток, к-рый "заказал" триггер.

...

 

Эти средства встроены в операционную систему? Я тоже не знаю, было бы интересно узнать

 

[Артём__ 0]

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

 

Наверное имелось в виду что-то такое:

 

void UART_RxC_Isr()
{
    NewByte.SignalISR(); // байт принят
}

void Task()
{
    while (1) {
        NewByte.Wait(); // событие которое ожидает задача
    }
}

[_Pasha 0]

Не могли бы вы дать ссылку, чтобы можно было ознакомиться с таким подходом?

 

Ссылка - здесь и сейчас :) Даже если я изобретаю "лисапед", обращаю Ваше внимание на такую вещь. Допустим, какой-либо процесс X ожидает комбинации условий (булевых переменных) (a==1)&&(b==0)&&(b_prev==1), что означает вход a в высоком уровне, вход b - переход 1->0, от других процессов. Вопрос детский: что мы можем сделать, чтобы уменьшить количество проверок, то бишь поллинг? Мы должны сообщить поставщику данных, чтобы он разбудил процесс Х именно при наступлении указанного условия, т.е. делегировать проверки тому процессу, который отвечает за прием a,b или сам процесс Х должен быть поставщиком для себя. Во втором случае проблема решена: никакого поллинга, но есть вопрос: а когда ему брать данные? Т.е. избавились от асинхронности-пришли к временным интервалам. И что лучше из трех вариантов - асинхронная обработка с поллингом, синхронная с семафором либо вообще слияние процессов - выбирать надо по месту.

 

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

 

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

 

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

[i-mir 0]

Как раз сейчас разбираюсь с работой ПЛИС и доказательством безопасности

сего устройства в условиях грозовых перенапряжений.

 

ИМХО задача поллинга превышающая разумные пределы для последовательных

контролеров должна быть устранена переходом на параллельную логику, те

же ПЛИС. Действиетльно последовательный контроллер больших систем уже

не вытягивает, т.к. он есть банальным воплощением машины Тьюринга, пусть

и мощной. Ваша система рано или поздно "наткнется" на ограничение, т.к.

все данные (а в реальности они все параллельные) нужно прокачать сквозь

узенькое игольное ушко - счетчик адреса контроллера. Это так называемый

функциональный предел. Дальше никуда.

 

Ядерщики первыми начали пользовать ПЛИСы для своих нужд - думаю на

сегодня это одно из наиболее перспективных решений по работе со сложными

системами.

 

 

 

[juvf 10]

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

 

time = get_tick();
wait(process2->end_packet || (tick_diff(time) > TIMEOUT));

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

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

Совершенно согласен с вашими рассуждениями... я тоже не представляю какого-то рационального решения при попытке переноса обработки событий на уровень ОС (я так понимаю, под "реалтаймовостью" подразумевается использование ОС)...

 

Может, специалисты в "реалтаймовости" нам тут подскажут...

 

Что такое поллинг? Это ожидание одной задачей несколько событий?....

Вот как ВАШ простой пример выглядел бы в FreeRTOS

if( xSemaphoreTake((process2_end_packet_Flag , TIMEOUT) == pdPASS )
{//дождались события
}
else
{//недождались события, вышел TIMEOUT 
}

можно ждать и несколько событий.... пример на µС/OS

uint8_t err;
OSFlagPend(statusFlags, P2_END_PACKET | P2_BREAK_PACKET, OS_FLAG_WAIT_SET_ALL, TIMEOUT, &err);
switch(err)
{
    case OS_NO_ERR:
        //были УСТАНОВЛЕНЫ флаги P2_END_PACKET и P2_BREAK_PACKET до таймаута TIMEOUT
        break;
    case OS_TIMEOUT:
    default:
        //сработал таймаут или какая-то др. ошибка
        break;
}

ОС у задачи заберёт процессор (задача уснёт на мертво) в момент обращения к методу OSFlagPend() или xSemaphoreTake(). Как толко наступит нужное(ые) событие(я) или пройдет TIMEOUT времени с момента засыпания, то ОС сразуже сама разбудит задачу и передаст ей управление (при условии что нет незаблокированных более приоритетных задач).