一个关于最近数据采集项目结构的问题，希望赐教

Question

数据采集 结构 C# 多线程 

Answer 1

while 不停的检测不太好，应该用EVENT来通知有新数据。实际上你应该有一个通用的有锁，有EVENT的队列Queue<>

Answer 2

1. 我觉得可以把while轮询改成事件机制，例如读板子的线程，完全可以判断是否读完整了，如果读完整了，直接发个事件出去，然解析的线程来解析就行了（就像你的解析线程解析好了，刷新画面一样）
至少这样可以可以避免轮询的时间差问题
2. 多线程同时操作一个数据块，肯定要lock，不然数据会错位
3. 锁多的话，避免锁里面再去申请锁，很容易造成死锁

Answer 3

这个 我也 想过 ，但是 有个问题，我板卡是通过中断响应的，有可能比较快，如果用EVENT来通知，我怕还没处理完，那边又来通知了，这样情况怎么处理，

Answer 4

我板卡是通过中断响应的，有可能比较快，偶然出现过一次错位帧，我怀疑是处理线程里lock时，把中断给锁了，结果丢中断了，很偶然的情况，有没有什么好办法，是不是用循环队列好些？

Answer 5

不太理想指的是感觉浪费资源，比如WHILE，我正准备试下上面二位说的事件机制。还有感觉几个线程共享一个缓冲不太安全，因为数据是板卡中断得到的，这种锁的机制，可能会影响到中断，不知阁下有没有好的方法分享

Answer 6

你这么做没啥问题，没啥事
至于优化问题，我到是有几个小意见
1.读板和散包的处理可以合并，最好是定量或定长处理
比如，没读到10个包，进行一次处理，一次显示，一次发送，当然这10个包也未必满足一条数据，你可以自己估计步长，估算下几个包够吃一顿的，然后下锅。这样触发点只在读取数据的方法中，满足一盘上一盘，另一个监视就变成了触发。其他的监视优化的好都可以改成触发的
2.这种轮询，如果你使用定时轮询的话，建议改成定间隔轮询，这样系统时间不会被跑满。如果用while死循环的话每次也要sleep哪怕只是个sleep（0）。
3.不要怕用锁，数据同步这是必须的，还有就是征用对象要查一下是不是线程安全的，如果是，msdn往往提供更好的同步方法

Answer 7

我明白你的意思，昨天睡觉的时候有个想法，你看成熟不，就是散包的打包在硬件中断线程中做，每组好个包，我触发一个任务，用来处理解析，发送，显示，处理完成后，结束任务，这样的话，并发任务触发就可以解决吧，但这样做开销是不是很大这要看你的数据量，触发频率以及监视逻辑的复杂程度。如果怕开销大，你可以加大打包判断的步长，也就是如我最开始所说，10个散包累加并判断一次就没问题了。甚至组好后的包都可以多个进行一次发送显示。基础逻辑定下来后，其他逻辑功能的运行周期自行判断就可以了。要求严格的话，这里需要不同步长的测试，不过没啥过分的要求 考虑到机器的性能，差不多就成。  感谢你的耐心回复，今天我测试了下并发任务，CPU彪的很厉害，准备用事件提醒的方式，不过，我琢磨了一下没有太好的方法，只有共享一块内存，然后用锁去交互，不知有没有什么好方法

Answer 8

cpu高啊？你这个只有一种可能性就是运算频率太高了。
多线程程序也要受cpu运算的限制，多线程的目的就是充分利用系统资源（cpu io等），所以高就对了。
这也是我开始就让你合并线程并加大步长的原因。没啥好办法。高点正常，现在差不多的PC咋不得4核啊，你要是两核的PC在DEBUG下测试不高都神了 哈。
你试试release出来在一台裸机上测试看看。cpu不怕高 重要的是稳。

Answer 9

没有能有耐心仔细看你的问题描述，单就个别比较容易理解的描述说一下：如果你在死循环中去“处理完，然后继续循环”，占用的时间只会更多，不会更少。如果事件触发是从同一个线程发起的，那么不可能“没处理完、又来了通知”，因为只有事件处理完，你的用于触发事件的程序才可能执行到。而如果是在子线程中触发事件的，那么你的事件处理程序应该在最必要的某几条语句上使用“lock(一个static的对象)”，让子线程按队列操作。但是这仅仅在这几条最必要的语句上才形成互锁（从而尽量较少互锁的时间几率），绝不是在整个事件处理程序上、或者输入整个数据上形成什么过分粗放的“同步”。这就是循环的不可取之处。循环处理一次如果需要15毫秒，但是你的底层的两次事件间隔恰好在14毫秒，那么你的轮询程序就无法查询到第二次事件状态。如果你的程序是用事件方式来相应底层中断事件，你的事件处理程序在子线程中处理事件本身，那么每当底层中断时你的程序仅需要花费1、2毫秒事件来启动子线程然后就立刻结束了，不会丢掉任何一次底层中断通知的。避免轮询，而改为事件驱动。避免在“大的”程序上进行同步加锁，而仅仅在事件处理程序的个别语句上才使用lock。好的并行处理流程可以让你的处理程序更“流畅”10倍并且从来不丢数据，那么多花1%的代码复杂度让系统自动进行线程池管理，这完全值得。你的CPU使用率应该稍稍大一点点（而不是大很多），但是程序应该显得更流畅、毫无阻塞感、毫不丢数据。如果你得CPU占用很大，那么通常都是“轮询”造成的，你为了“不丢数据”于是拼命缩短循环周期，造成了烧烤CPU空转的现象。