问题描述
大家好首先我介绍这次的项目流程这是个数据采集项目数据源为1553B板卡发下来的我要做的是1、从1553B板卡将数据读出来（每包32个字）2、没个协议包由不定量的字组成，所以我需要在拿到几个包后在通过协议组合拆分成协议包3、显示在主界面4、通过网络发送出去5、也会有一些数据通过1553B发送出去我现在做法是板卡读取是一个线程每读到一个板卡包（<=32个字）就存在一个缓冲区里（list<byte[]>）里另个数据处理线程在从这个缓冲区里while不停的检测这个缓冲区里是否有散包，如果有就拼起来，然后解析，通过委托，在界面显示数据这个缓冲去通过lock一个静态唯一的object上锁网络发送是另一个线程，另一个缓冲区，也是同样方法程序中还会有别的线程和锁，程序写完了，测试过程中感觉不太理想各位有没有好的结构还有lock锁唯一变量这样的方法，对于这种缓冲区合适吗
解决方案
解决方案二：
while不停的检测不太好，应该用EVENT来通知有新数据。实际上你应该有一个通用的有锁，有EVENT的队列Queue<>
解决方案三：
1.我觉得可以把while轮询改成事件机制，例如读板子的线程，完全可以判断是否读完整了，如果读完整了，直接发个事件出去，然解析的线程来解析就行了（就像你的解析线程解析好了，刷新画面一样）至少这样可以可以避免轮询的时间差问题2.多线程同时操作一个数据块，肯定要lock，不然数据会错位3.锁多的话，避免锁里面再去申请锁，很容易造成死锁
解决方案四：
不太理想指的是什么？
解决方案五：
引用1楼rtdb的回复:
while不停的检测不太好，应该用EVENT来通知有新数据。实际上你应该有一个通用的有锁，有EVENT的队列Queue<>
这个我也想过，但是有个问题，我板卡是通过中断响应的，有可能比较快，如果用EVENT来通知，我怕还没处理完，那边又来通知了，这样情况怎么处理，
解决方案六：
引用2楼truediego的回复:
1.我觉得可以把while轮询改成事件机制，例如读板子的线程，完全可以判断是否读完整了，如果读完整了，直接发个事件出去，然解析的线程来解析就行了（就像你的解析线程解析好了，刷新画面一样）至少这样可以可以避免轮询的时间差问题2.多线程同时操作一个数据块，肯定要lock，不然数据会错位3.锁多的话，避免锁里面再去申请锁，很容易造成死锁
我板卡是通过中断响应的，有可能比较快，偶然出现过一次错位帧，我怀疑是处理线程里lock时，把中断给锁了，结果丢中断了，很偶然的情况，有没有什么好办法，是不是用循环队列好些？
解决方案七：
引用3楼cancerser的回复:
不太理想指的是什么？
不太理想指的是感觉浪费资源，比如WHILE，我正准备试下上面二位说的事件机制。还有感觉几个线程共享一个缓冲不太安全，因为数据是板卡中断得到的，这种锁的机制，可能会影响到中断，不知阁下有没有好的方法分享
解决方案八：
你这么做没啥问题，没啥事至于优化问题，我到是有几个小意见1.读板和散包的处理可以合并，最好是定量或定长处理比如，没读到10个包，进行一次处理，一次显示，一次发送，当然这10个包也未必满足一条数据，你可以自己估计步长，估算下几个包够吃一顿的，然后下锅。这样触发点只在读取数据的方法中，满足一盘上一盘，另一个监视就变成了触发。其他的监视优化的好都可以改成触发的2.这种轮询，如果你使用定时轮询的话，建议改成定间隔轮询，这样系统时间不会被跑满。如果用while死循环的话每次也要sleep哪怕只是个sleep（0）。3.不要怕用锁，数据同步这是必须的，还有就是征用对象要查一下是不是线程安全的，如果是，msdn往往提供更好的同步方法
解决方案九：
引用7楼cancerser的回复:
你这么做没啥问题，没啥事至于优化问题，我到是有几个小意见1.读板和散包的处理可以合并，最好是定量或定长处理比如，没读到10个包，进行一次处理，一次显示，一次发送，当然这10个包也未必满足一条数据，你可以自己估计步长，估算下几个包够吃一顿的，然后下锅。这样触发点只在读取数据的方法中，满足一盘上一盘，另一个监视就变成了触发。其他的监视优化的好都可以改成触发的2.这种轮询，如果你使用定时轮询的话，建议改成定间隔轮询，这样系统时间不会被跑满。如果用while死循环的话每次也要sleep哪怕只是个sleep（0）。3.不要怕用锁，数据同步这是必须的，还有就是征用对象要查一下是不是线程安全的，如果是，msdn往往提供更好的同步方法
你的建议非常好，我一会测试一下感谢，还有个问题，我是不是可以用信号量或事件来触发线程，比如够一包了，我就去触发解析线程。然后解析完成后，自动循环回去再等待。现在我不太明白的是，如果在触发了，我开始执行后，还没有执行完，板卡数据又来了，再次触发，将会发什么什么，还会不会被触发了
解决方案十：
按照你的程序，包一够了就触发解析线程是没问题的，但是你需要注意的是，如果你这样做，每次接收到信号量，你都要进行一次验证（包够不够，数据完整性啥的），以保证触发的正确至于没执行完，再次触发，这个完全取决于你自己的控制逻辑，按照你的思路，在满足包够触发的前提下，怎么处理都无所谓，因为你一次触发的是一组完整性数据，不会对其他数据造成影响。在触发开始时，将这组数据移出你的缓存，避免对其他数据造成影响，单独处理这组数据。
解决方案十一：
引用9楼cancerser的回复:
按照你的程序，包一够了就触发解析线程是没问题的，但是你需要注意的是，如果你这样做，每次接收到信号量，你都要进行一次验证（包够不够，数据完整性啥的），以保证触发的正确至于没执行完，再次触发，这个完全取决于你自己的控制逻辑，按照你的思路，在满足包够触发的前提下，怎么处理都无所谓，因为你一次触发的是一组完整性数据，不会对其他数据造成影响。在触发开始时，将这组数据移出你的缓存，避免对其他数据造成影响，单独处理这组数据。
我明白你的意思，昨天睡觉的时候有个想法，你看成熟不，就是散包的打包在硬件中断线程中做，每组好个包，我触发一个任务，用来处理解析，发送，显示，处理完成后，结束任务，这样的话，并发任务触发就可以解决吧，但这样做开销是不是很大
解决方案十二：
引用10楼luran82的回复:
Quote: 引用9楼cancerser的回复:
按照你的程序，包一够了就触发解析线程是没问题的，但是你需要注意的是，如果你这样做，每次接收到信号量，你都要进行一次验证（包够不够，数据完整性啥的），以保证触发的正确至于没执行完，再次触发，这个完全取决于你自己的控制逻辑，按照你的思路，在满足包够触发的前提下，怎么处理都无所谓，因为你一次触发的是一组完整性数据，不会对其他数据造成影响。在触发开始时，将这组数据移出你的缓存，避免对其他数据造成影响，单独处理这组数据。我明白你的意思，昨天睡觉的时候有个想法，你看成熟不，就是散包的打包在硬件中断线程中做，每组好个包，我触发一个任务，用来处理解析，发送，显示，处理完成后，结束任务，这样的话，并发任务触发就可以解决吧，但这样做开销是不是很大
这要看你的数据量，触发频率以及监视逻辑的复杂程度。如果怕开销大，你可以加大打包判断的步长，也就是如我最开始所说，10个散包累加并判断一次就没问题了。甚至组好后的包都可以多个进行一次发送显示。基础逻辑定下来后，其他逻辑功能的运行周期自行判断就可以了。要求严格的话，这里需要不同步长的测试，不过没啥过分的要求考虑到机器的性能，差不多就成。
解决方案十三：
引用11楼cancerser的回复:
Quote: 引用10楼luran82的回复:
Quote: 引用9楼cancerser的回复:
按照你的程序，包一够了就触发解析线程是没问题的，但是你需要注意的是，如果你这样做，每次接收到信号量，你都要进行一次验证（包够不够，数据完整性啥的），以保证触发的正确至于没执行完，再次触发，这个完全取决于你自己的控制逻辑，按照你的思路，在满足包够触发的前提下，怎么处理都无所谓，因为你一次触发的是一组完整性数据，不会对其他数据造成影响。在触发开始时，将这组数据移出你的缓存，避免对其他数据造成影响，单独处理这组数据。我明白你的意思，昨天睡觉的时候有个想法，你看成熟不，就是散包的打包在硬件中断线程中做，每组好个包，我触发一个任务，用来处理解析，发送，显示，处理完成后，结束任务，这样的话，并发任务触发就可以解决吧，但这样做开销是不是很大
这要看你的数据量，触发频率以及监视逻辑的复杂程度。如果怕开销大，你可以加大打包判断的步长，也就是如我最开始所说，10个散包累加并判断一次就没问题了。甚至组好后的包都可以多个进行一次发送显示。基础逻辑定下来后，其他逻辑功能的运行周期自行判断就可以了。要求严格的话，这里需要不同步长的测试，不过没啥过分的要求考虑到机器的性能，差不多就成。
感谢你的耐心回复，今天我测试了下并发任务，CPU彪的很厉害，准备用事件提醒的方式，不过，我琢磨了一下没有太好的方法，只有共享一块内存，然后用锁去交互，不知有没有什么好方法
解决方案十四：
cpu高啊？你这个只有一种可能性就是运算频率太高了。多线程程序也要受cpu运算的限制，多线程的目的就是充分利用系统资源（cpuio等），所以高就对了。这也是我开始就让你合并线程并加大步长的原因。没啥好办法。高点正常，现在差不多的PC咋不得4核啊，你要是两核的PC在DEBUG下测试不高都神了哈。你试试release出来在一台裸机上测试看看。cpu不怕高重要的是稳。
解决方案十五：
没有能有耐心仔细看你的问题描述，单就个别比较容易理解的描述说一下：引用4楼luran82的回复:
这个我也想过，但是有个问题，我板卡是通过中断响应的，有可能比较快，如果用EVENT来通知，我怕还没处理完，那边又来通知了，这样情况怎么处理，
如果你在死循环中去“处理完，然后继续循环”，占用的时间只会更多，不会更少。如果事件触发是从同一个线程发起的，那么不可能“没处理完、又来了通知”，因为只有事件处理完，你的用于触发事件的程序才可能执行到。而如果是在子线程中触发事件的，那么你的事件处理程序应该在最必要的某几条语句上使用“lock(一个static的对象)”，让子线程按队列操作。但是这仅仅在这几条最必要的语句上才形成互锁（从而尽量较少互锁的时间几率），绝不是在整个事件处理程序上、或者输入整个数据上形成什么过分粗放的“同步”。引用5楼luran82的回复:
我板卡是通过中断响应的，有可能比较快，偶然出现过一次错位帧，我怀疑是处理线程里lock时，把中断给锁了，结果丢中断了，很偶然的情况，有没有什么好办法，是不是用循环队列好些？
这就是循环的不可取之处。循环处理一次如果需要15毫秒，但是你的底层的两次事件间隔恰好在14毫秒，那么你的轮询程序就无法查询到第二次事件状态。如果你的程序是用事件方式来相应底层中断事件，你的事件处理程序在子线程中处理事件本身，那么每当底层中断时你的程序仅需要花费1、2毫秒事件来启动子线程然后就立刻结束了，不会丢掉任何一次底层中断通知的。引用10楼luran82的回复:
我明白你的意思，昨天睡觉的时候有个想法，你看成熟不，就是散包的打包在硬件中断线程中做，每组好个包，我触发一个任务，用来处理解析，发送，显示，处理完成后，结束任务，这样的话，并发任务触发就可以解决吧，但这样做开销是不是很大
避免轮询，而改为事件驱动。避免在“大的”程序上进行同步加锁，而仅仅在事件处理程序的个别语句上才使用lock。好的并行处理流程可以让你的处理程序更“流畅”10倍并且从来不丢数据，那么多花1%的代码复杂度让系统自动进行线程池管理，这完全值得。你的CPU使用率应该稍稍大一点点（而不是大很多），但是程序应该显得更流畅、毫无阻塞感、毫不丢数据。如果你得CPU占用很大，那么通常都是“轮询”造成的，你为了“不丢数据”于是拼命缩短循环周期，造成了烧烤CPU空转的现象。