去线程化与智能调度

多线程是个问题。

当多个任务真正并发执行的时候，等待时间最大化。不管在对内存的利用上还是任务的实时性上都是不利的。公平是效率是矛盾的。

加了优先级就不一样了，但是优先级不能得到实时反馈的任务信息，需要动态调整的话也不好做。

根子在io。io的不确定性太大。

另外一方面，多线程起源于多道程序设计，多道程序设计也起源于分时。多道程序设计如果不考虑分时的公平性需求的话也是多余的，多个任务可以轮着上，效率更高。但是这个在多个长线程的需求下失效。有些任务是永远也完成不了的，它们需要分时。特别是操作系统任务，长的不得了。于是分时碉堡了，没人动得了它。

这就是现在的多任务。

我决定换个角度来考虑，把处理器看成一个主动找活干的人。

归根结底，只要所有的活都被干了，那么就无所谓活有没有干完这个问题了。或者，只要处理器已经满负荷，那么其余的都不是问题。

并且我觉得这个的系统粒度更小一点，所以能提供更细致的任务区分。

线程粒度太粗。

提供更细致的任务区分是建立智能调度的基础。因为线程没有办法被描述。比如一个文件访问明显是一个不同的任务，单独拿出来做可能要好的多。而且不会因为io缓慢阻塞原来的线程形成内存溢出。很多时候io恰恰是一个线程的最大堆栈点。并且一个多阶段io的线程将长期占据内存不放。

这个改革将使传统的编程模型全部实效。J2EE所有的api都将废弃。J2EE跟线程模型太粘。它是典型的方法调用型计算。加上面向对象，内存很吃亏。多线程跑不动就在这里：io加对象，线程给卡死了。

这个其实也不是大问题。

我觉得只要处理器能动就不是问题。大多数时候并没有这个问题。

那么为什么还要智能调度呢？

不要。我只是想把多核给真正跑起来。也许小粒度的任务定义能提供更好的并行性能。

关键任务之间的关系怎么处理。怎么去掉任务的时序？有两个问题：一是单任务的划分，一是多任务的并行。这样是否意味着一个多级任务模型？这样就复杂了肯定fail掉。

必须要划分，否则不可能做到单任务的并行。对线程进行流水线改造。那你又想，为什么线程不行。线程不符合现实情况：现实并发任务并不多。当没有并发的时候不能充分利用机器的计算能力。

子任务间的依赖将是自适应的：条件没到就做不了。索性去做别的。

这样就真正去掉了线程：不允许定义线程。没有线程。操作系统将全权掌握系统的运行而不只是调度线程。任务退后，系统站出来，像批处理，一切由操作系统说了算。用户提交的只是真正的“任务”，而不是一个“程序”。

另一方面，分时其实是迫不得已：

处理器被占用时不可能做任何真正的智能调度。因为它没有周期。

但是多核可以。多核随时可以动态调度。这样也迫使将任务降级，使之完全听命于操作系统而不是只能用个时钟中断时不时地看一下优先级动了没有。

关键是任务降级。成为鱼腩。是任务是操作系统的鱼腩，不是操作系统是线程的鱼腩。要夺回操作系统的权利。

去线程化的关键则在于强调处理器的第一性地位。让处理器跳出来，形成一个worker。而不是线程的服用。把它看成是工作的真正完成者而不是线程。让线程的概念退下，不需要它了。单处理器下必须线程来做到分时，现在不需要了。分时是为了并发，复用，现在自然可以并发复用了。多任务不等于并发。所以分时离开单处理器环境已经没有用。

另一件关于线程的事就是它嵌入了运行时的语义。操作系统对他能做的就只有做与不做，不可能衍生其它的操作。这个限制了任务的语义发展。比如顶多发展到优先级，进一步则很困难。去掉这个运行时语义它就成了鱼腩，基本原因就是这个概念离底层太近。从这个角度还可以看出，线程于系统安全的发展也很不利：它给予程序太多权利。去掉它的运行时特性就给了操作系统空间去做所有的事情：你往你的空间退，你陈述一个任务，我来完成它。这是个理想，我想把系统安全化。安全话最好的方法就是收缩任务的语义，让他远离系统。这个就是最小化原则的应用：不让一个人惹事最好的办法就是收缩与他的接口。收缩接口就是对他的信任解除。收缩它的相对行为空间！

在系统核心嵌入神经学习网络，建立评价机制，让系统自己学习而不是用概率来解决问题。使系统屈从于评价系统。加上规则系统，可以建立一定的智能调度。在任务中加入评价api与数据服务，让用户自己产生调度评价。这样达到以及动态达到最佳调度。可以对系统进行充分的训练再投入使用也可以让他在实践中学习。它将学得非常快并且迅速达到最佳状态。从这个角度考虑，关键要形成正确合理粒度的资源概念。 --这是个理想。