关于djyos的思想理念

wjg198576

我看了版主写的《“以事件为调度核心”是什么意思？》觉得版主以事件的方式来实现操作系统思想是挺新的，从某种程度上来说改变了嵌入式系统的编程模型。我有几点意见，想和版主交流一下~

1、因为我是做嵌入式GUI的，在整个GUI系统中就是基于事件的处理方式，我觉得版主的思路是不是和GUI的思路有点像呢？

2、另一个方面，我比较关心的是嵌入式系统的实时性的问题。我觉得以事件进行的处理是不是要比以线程进行的处理要慢呢？因为至少线程是存在的，如果以事件调用线程的话是不是肯定要比线程对事件的响应要来的慢呢？

3、关于传统嵌入式系统中的堆栈的压栈出栈版主的处理方式是什么呢？

djyos

第一个，关于gui的事件驱动问题，它与djyos是有本质区别的，在于：
gui是线程在等待，等有事件发生后，唤醒事件，并把事件当线程需要处理的数据传递给线程，由线程处理。
djyos的方式是，当事件发生后，进入就绪队列，待事件成为就绪队列中优先级最高的事件后，分配一个线程给该事件，并且由该线程处理事件。两者线程与事件的关系角色是刚好相反的，gui中事件是线程的数据，djyos中线程是事件的数据。

djyos

创建线程因为要调用malloc函数，需要花费有一定的开销，对实时系统来说是有影响，即使不是实时系统，每次事件都创建新线程也是不划算的。djyos对这种状况做了改进，方法是：
    1、紧急事件在登记事件类型的时候创建一个线程，但该线程并不投入运行（不启动），待事件发生并被调度器投入运行时，该线程立即分配给事件，当事件处理完毕以后，如果该事件使用的是该事件类型的最后一个线程，则线程不销毁，待再次发生事件时重复使用。而分配线程只需要一条赋值操作。
    2、无论是紧急事件还是普通事件，如果事件接踵发生，即前一条事件没处理完，后一天事件又发生，则前一条事件处理完毕后，线程并不销毁，而是把线程复位后直接转交给后续事件，重新启动线程后就可以处理后一条事件。转交事件也只需要一条赋值操作。
    3、如果是mark型事件（参见《都江堰操作系统与嵌入式系统设计》的第4.3.13节），则可以把接踵弹出的事件一次处理，无需新开线程。
    情况1和2，都需要在事件发生后，重启线程以处理事件，与传统的线程休眠等候事件发生的操作系统比，启动线程比直接的山下文切换来说，确实要慢一点点（多执行一次int_restore_asyn_signal调用），读者可以理解为：传统方法是汽车怠速等候，乘客上车以后立即开动车子，djyos的方法是汽车熄火等候，乘客上车后点火启动。而当今，CPU的运行速度很快，价格也低至几分钱每MIPS，人力资源成本却在上升，让CPU多干点，让程序员少干点吧！x86系列的CPU主频不断提高，你见到windows的运行速度有提高吗？
    4、djyos的内存管理算法也有巨大的改进，与传统用链表管理堆、使malloc函数调用执行时间不确定而且可能很长相比，djyos执行malloc的时间是确定而且速度很快。比如，在4G的寻址空间内，4k为一页，寻找一个空闲页，无论该空闲页的位置在哪里，无论存储器的当前使用情况如何，定位一个空闲页只需要：4次比较、4次乘法和4次加法。（详情参见《都江堰操作系统和嵌入式系统设计》第7章），然后再用稍长一些的时间来填充内存分配位图，即可完成内存分配。
    通常，堆内存管理被认为是非实时组件，但在djyos中，只要不出现无资源可分配的情况，djyos的堆内存管理是一个实时组件。

djyos

栈的使用上，与传统操作系统是一样的。

pyuozhuo

了解

emmoblin

那是不是可以说djyos的执行的基本单位仍然是线程呢？

djyos

是的，微观上将，执行单位仍然是线程，让程序员无需了解线程，是从宏观上讲的。

old_taoist

那为什么不做一个线程的pool以提高性能呢？

我觉得斑竹还是给出一个benchmark，让用户自己选择要性能还是方便。

superyongzhe

感觉是在偷换概念！