程序执行的时机

是否发起一次调用,在什么时候,什么条件下?这也是跟做事情一样,什么条件下能发起(做),
得瞻前顾后! 常见的条件如:
<1> 输入数据是否准备好?
<2> 输出是否有足够的空间保存?
<3> 是否有足够的线程进程资源可以使用?
<4> 共享对象(如数据) 是否被占用,给共享的数据对象定义一个flag,若处于busy则不得使用?
<5> 或者是否接收到了可以发起调用的通知?
<6> 所依赖的对象是否给出了合适的结果,若没有则不发起本次调用?
<7> 当前的输入是否已经在之前已经计算过,若之前已经有,则没有必要发起本次调用?

等等 ! 满足条件发起调用才是合适的,这些条件是需要思考的。
因此一个程序块的执行不只有某种顺序依赖,上一个依赖执行完成之后便可执行,
所以程序的执行时机收到多方面的影响,这种时机的检查,最好与计算逻辑分离,
因为时机千变万化,计算逻辑相对固定!

以上的条件可以包装成一个事件的消息,当所有条件满足,即定义的事件发生,发送
出一条关于事件描述的消息给回调(handler),回调提取消息内容进行执行!完全
有消息进行驱动!

两程序块AB除了执行顺序是前后关系外,其他条件相同,放在一个执行块(线)才是可能适当的?
a. 当AB同线时,若B的执行还有额外条件,当得不到满足时,会同时对A进行阻塞?所以这也是执行(代码)
分离的参考点。对执行条件进行分组,最大努力,只要有条件即执行?这里是否涉及最优调度算法?
b. 当AB同线时,若B的执行相当耗时,这也会阻塞 A 的执行!
c. 两程序块AB,当程序块A,所有的执行条件满足,仅仅是因为B占用了其去路而不能执行,则说A被B阻塞了;
当程序块A在执行而且没有执行完成,而B依赖A的结果,导致B不能执行,这应该不能说A阻塞了B,A没有阻塞B,而且A在其完成后可以立即通知B; 这是我
认为对阻塞的确切理解。不知道大家是否有更好的理解?
最关键的: 条件满足的程序应当被即刻执行,满足执行条件的模块应该立马被通知,这样才能最好最快响应,最大程度利用资源!

变化最大的部分参数化,哪怕是代码块;最不变的部分代码化,哪怕是一个常数如pi,中等变化的
可以写在配置文件中!

原文地址:https://www.cnblogs.com/wdmx/p/9524655.html