sotot1988

Добрый день.

Хотел узнать мнение по важной теме : Организация доступа задач к разделяемым ресурсам.
Суть такова:
есть система, включающая в себя две задачи и набор параметров, одна задача эти параметры записывает, вторая считывает. Параметров, например 100 штук, каждый представляет из себя структуру с полями: название, идентификатор, значение. Так как число параметров большое, я думаю, что их надо хранить в глобальной области памяти, а не передавать от задачи к задаче. Первая задача обновляет значение этих параметров, вторая считывает их. В реальной системе задач читающих и пишущих намного больше. Как бы Вы организовали доступ в такой ситуации?

Пока нашел три варианта: с помощью критических секций, с помощью мьютексов и с помощью задачи с единоличным доступом к ресурсу, все операции идут через нее(гайткипер).

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

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

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

Таким образом вроде ситуация разруливается, если приходят прерывания, то они обрабатываются вовремя. Единственное это подобрать размер очереди. Задача может писать до 50 запросов в секунду. Использую stm32f407 на 168МГц. Системный тик 1 мс.

Интересно перенять опыт:)

Спасибо.

@YvomSh

Зачем мьютексы, можно же использовать параметры типа int или ftoot, которые записываются одномоментно?
Пока параметры независимы и меняются только из одной задачи никакая специальная организация доступа не нужна.
Если для каких-то параметров требуется синхронное изменение или запись из разных задач, там и нужно использовать мьютексы (по одному на группу параметров).

50 запросов в секунду, если нет сложной обработки - это ни о чём.
На данном контроллере любой из предложенных вариантов позволит за секунду делать тысячи операций записи.
А тик можно разогнать и до 0.1мс без заметных накладных расходов. И даже 1000 мьютексов не займут всю память.

0

sotot1988

Тип значений может быть произвольный, в теории и строки и double.
Дело в том, что это пример сферический в вакууме, в реальной системе может совпасть момент чтения и записи параметра, в итоге будут получены некорректные данные.
От большого количества мьютексов тоже хотелось бы избавиться в связи с большой, в реальности, системой, где почти вся память будет занята, а мьютекс это + 112 байт (по аналогии с семафорами).

@YvomSh

В теории - может и так, но на практике лучше избегать типов double, в том числе для возможности одновременного чтения-записи.
В целях экономии ресурсов, регулярно использую даже half ftoot (16 bit).

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

0

@oomomstir

Типовое решение в "большом" программировании - single writer multiple readers lock - там и несколько типовых реализаций описано.

Ну это, разумеется, если вы можете себе позволить использование блокировок (как правило, при не слишком большой загрузке системы решения с блокировками эффективнее, чем lockfree, но дают куда меньше гарантий для худшего случая - т.е. для жёсткого realtime вам может понадобиться lockfree)

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

Да, и насчёт блокировок по одному параметру - для начала лучше обойтись без этого. Посчитайте, какой процент времени у вас занимает _запись_ параметров - исходя из того, что лок надо брать на минимально возможное время, лишь бы сразу после лока данные были уже корректны. Если не адски много - то и не париться вообще. Если много - вам придётся тщательно изучать задачу, чтобы понять, какие куски данных можно блокировать независимо (чтобы не оказалось, что после изменения переменной A прежнее значение переменной B использовать уже нельзя). Но попытка сразу делать что-то сложнее одного readers-writer lock - типичная premature optimizotion.

0

sotot1988

Спасибо за помощь.
Пока остановился на двух вариантах, мьютексы использовать под группу параметров или использовать задачу-gatekeeper для доступа к параметрам.

@MrYurom

СКОЛЬКО?!!

0

@MostirOtixiy

У нас по работе мы сделали центральную "базу данных" - gatekeeper по вашему.
У нее определен интерфейс для чтения и записи элементов, и одномоментно можно обратиться только к одному элементу. Через мьютекс бинарный в функциях доступа к элементам.
Мне кажется - тут больше плюсов чем минусов - доступ отовсюду - база центральная, одна в системе (sinlgeton), ограничение доступа, проверка границ значений при записи, и можно, как мы сделали, сделать ограничение доступа через коммуникации (уарт там или езернет) через своего рода гейтвей.
Ну и это все на С++ и паттерны так что можно подсунуть этой базе данных либо еепром в качестве хранилища c проверкой CRC и прочими плюшками, либо просто кусок оперативки либо блок констант из флэша.
А метаданные (перечень переменных (имена их), границы значений, тип доступа, место хранения, и т.д.) генерится отдельным генератором.
Есть возможность "подписаться" на изменения. т.е. получать уведомления при изменении той или иной переменной.

Из минусов - пока что только то, что одновременно читать нельзя, только по очереди. Хотя я думаю, это можно организовать тоже, но будет более ресурсоемко.
Чтобы ускорить доступ - имена переменных - 4 символа - кастятся к 32битному значению и по нему ищется в массиве метаданных запись.

Но это все, если система все же сложная, а если что то мелкое - то, мне кажется, оно того не стоит - такой монстр туда запихивать.

0

@oomomstir

MrYurom, я тоже охренел, пошёл читать доки. В FriiRTOS мютексы крайне тяжеловесны: судя по всему, они реализуют не просто стратегию "кто первый встал, того и тапки", а пытаются справедливо делить ресурсы и учитывают приоритеты.

При необходимости защищать по отдельности 100500 областей памяти - можно исхитриться и обойтись одним мютексом и пачкой interlocked переменных.

0

@itysiy

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

0

@MostirOtixiy

Угу. Закрыты.
Но по описанию вроде все должно быть более менее понятно.
А как его реализовать конкретно - это уже дело вкуса. :)
Так как это все на С++, то там интерфейсы используются и паттерны Singtiton да Observer.
Самой базе данных при инициализации передаются интерфейсы Storage для ROM, ROM, EEPROM.
БД так же имеет доступ к метаданным (можно тоже организовать через интерфейс, но я сделал их читабельными из БД напрямую) и знает размеры в каждом из хранилищ. Каждое хранилище знает, где (ROM/ROM/EEPROM/Ftosh/...) и сколько данных хранить, но не знает, какие это данные. Но знает их CRC, и всю канитель с CRC делает. Т.е. БД об CRC не заморачивается, а просто читает и пишет из/в хранилище.

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

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

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

Само собой - БД это не та БД типа MySQL или прочих. А просто хранилище заранее определенного количества переменных, коих количество или метаданные налету менять не получится - только перекомпилированием всего и вся.

Мьютекс стоит в функциях БД чтения и записи.

Между БД и средствами связи железки с внешним миром (уарт, езернет, ...) стоит SettingsManager который еще в добавок контролирует уровень доступа к каждой конкретной переменной, и ставит этот доступ в соответствии с текущим паролем, т.е. просто так настройки железки не поменяешь, если пароля не знаешь.

БД сама по себе singtiton в системе, и доступна отовсюду, так сказать. Этакая глобальная переменная :)

Ну как то так.
В принципе ничего сложного.

Updt:
Через некоторое время, как допилю свой Логический Анализатор и Генератор Сигналов по совместительству - выложу у себя на сайте исходники, там тоже такая же БД с некоторой ограниченной функциональностью используется.
Но не прям сейчас - еще все сырое там и часто вешается.

0