做法1:使用定时器,在定时器里面读数据,显示到界面
做法2,开一个线程读,再显示到界面
7*24小时运行场景下,两者有区别么?那种好一点?
4 个解决方案
#1
I/O 有数据来(有中断事件通知)时才读,没数据来就什么都不用干。用什么定时器、线程呢?
假设你不管有没有数据来都要定时轮询,那么你猜猜看系统定时器机制还是死循环线程才是定时控制的原生(节省资源、由操作i同底层支持和优化)的呢?
假设你不管有没有数据来都要定时轮询,那么你猜猜看系统定时器机制还是死循环线程才是定时控制的原生(节省资源、由操作i同底层支持和优化)的呢?
#2
没什么区别,定时器相对来说在资源回收等方面比你自己做线程可能要考虑的更合理一些,毕竟微软做了那么多年的东西了。
#3
大佬,他有可能是气象观测,就是要严格定时读取数据记录的,用数据驱动是不符合业务规定的。
#4
其实说白了就是想用定时器又担心定时器不可靠,决定用线程了,多花点时间罢了。谢谢两位
#1
I/O 有数据来(有中断事件通知)时才读,没数据来就什么都不用干。用什么定时器、线程呢?
假设你不管有没有数据来都要定时轮询,那么你猜猜看系统定时器机制还是死循环线程才是定时控制的原生(节省资源、由操作i同底层支持和优化)的呢?
假设你不管有没有数据来都要定时轮询,那么你猜猜看系统定时器机制还是死循环线程才是定时控制的原生(节省资源、由操作i同底层支持和优化)的呢?
#2
没什么区别,定时器相对来说在资源回收等方面比你自己做线程可能要考虑的更合理一些,毕竟微软做了那么多年的东西了。
#3
大佬,他有可能是气象观测,就是要严格定时读取数据记录的,用数据驱动是不符合业务规定的。
#4
其实说白了就是想用定时器又担心定时器不可靠,决定用线程了,多花点时间罢了。谢谢两位