Своевременное получение данных их serial и обработка уже полученных данных

Всем привет

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

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

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

Подскажите, стоит ли прибегать к потокам для реализации данной задачи или есть какие то другие пути ?

0

Сообщение от sonmax Между двумя потоками по любому д.б. синхронизация

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

Сообщение от sonmax Семафор как раз позволяет понять полностью ли данные загружены из пакета в очередь

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

Сообщение от Wolfdp А завязываться на то что поток якобы будет вычитывать с какой-то скоростью -- вообще не правильно

Это условный термин, чтобы показать разное течение операции приема/обработки. Я не говорил что нужно завязываться на скорости...
Очередь, на то и очередь, чтобы заполняться одним "циклом", а считываться другим, со своим собственным ритмом. Какой толк от очереди (зачем она нужна), если по каждому событию приема будет пинаться ивент для обработки? Или - зачем мне ивент, если мне НЕ нужно сейчас делать что-то с данными? Ну, условно.

Сообщение от Wolfdp через элементы синхронизации можно нарулить свое решение и через очереди/каналы

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

Сообщение от Wolfdp Решений тут на самом деле много:

Понятно дело что много. На каждую конкретную задачу - свое решение.

Добавлено через 8 минут
sonmax, в данном случае я говорю о ситуации, когда данные априори есть, т.е. идут постоянно. А их обработка вариативна по времени, типа "когда надо, тогда и лезем в буфер".

Добавлено через 12 минут
Vladimirchy, а вообще, COM-порт - это такая штука, которую не желательно сваливать в некий неконтролируемый режим работы. Здесь, возможны две генеральные ситуации:
1. когда данные отправляет устройство само по себе (когда ему вздумается). В таком случае приемник ничего не решает в части приема: данные пришли - взвелся флаг.
2. когда получение данных происходит по принципу Запрос-Ответ. Здесь уже приемник инициализирует получение данных, когда ему это нужно.
И как правильно подметил Wolfdp, нужно строить логику так, чтобы не было явных простоев/ожиданий приема/обработки.

0

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

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

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

0

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

Сообщение от Vladimirchy самое простое это семафор ?

Нет. Семафор немного для других целей. А вот это верное рассуждение:

Сообщение от Vladimirchy сделать запрос / ответ, получил данные, как только обработались, сообщать о готовности следующего пакета

Тем более, если сам себе и жнец и кузнец: есть возможность написать логику для обоих устройств (МК/ПК). Труднее, когда источник данных - черный ящик, на который нет возможности повлиять и который сыпет битами как из рога изобилия.

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

0

Сообщение от wizard41 Или - зачем мне ивент, если мне НЕ нужно сейчас делать что-то с данными?

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

И честно говоря меня удивляет "ТСу это не надо, слишком сложно". Т.е. работать с COM-портами и многопоточностью он вроде как и умеет, но вот семафор -- уже сложно? На мой взгляд потратить 20 минут на чтение что это такое, как оно работает, и как склеить вместе конкурентную очередь и семафор -- не составит труда.

0

Сообщение от Vladimirchy Я думал о том, что бы не плодить потоки

На данной стадии, скорее всего, ты юзаешь нетовский Serial "по умолчанию", т.о. его работа происходит в том же потоке, что и само приложение. Когда набьешь руку и перейдешь к более серьезным решениям, вдруг обнаружишь, что работа с портом (прием/отправка) уже будут сами по себе работать в своем собственном потоке, отличным от UI/главного потока приложения.
Тут хошь/не хошь придется создавать другой поток для обработки данных, особенно, если она довольно длительная.

Добавлено через 2 минуты
Wolfdp, я к тому, что ТС еще даже толком не выработал (не понял) саму концепцию - как будет работать COM в его системе. А тут его нагружают семафорами в нагрузку... Я не спорю что его можно применить.

Добавлено через 2 минуты

Сообщение от Wolfdp Это сигнал, что в очереди есть данные

Повторюсь: я о ситуации, когда данные там есть всегда. ТС сам же сказал - он не успевает от туда их черпать... А семафор - это уже тонкости вида - как получать уведомления...

Добавлено через 10 минут

Сообщение от Wolfdp И честно говоря меня удивляет "ТСу это не надо, слишком сложно".

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

0

Сообщение от wizard41 Вытащит наружу свойство HasDataExist из класса - вот тебе и флаг что данные есть...

ужс... не нужно учить юные умы такому.

0

Сообщение от Wolfdp ужс... не нужно учить юные умы такому

А, ну да. Нафиг свойства и прочую дребень - давайте сразу семафорить? ))

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

Ситуация несколько прояснилась? Если переложить аналогию?
Я как бы... смотрю от лица ТСа - сейчас я мало смыслю в самом ком-порту и не очень понимаю что такое семафор... Выход: нужно прям сразу бросаться во "все тяжкие" и брать нахрапом )

Добавлено через 10 минут

Сообщение от Wolfdp работать с COM-портами и многопоточностью он вроде как и умеет

Вы не уловили сути: он это обозначает с позиции МК (RTOS) и я четко представляю себе что ТС имеет в виду. В многопоточности же C# он вообще ни как:

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

0

Сообщение от Vladimirchy Собственное устройство на базе МК

Ну ясно. Придётся скорость без контрольного потока снижать или делать диалог ПК с устройством.

0

Сообщение от VladimirU Придётся скорость без контрольного потока снижать или делать диалог ПК с устройством.

VladimirU, вы серьёзно?!
Поймите правильно я ни сколько не хочу принизить ваши знания и навыки, но блин это же первое о чём следовало подумать. Если какая-то свистелка-перделка пуляет данные со скоростью выше той, с которой эти данные могут быть обработаны, то это изначально провальная идея. На простом примере, допустим есть устройство, которое в протоколе UDP пуляет видео высокого качества, а слабый ПК это видео декодирует и отображает. Это очень похоже на ваш случай. А теперь внимание вопрос: как вы думаете что увидит пользователь на экране ПК? Ответ: либо это будет картинка высокого качества, но с прореживанием кадров, либо картинка низкого качества, а возможно и пониженного разрешения, либо вообще черный квадрат и сообщение об ошибке. Всё это обусловлено тем, что ПК не успевает прожевать всё то, что на него сыпется. И если с видеопотоком наработаны решения проблемы (см. выше), то в случае важных данных так делать нельзя от слова совсем.
VladimirU, вам следует применить или в крайнем случае разработать самому простой протокол прикладного уровня с синхронизацией передачи данных. Либо оставить как есть, но тогда алгоритм обработки данных должен уметь пропускать всё то, что не успело обработаться, т.е. частично или полностью выкидывать данные из буфера если пришёл новый пакет, а буфер уже битком.

1

VladimirU, распишите что вы вообще делаете с этими данными? Просто показываете на UI. Куда-то сохраняете? Куда-то отправляете? Мониторите и при каких-то значениях нужно что-то вызвать? Можно ли обрабатывать данные независимо друг-от-друга?

0

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

0

Господа, мне кажется что некоторых уже понесло и ответы пошли не тем людям)
Давайте немного упорядочим тему.

Вопрос изначально был о том, как сделать в языке С#, (если перефразировать) что бы одна функция не тормозила выполнение другой, т.е работали асинхронно, каждая в своём темпе.

То что нужно следить: а пришел ли весь пакет с порт или нет, цел он не цел, всё пришло или нет, это всё понятно, но это не имеет отношения (или прямого отношения) к вопросы асинхронности.
Так же понятно что если лить из ведра в бочку, а черпать ложкой, то бочка заполнится и потечет через края.
Расписывать откуда идут данные в ПО и почему их так много/часто или что делает моё ПО -не имеет смысла, хотя бы потому, что это не имеет отношения к теме, если в какой то момент я пойму, что какая то часть моего кода занимает много времени и нужно как то оптимизировать, то есть смысл создать новую тему и уже разбирать там, не смешивая мух и котлеты.

По всей видимости, у участников складывается автоматические выводы, что если нет знаний в языке С#, то точно не имеет представления ни в чем другом)

Я хорошо владею языком Си и на приличном уровне С++, больше части работаю с МК с использованием ОСРВ и там тоже есть таски, очереди, семафоры, мютексы и т.д и понимание как сделать так, что бы одна медленная функция не влияла на работу всей системы -есть, другое дело какие инструменты имеются в С# и именно это я бы хотел узнать, т.е какие инструменты есть и какими лучше воспользоваться.

Есть какие то различия в цели назначения семафоров в ОСРВ и С# ? если нет, то обрадую: я знаю что такое и для чего семафор, понятно что синтаксис его может отличатся в С#, но это уже детали.

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

И хотел выразить благодарность всем, кто пытается мне помочь)

Добавлено через 4 минуты
Я время не теряю и не жду на блюдечке готового решения, я немного начал вникать и если я правильно понял, для моей задачи можно использовать Асинхронность (async, await) или многопоточность (thread), но я не совсем понял, в чем между ними разница.

0

Сообщение от Vladimirchy но я не совсем понял, в чем между ними разница.

Если коротко, то асинхронность может (если надо) использовать многопоточность. Фишка асинхронных методов в том, что если вызываемый метод успеет отработать в потоке, в котором он был вызван, то он там и выполнится, а если не успеет, то для его выполнения будет взят свободный поток.

Добавлено через 3 минуты

Сообщение от Vladimirchy Вопрос изначально был

Вопрос был, кода для практического исправления не было, отсюда и море воды.

0

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

Да, вам Rius и я в само начале темы скидывали примеры: через конкуретную очередь (именно конкуретная нужна, т.к. в обычная либо выдаст исключения, либо будет терять данные), либо через каналы. Оба подхода подразумевает что у вас есть отедьный поток тупо считывающий сообщения с com-порта и запихивает в очередь, и отдельный поток который эти сообщения вытягивает из очереди и что-то с ними делает.

Сообщение от Vladimirchy Я время не теряю и не жду на блюдечке готового решения, я немного начал вникать и если я правильно понял, для моей задачи можно использовать Асинхронность (async, await) или многопоточность (thread), но я не совсем понял, в чем между ними разница.

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

Добавлено через 6 минут

Сообщение от Vladimirchy Invoke(new EventHandler(/* моя функция для обработки полученных данных */))

Немного слов по этому коду: вы пинаете обработку в UI поток. Это не совсем правильно. UI поток работает со всем интерфейсом последовательно, т.е. все клики, движения мыши и прочие штуки обрабатываются исключительно в нем.

Ещё такой момент -- если какой-то Invoke зависнет -- повиснет вся форма и не будет реагировать ни на что. Причем если там ещё и зависимость от UI действий, то легко поймать дедлок, из-за которого повиснет уже функционал.

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

0