4．2）单线程与多线程的对比：随着硬件技术的发展，CPU的速度越来越快，相对来说，串口是低速设备，向数据库服务器进行一次查询也要花去不少的时间。根据木桶理论，一个木桶能放多少水，取决于最短的那一块木板。打个比方,就像我们的上网速度与我们计算机的CPU的速度没有什么关系。因为瓶颈在连接速度。
类似的，对串口通信的上位机而言，多数时间是CPU在等待串口读写操作的完毕和数据库查询结果的返回，而不是相反。如果使用单线程，其流程基本是，查询接收缓冲区里是否有等待接收的数据，如果有，则接收数据，处理数据，向数据库服务器发出查询请求，然后等待数据库服务器返回的查询结果（注意：此间，整个进程可能被阻塞于此），接到查询结果之后，再做相应的处理。处理完毕后，再对串口接收缓冲区进行查询。
使用单线程的流程图略。这种方法在一些对实时性能要求不高的场合是可行的，但它的缺点也是显而易见的。现在，我们设想这么一种情况，当进程正在等待数据库服务器返回结果的时候，又有一个门控控制机发来了串口信号，可是它必须在串口的接收缓冲区里等待。因为整个进程由于等待数据库服务器的返回结果而阻塞于此了。在处理完手头的事情之前，CPU没有时间去接收串口传来的数据。这样，系统分配给该进程的CPU时间片，就这样白白的浪费掉了。设想一下：如果发生数据大量高速涌入的情况，比如说,在3秒钟内，有20个门控控制机发出请求。那么，会出现什么情况？同一时间，进程只能去处理一个请求，其它的信号必须等待。数据库查询所花的时间越长，问题就越严重。在门控系统里，这样的问题或许不重要。因为出现这种情况的概率并不高，即便出现了，让用户在门外多等几秒钟也算不上什么大事。但在其它的一些场合，比如工控系统，这样的就会因为不能在规定的时间内做出响应而误事。
这是题外话，本文在这里不做进一步的讨论。（待续）
这位仁兄讨论问题的态度蛮真诚的.
从我这个角度来看,实在是很难看出问题.
但是有一点比较难理解.
就是你如果使用一个ADO连接的话,它的颈瓶效应会在连接处.如果建立多个连接的话~~
在产生新的连接时,可能查询的结果已经回来啦.只有在系统启动的时候,内部预建十或二十个连接.在有ADO请求时,使用空闲的一个.如果全部占用,就等吧.
愚见,不要见笑.
就是你如果使用一个ADO连接的话,它的颈瓶效应会在连接处.如果建立多个连接的话~~
在产生新的连接时,可能查询的结果已经回来啦.只有在系统启动的时候,内部预建十或二十个连接.在有ADO请求时,使用空闲的一个.如果全部占用,回复贴子：
temp(全局变量) 回复于2001-5-16 14:03:00
事关学位，欢迎多提批评意见！
seesi(不是我想骗你，是我不知道怎么才能不骗！) 回复于2001-5-16 14:06:00
还可以
temp(全局变量) 回复于2001-5-16 16:10:00 4．2）单线程与多线程的对比：随着硬件技术的发展，CPU的速度越来越快，相对来说，串口是低速设备，向数据库服务器进行一次查询也要花去不少的时间。根据木桶理论，一个木桶能放多少水，取决于最短的那一块木板。打个比方,就像我们的上网速度与我们计算机的CPU的速度没有什么关系。因为瓶颈在连接速度。
类似的，对串口通信的上位机而言，多数时间是CPU在等待串口读写操作的完毕和数据库查询结果的返回，而不是相反。如果使用单线程，其流程基本是，查询接收缓冲区里是否有等待接收的数据，如果有，则接收数据，处理数据，向数据库服务器发出查询请求，然后等待数据库服务器返回的查询结果（注意：此间，整个进程可能被阻塞于此），接到查询结果之后，再做相应的处理。处理完毕后，再对串口接收缓冲区进行查询。
使用单线程的流程图略。这种方法在一些对实时性能要求不高的场合是可行的，但它的缺点也是显而易见的。现在，我们设想这么一种情况，当进程正在等待数据库服务器返回结果的时候，又有一个门控控制机发来了串口信号，可是它必须在串口的接收缓冲区里等待。因为整个进程由于等待数据库服务器的返回结果而阻塞于此了。在处理完手头的事情之前，CPU没有时间去接收串口传来的数据。这样，系统分配给该进程的CPU时间片，就这样白白的浪费掉了。设想一下：如果发生数据大量高速涌入的情况，比如说,在3秒钟内，有20个门控控制机发出请求。那么，会出现什么情况？同一时间，进程只能去处理一个请求，其它的信号必须等待。数据库查询所花的时间越长，问题就越严重。在门控系统里，这样的问题或许不重要。因为出现这种情况的概率并不高，即便出现了，让用户在门外多等几秒钟也算不上什么大事。但在其它的一些场合，比如工控系统，这样的就会因为不能在规定的时间内做出响应而误事。
ginkgoboy(彝族舞曲) 回复于2001-5-16 16:14:00 蛮好蛮好...我不是计算机专业的...没写过...好遗憾....
temp(全局变量) 回复于2001-5-16 16:15:00
这个毕设论文关系到我的学位，请大家指正。
temp(全局变量) 回复于2001-5-16 17:04:00
（接前文）为了提高CPU的利用率，为了保证程序的实时响应能力。我在这里使用了多线程技术，串口监视线程，数据分析线程，动态建立的数据处理线程可以‘同时’工作。注意，在单CPU的系统里，这样的‘同时’是一种错觉，实际上，还是多个线程轮流使用CPU。如前问所述，CPU的速度已经很快，系统效率的瓶颈不在CPU，而在串口和数据库服务器。所以，整个进程的效率会提高不少。使用多线程的流程图：略。需要注意的是，使用多线程技术并不能节省CPU的操作，相反，它还要在切换上下文中花一些时间。多线程只是提高了CPU的利用率而已。当线程开得过多的时候，CPU要在各个线程中不停的切换，可能会出现整体运行效率降低的情况。
这是题外话，本文在这里不做进一步的讨论。（待续）
temp(全局变量) 回复于2001-5-16 18:43:00
谁能指出写毛病？只要说了就有分。
谢过了。
111222([email protected]) 回复于2001-5-16 18:47:00
不幽默啊...能不能写得搞笑一些啊？？
BaoYu(雨路) 回复于2001-5-16 19:04:00
呵呵.
这位仁兄讨论问题的态度蛮真诚的.
从我这个角度来看,实在是很难看出问题.
但是有一点比较难理解.
就是你如果使用一个ADO连接的话,它的颈瓶效应会在连接处.如果建立多个连接的话~~
在产生新的连接时,可能查询的结果已经回来啦.只有在系统启动的时候,内部预建十或二十个连接.在有ADO请求时,使用空闲的一个.如果全部占用,就等吧.
-------------------------我测试过呀,两组查询结果是交错打印出来的。可见，是可以并行的。
-------------------------就是你如果使用一个ADO连接的话,它的颈瓶效应会在连接处.如果建立多个连接的话~~
在产生新的连接时,可能查询的结果已经回来啦.只有在系统启动的时候,内部预建十或二十个连接.在有ADO请求时,使用空闲的一个.如果全部占用,等吧.
-------------------------
我测试过呀,两组查询结果是交错打印出来的。可见，是可以并行的。
1、如果只是把数据的接收和处理拆分成两个线程，效果还不如直接在一个线程中接收再处理。
你要做成一对多或多对多的处理方式，这是常用的技术。
2、不要考虑mscomm控件，它不可靠。
2. 如果串口数据来的太快，串口线程发出N个消息，接收线程来不及处理，消息会不会丢失？
消息队列中的最大消息数依赖于window机制， 且消息的实时性值得怀疑，
不如自已定义缓冲区，然后用事件(event)通讯来得稳妥。
3. 多线程间的同步多讲一点。
这该怎么应对呢？
俺的毕设也做的串口通信，可是做得巨烂，有几个问题请教！