[simark1979 0]

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

Столкнулся с такой проблемой.

Имеется очередь, элементом которой является структура с глобальными настройками системы.

Через xQueuePeek  различные потоки получают из этой очереди актуальные настройки системы. Всё работало великолепно.

Потихоньку я наполнял структуру новыми элементами в какой-то момент очередь перестала работать (в причинах пока глубоко не разбирался)

Пробовал увеличить размер TOTAL_HEAP_SIZE - не помогло.

 

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

Подскажите как правильно организовать потокобезопасное хранение и доступ к глобальным настройкам?

 

 

Изменено 5 марта, 2019 пользователем simark1979

[jcxz 182]

43 минуты назад, simark1979 сказал:

Подскажите как правильно организовать потокобезопасное хранение и доступ к глобальным настройкам?

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

[haker_fox 60]

1 hour ago, simark1979 said:

в какой-то момент очередь перестала работать (в причинах пока глубоко не разбирался)

Что значит перестала? Какие ошибки возвращаются от API? Или данные портятся? Вы в очередь кладёте саму структуру или указатель на неё?

1 hour ago, simark1979 said:

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

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

1 hour ago, simark1979 said:

потокобезопасное хранение и доступ к глобальным настройкам?

Грамотное использование API уже гарантирует потокобезопасный обмен данными между задачами. Если они только читаются, то да, как выше заметил уважаемый @jcxz, заботиться ни о чём не нужно. Если данные могут быть изменены, то для обеспечения атомарного доступа можно использовать критические секции, например. Всё зависит от задачи.

[simark1979 0]

42 minutes ago, jcxz said:

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

Я не написал, но запись тоже имеется.

[jcxz 182]

Только что, simark1979 сказал:

Я не написал, но запись тоже имеется.

Тогда, как писал уважаемый haker_fox:

19 минут назад, haker_fox сказал:

Если данные могут быть изменены, то для обеспечения атомарного доступа можно использовать критические секции, например. Всё зависит от задачи.

Очень сильно зависит от задачи. Про которую Вы тоже забыли написать.

[simark1979 0]

Я собственно, пока хотел не столько разобраться почему у меня перестала работать очередь, а выяснить какие бывают подходы для организации доступа (r/w) к глобальным настройкам.
Поэтому извините, что дал неполную информацию.

Сейчас мне нужно определиться с подходом.

 

[simark1979 0]

Ребята, извините.

Дело не очередях, у меня в логике косяк, взаимная блокировка произошла.

[uriy 4]

я бы мютекс использовал

[haker_fox 60]

8 minutes ago, uriy said:

я бы мютекс использовал

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

[Arlleex 131]

11 часов назад, uriy сказал:

я бы мютекс использовал

А мьютекс исключает взаимную блокировку? Нет, не исключает.

[ivan24190 0]

On 3/5/2019 at 7:40 PM, simark1979 said:

Я собственно, пока хотел не столько разобраться почему у меня перестала работать очередь, а выяснить какие бывают подходы для организации доступа (r/w) к глобальным настройкам.
Поэтому извините, что дал неполную информацию.

Сейчас мне нужно определиться с подходом.

 

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

P.S. если интересно почитайте руководство к FreeRTOS "Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide" в частности главу "7.4 Gatekeeper Tasks". Данный файл можно найти на официальном сайте.

Изменено 6 марта, 2019 пользователем ivan24190

[simark1979 0]

On 3/6/2019 at 9:49 PM, ivan24190 said:

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

P.S. если интересно почитайте руководство к FreeRTOS "Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide" в частности главу "7.4 Gatekeeper Tasks". Данный файл можно найти на официальном сайте.

Спасибо, посмотрю)