程序执行的时机

是否发起一次调用，在什么时候，什么条件下？这也是跟做事情一样，什么条件下能发起（做），
得瞻前顾后！ 常见的条件如：
<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，中等变化的
可以写在配置文件中！