Пару вопросов по scmRTOS (да наверно в целом по РТОС).

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

2. Предположим есть две функции, которые имеют дело с портом. Первая настраивает его скорость и прочее. Вторая... например просто делает enabled/disabled для порта, в принципе неважно. Функции могут вызываться каждым из процессов. По идее надо тело функции обрамлять mutex.Lock() mutex.Unlock(). Но ситуация такова, что например вторую функцию может вызывать не только любой из процессов непосредственно, но и первая функция (понятно, что в рамках какого то процесса). То есть при настройке порта я хочу еще сразу делать enable port. И при этом получается, что процесс в рамках вызова первой функции блокирует мютекс и вызывая вторую функцию, опять видит mutex.Lock и блокирует сам себя, навечно. Чую, тут самые такие азы всего этого дела, но не понимаю как поступают в таких случаях?

Спасибо

Зачем?


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

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

Понимаю. Но внутри этой функции и идет собственно оьращение к ресурсу. А точнее обращение к регистру, которым включается/отключается UART.

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

Я понимаю, что тут скорее всего ошибка проектирования... или чето в этом духе. Но хочется понять как правильно в такой ситуации поступать.

Незачем. Если вы захватили ресурс, то работаете с ним, а потом освобождаете.


Если эта функция вызывается из другого процесса (задачи), то dxp все описал подробно с вытеснениями.
Или вы эту функцию хотите вызывать из первой функции, которая уже получила доступ к ресурсу, но из того же процесса?
Так просто делать не надо, напишите код по другому, иначе у вас получится deadlock.

Поэтому-то и надо защищать ресурс, а не функцию. Тогда и проблем таких не будет.


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

Что касается конкретно этого Вашего случая, то тут есть основания полагать, то и мутекс никакой не нужен - обращение ведется к регистру, все обращение - это две-три инструкции процессора. Незачем в этой ситуации использовать мутексы - для предовращения нарушения совместного доступа просто поместите этот код в критическую секцию и все. Это будет и быстрее, и компактнее, и проще. Мутекс имеет смысл использовать, если ресурс требует значительного времени при обращении - массив, например, обработать. На эту тему в доке на стр 77 есть замечание (совет).

Именно так!! Теперь понял, то есть борьбы с этим как таковой нет. Перепроектирую.
Спасибо.


Да спасибо за советы. Перечитаю.

Из Exec() можно достучаться до YourProc.Priority и передавать его как параметр в функцию.

Для dxp. Это может понадобиться, например, при отладке для вывода лога.

Тогда уж проще для отладки добавить в public TKernel что-то вроде TPriority GetCurPriority() const { return CurProcPriority;} Не нужно будет тащить лишний параметр. (шепотом) А dxp не скажем что исходник трогали
Есть еще один вариант - делаем класс, производный от process и в нем функцию, возвращающую Priority.

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


Ага, конспираторы, блин.


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