[自制操作系统研究]分享一下, 我为什么想要做一个操作系统. 细节.

linuxfellow

原来你是做研究的，我以为你只是想做一个操作系统玩玩，失敬了。你有没有发表的文献，请把链接贴上来，让我拜读拜读

MJK2012

回复 2# linuxfellow


研究不是我的工作, 只是业余兴趣  :wink:

这是我上一年的自创语言的链接, http://www.cnblogs.com/parallet/archive/2011/06/16/parallet.html 已经停了大半年了.

本来计划是今年开始做HTML5的东西的, 但是无意之中让我看到了Linux的源代码, 然后和同事谈起了一些关于智能家电的事情.

加上最近对这方面的各种研究, 我也发现了做一个OS并不是难事. (当然, 做一个OS, 和做好一个OS, 是两回事)

现在已经不是1991了, 对比起Linus当初写Linux的环境来说, 现在可以说是有着各种各样的全新的资源.

那么编写一个OS, 还真有一种穿越剧带着现代的知识'穿越到过去秒杀各种小号'的感觉..

上面是说笑而已. 我现在的知识是学回来的, 与前人的自创的知识, 还拍马都比不上了.

不过, 根据自己的想法, 重组一个兼容POSIX的操作系统, 移植各种C库, 这还真的很可行.

而最难的部分, 也许就是驱动程序了. 也许我会提供各种兼容的API接口, 去让移植LINUX的驱动也更容易吧.
(这一点也许也不简单, 因为我有一种预感, 就是这个底层的结构被改得面目全非后, 并不一定就能提供兼容的接口了)

kouu

MJK2012 发表于 2012-03-14 11:07
--

其实我上一年是研究异步并行编程语言的, 我创出了一种新的概念式编程.

请教一下楼主：帖子的前半部分说现有的线程机制不满足要求，需要创新；后半部分却又列举了一堆不知道跟这个出发点是否相关的feature……
那么到底是什么样的需求得不到满足，又需要怎样的创新呢？

MJK2012

回复 4# kouu


修正. 测试了一下Windows7 64位 , 我发现Windows7已经对stack进行全面的优化, 不用到的部分不占内存, 线程的调度速度也变得非常快. 唯一缺点就是单进程只支持8192个线程了.. 所以, 我提到的那些优点, 比起Windows7 64位, 会削弱了很多很多.


你好. 后面的feature的第#5,#6条是描述前面说的逻辑的.

我举个简单的例子来说明这种情况.

现在这个世界, 都是一个开放的世界了.

服务器与服务器之间, 大多数提供着越来越多的通信接口.

例如现在各大网站开放的OAuth体系, 允许其他网站互相进行用户信息的传递.


很多服务器程序编写OAuth代码, 依然是使用阻塞的方式.

例如 客户端请求服务器A, 服务器A要向服务器B请求OAuth , 那么在服务器A上, 就会造成很多线程被挂起.

鉴于现今的OS体系, 如果服务器A挂起一万条线程在等待数据, 那么内存就会被占据10个G用来做这些线程的STACK.

而现今的OS, 要管理越多的线程, 管理成本就会迅速攀升. 线程的切换效率就会急剧下降 .


对于很多专用的服务器程序来说, 通过编写异步IO处理代码, 例如使用完成端口, 就能解决这个问题.

但是编写异步IO的代码很不直观, 很难理解, 调试起上来也非常难.


所以现在我的那个OS, 目标就是要从OS的基础上解决这个问题.  

目标是 既能使用简单易懂的编程方式, 又能实现完成端口一样的高性能.

让本来可以负载1万条线程的服务器, 通过简单的移植, 变成可以负载10万条异步任务.  (1万/10万只是一个理论上的比喻, 没实测)

kouu

MJK2012 发表于 2012-03-15 10:14
5 - 吸纳最新的多任务队列与并行机制, 引入新概念, 实现 进程-线程-XX 的结构, 每个XX有单独的STACK.
......
鉴于现今的OS体系, 如果服务器A挂起一万条线程在等待数据, 那么内存就会被占据10个G用来做这些线程的STACK.

每个XX都有单独的STACK，那STACK不是没有省下来么？只是省些线程的描述结构而已。但是这些节省的空间跟XX的描述结构引入的空间又是抵消的。

其实说白了就是进行一层用户级线程的包装，让开发者使用同步IO的方式，享受异步IO的效果。

MJK2012 发表于 2012-03-15 10:14
主要的研究方向是将来的智能家电的应用, 与智能家电共同前进, 时机合适.

这个好像跟挂起一万条线程的服务器大相径庭啊...

MJK2012

回复 6# kouu


修正. 测试了一下Windows7 64位 , 我发现Windows7已经对stack进行全面的优化, 不用到的部分不占内存, 线程的调度速度也变得非常快. 唯一缺点就是单进程只支持8192个线程了.. 所以, 我提到的那些优点, 比起Windows7 64位, 会削弱了很多很多.


在我设计的那个机制里, 这个stack是很特别的. 我为每个任务默认分配4M的stack地址空间,  理论支持的任务数是极大.. 大到什么程度, 我还没算.

举个例子吧, 假如一个进程, 有65536个任务在执行, 那么就需要256G的地址空间吧, 一个进程4G空间装不下 ,  但是我用内存分页技术解决了这个难题.


我只能说一些重点,

第一, 分配多少个stack, 和分配多少地址空间, 和分配多少物理内存, 是分开的事情.  分配的4M的地址空间, 不会立刻占用4M的物理内存.

第二, 在32bit模式下, 一个进程有4G的地址空间, 但是通过我的OS机制, 一个进程能用到的内存是远超4G的.

第三, 在64bit模式下, 这些更不是问题了..

细节方面,目前只能透露这么多.

MJK2012

回复 6# kouu


HI, 谢谢你的讨论先. 至于你后面说的那句话, 的确就是有这个意思.

用'同步'的编程方式, 实现'异步'的成果. 就是我的目标. 而这个目标是需要建立在OS的基础上, 才能更快.


(不是非要OS实现不可, 而是如果不用OS实现, 那么性能就不够快, 也就在一定程度上抵消了它的好处了)


那么我这里继续说说那个任务的stack的处理机制吧.


其实我的设计, 是基于页面切换的 . 在32bit,64bit,pae等各种情况下, 都可用页目录来实现分页.

其中最后一个表, 可以映射出4K*1024 = 4M的空间.


stack是一个很特殊的结构, 它只会存临时信息, 它可以引用其他指针. 但是基本上不会(也禁止)程序直接引用stack上的某一点.

(C语言允许把stack上的内容, 通过指针的方式传递给其他函数, 甚至传递给其他线程. 这就是兼容问题的一个大原因.)


假如一个stack它只是task自己用到的, 不允许stack的内容被指针的方式引用.  

那么 , 就可以在页目录上, 切换页表的形式, 加载和卸载stack的数据了.

那么产生的好处就是, 进程内一个128M的地址范围, 本来只能存放16个4M空间.

但是通过切换页表后, 就可以用来描述无数个stack了.

当一个任务被CPU执行时, 就会往这16个范围内, 申请一段, 加载stack, 当切换离开时, 需要释放.

这些都不需要移动物理内存, 纯粹就是靠在页目录上换一下页表的指针就够了.

在这个过程中, 任务的stack的位置, 是会不断地被改变, 相当于不断地被移动.

那么这128M的地址空间, 允许同一个进程的多个个tasks同时被16个CPU执行.


这实际上, 可以被称为一种, 地址的分时复用技术. 通过不断地切换页面映射, 在合适的时间内分配合适的数据.

linuxfellow

回复 7# MJK2012
线程不阻塞通信或读io好像用不着改操作系统，或创造一种新的编程语言这么复杂。
能不能举一个例子来说明你的异步IO机制？
假如在一个系统里有一个IO manager管理着所有设备；系统内的所有线程通过这个manager读取IO.
你的意思是线程向manager发出读取IO请求后立即返回；manager会回送请求的结果。我估计所有实际系统都会这么做。
你的结果回送过程是如何做的？与其他人做法不同在哪里？

   

linuxfellow

回复 7# MJK2012

这么做家电，没人买得起。家电的cpu比server还厉害。
   

MJK2012

回复 9# linuxfellow


    这种异步编程模式是一个新的概念. 一时三刻很难描述清楚.

就连微软的C#,也是到了5.0才有这种机制. (现在还没发布呢)

现在我自己也没有太多这种例子, 要描述这种方式还是挺难的.


现在很多的真正的异步编程体系, 都是通过'事件','callback'之类的机制触发.

就算是CPU的中断, 也相当于这么一个被通知的模式.


被通知的模式, 需要传递通知着一个处理函数地址, 需要某种方式去传递相关的上下文 (Context)

这种编程方式需要做很多工作, 去保存这些上下文, 去决定下一步, 如果得到什么数据, 再要做什么东西.