Reentrant функция, Keil, RTX Опции

[toweroff]

Добрый день!

Есть у меня 2 одинаковые задачи. Одинаковые с точностью до записи в один индикатор или другой, проверки этого датчика или этого
Замучился уже отлаживаться в одной задаче, потом копипастить во вторую и сидеть выверять куда там что отправилось и что проверилось

Идея-то давно витала - сделать одну reentrant функцию, в которую в качестве параметра будет валиться только OS_TID, из которой ее вызвали. Но как это грамотно сделать - пока не разбирался, да и смущает еще такой момент. В этой функции активно используются ожидания таймаута или событий. Как эти функции RTX будут вести себя в reentrant-функциях?
Вообще Keil RTX поддерживает такие вещи?

UPD
С кейлом вроде как порядок. (тыц)

Теперь остается узнать, как правильно писать reentrant функции?

[alexeyv]

1. Не используйте статические, глобальные и иные переменные, которые могут повлиять на выполнение кода в другом потоке
2. Локальные переменные д.б. размещены в стеке (выполняется почти всегда по умолчанию)
3. Функция не должна возвращать к-либо глобальные указатели/объекты
4. И вообще, в функцию необходимо передавать только указатель на объект/структуру с данным объектом, в котором должны быть все данные, необходимые для работы, и там же необходимо сохранять все результаты работы функции над данным объектом
5. Если используете объекты синхронизации (мьютексы, семафоры и т.д.) - то необходимо детально проработать их использование - иначе деадлок

Как-то так, если своими словами.

[AlexandrY]

1. Не используйте статические, глобальные и иные переменные, которые могут повлиять на выполнение кода в другом потоке
2. Локальные переменные д.б. размещены в стеке (выполняется почти всегда по умолчанию)
3. Функция не должна возвращать к-либо глобальные указатели/объекты
4. И вообще, в функцию необходимо передавать только указатель на объект/структуру с данным объектом, в котором должны быть все данные, необходимые для работы, и там же необходимо сохранять все результаты работы функции над данным объектом
5. Если используете объекты синхронизации (мьютексы, семафоры и т.д.) - то необходимо детально проработать их использование - иначе деадлок

Как-то так, если своими словами.

Вы здесь описали какое-то чудо, но не реентерабельные функции.
Можно в эти функции и глобальные переменные передавать, можно и глобальные переменные возвращать.
Зато внутри них не должно быть статических переменных.
Обращение к глобальным переменным просто надо защитить.
А вот уже чем защитить есть некоторый нюанс.
Простой запретить прерываний будет плохо отражаться на риалтайме.
Если использовать семафоры, то если функция работает под разными задачами и над разными глобальными переменными, то и семафоры должны быть разные.
И тогда функции надо передать эти семафоры.
Я делаю так. Я семафоры включаю в структуру задачи. Функции же всегда могут определить идентификатор задачи в которой они выполняются. И по этому идентификатору найти свои семафоры. Тоже относится и к очередям и к мьютексам и проч.

[SM]

Зато внутри них не должно быть статических переменных.

Это еще с какого перепуга? Просто их тоже надо защитить как и глобальные, если, конечно, они сами не "средство защиты" (например семафор доступа к ресурсу, с которым работает ф-ция).

[AlexandrY]

Это еще с какого перепуга? Просто их тоже надо защитить как и глобальные, если, конечно, они сами не "средство защиты" (например семафор доступа к ресурсу, с которым работает ф-ция).

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