上图中JobLevel优先级为4的标红任务(左侧y轴高度值为14),是多个竞争同一公共资源的多个设备之间的快速任务联动。各个任务之间,没有宽度为一个扫描周期的间隔缝隙,任务是相对紧凑执行的。
任务的参与数量是按照当前在线的设备数量来变化的。如有设备上线,任务就会加入,如果设备下线,任务就退出了。
JobLevel级别为2的任务(左侧y轴高度值为12),也是按照设备数量变化。区别是,各个任务之间有宽度为一个扫描周期的间隔缝隙。也就是它会回过头执行,并不按照实例代码扫描的先后次序。
这里仅展示一个具体应用个例。相同的调度策略,可以用于给定且持续变化的约束边界范围内的多对象动态行为规划。现实中具有类似抽象本质的功能需求,还是有一些的。
把一个模块的全部功能需求,按照不同的优先级进行分类。采用通用架构,在模块内部实现。让共性和个性元素,得到充分隔离,便于随意扩展和包含丰富的健壮性考量,便于诊断。
上图中大多数任务的JobLevel级别为1(左侧y轴值11)。上图中并未包含JobLevel级别为3的任务(y轴值13),本例中L3级别任务不具有周期性。
另注:一个任务存在不同等级的JobLevel,并不代表它在条件满足的前提下,一定会获得实际优先执行的权力。
可以人为设定:即便是高优先级别的任务,在一些特定场景下,照样按照低级别来执行。第二张图即表明了这个问题。Job Level不一定等于User Level。
这就是调度的灵活性,任何东西都不必必须固定为某种不变的模式。一切都可以动态调整。