[firstvald 20]

Кто какие приемы использует для работы с данными общими для нескольких потоков?

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

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

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

[juvf 10]

У меня такой прием - Не использую общих данных. Не то что, для нескольких потоков, даже для одного потока. Не должны разные таски использовать общие данные. Каждая задача занимается своим делом и своими данными и нефиг ей лезть в чужие данные. Для передачи сообщений в др. таски использую механизмы ОС (флаги, эвенты, месаджбоксы, слоты/сигналы).  

[jcxz 192]

26 минут назад, firstvald сказал:

Кто какие приемы использует для работы с данными общими для нескольких потоков?

Бессмысленный вопрос. Способ будет зависеть от алгоритма обработки этих данных. Можно придумать 100500 разных вариантов, удобных для каждого конкретного случая.

 

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

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

[firstvald 20]

смысл поста?

[EdgeAligned 55]

Чтобы понять, как поступить, надо разобраться, что будет происходить.

Допустим, задача А читает данные, задача В записывает данные в общую область. Переключение задач А и В может произойти в любое время, в том числе и до окончания операций записи или чтения этими задачами. А значит, следует запретить запись/чтение другой задачей, пока задача, начавшая эти операции, не завершит их. 
Вспоминаем, какой инструмент из API RTOS обладает таким функционалом. Это - мьютекс. Mutually Exclusive - взаимное исключение. Намек понятен? 🙂 Ассоциация с ключом от туалета - захотел в туалет, взял ключ на вахте, попал в "комнатку". Другой чел не сможет уже попасть в нее, пока ты не вернул ключ на вахту после "большого/малого дела". Возвращаешь ключ - другой берет его и идет в туалет. А ты, если тебе вдруг надо вернуться, теперь будешь ждать. Тут всё понятно? Ключ - мьютекс - он один. Желающих взять ключ - сколько угодно, но в "кабинку" зайдет только тот, кто взял ключ.

[firstvald 20]

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

7 hours ago, juvf said:

У меня такой прием - Не использую общих данных. Не то что, для нескольких потоков, даже для одного потока. Не должны разные таски использовать общие данные. Каждая задача занимается своим делом и своими данными и нефиг ей лезть в чужие данные. Для передачи сообщений в др. таски использую механизмы ОС (флаги, эвенты, месаджбоксы, слоты/сигналы).  

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

[amaora 21]

Для чего разбивать работу с одним набором данных по разным задачам? Чтобы потом они сидели в блокировке на семафорах и по итогу выполнялись последовательно?

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

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

[uriy 5]

Можете описать какие у вас есть таски и какие интерфейсы? 

Мне кажется удобным для каждого интерфейса выделять таск.

[firstvald 20]

9 hours ago, amaora said:

Для чего разбивать работу с одним набором данных по разным задачам? Чтобы потом они сидели в блокировке на семафорах и по итогу выполнялись последовательно?

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

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

такой вариант есть и имя ему основной цикл.

8 hours ago, uriy said:

Можете описать какие у вас есть таски и какие интерфейсы? 

Мне кажется удобным для каждого интерфейса выделять таск.

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

[x893 40]

На одном процессоре - чистый махохизм.

[firstvald 20]

так все приборы так устроены. это еще хорошо ,  freertos и 66 мегагерц. а начинал делать на dallas  .  это 51 , но с 4 мегагерцами после 110592 кварца.