目录
概要
计算机应用程序一旦与外部设备打交道,发送指令或者接收返回数据时,或多或少都会让程序员感到焦虑,因为设备特性不同,有的通过串口等标准端口传输,有的通过非标准的方式。
非标准端口传输的数据获取,完全取决于设备特性。例如,带存储的IC卡读卡器,读取数据的时间取决于容量和卡CPU性能,上层应用如何第一时间知道卡已经读完呢?再比如,自动化检测设备,测试过程从10几秒到几分钟的都有,多设备同时工作时,如何第一时间发现空闲设备呢?
上述问题有个共同点,就是多设备工作的情况下,第一时间能发现空闲设备并发出请求,进而提升设备利用率,减少等待时间。
案例背景
固定电话故障检测通常使用一种测试头,可以远程访问并启动该设备,该设备根据所提供的号线资料自动找到线路负载,通过电流电压值判断是否异常,并返回这些值和结果。测试头还可以返回“忙”状态,此时应用程序继续等待,并再次访问测试头状态,以便于获取测试头的使用权。
这里有个问题,就是对某个测试任务来说,测试头可能永远处于忙状态,因为碰巧它一直服务于其他任务,该测试任务十分“不巧”,从未捕捉到它空闲状态。
较差的设计思路
这里提供一个最初的设计方案,而且这个方案也运行了多年,运营方等用户一直在默默地忍受着。当时只有两个测试头,测试头数量少,大量的测试任务存在排队现象,但更奇怪的是,经常只有一个测试头在工作,另一个测试头始终在“偷懒”。通过了解程序,其方案如下:
- 测试任务主动请求测试头,如果处于忙状态,则等待;
- 一次测试正常情况约耗时30秒,程序做了计时处理,30秒请求一次;
这样的设计,难怪累的累死,闲的闲死。
改进的设计思路
- 增加一个数据库表,隔离设备和应用程序,用于记录每个测试头的状态:空闲态、忙态;
- 每个测试头都采用独立进程监视测试结果,一旦有了结果,立刻修改状态为空闲态(这里假设设备不会主动发送数据);
- 应用程序不再直接访问测试头,只反复监视测试头状态表,发现空闲态,就锁定;
- 所谓锁定,就是对空闲态的测试头,再使用一个标识表示其已经被占用,所以上一步发现空闲态后,还要判断是否被其他测试任务锁定,这里也采用了锁机制。
小结
改进后,测试头空闲会被立刻发现;两个测试头满负荷运行,再没有偷懒的情况发生。
缺点:增加了状态表和锁机制,需要保证服务器用不异常断电,否则测试头锁处于假的空闲态和假锁定,需要人工恢复才能使用。
标签:状态,外部设备,应用程序,案例,任务,测试,交互,空闲,设备 From: https://blog.csdn.net/workflower/article/details/139892733