关于系统设计,我想到了两件事情
从性能的角度考虑,系统设计应该尽可能隔离物理设备,向用户提供透明的接口。最好让所有的东西都是普通的变量。例如,为什么要区分内存上的结构体和磁盘里的文件呢?完全可以让用户认为,定义一个变量,他就在内存里,又随时可以固化到磁盘上。至于这个变量,实际上放在哪里,由操作系统决定。例如一个很复杂的结构体数组,就可以开辟在磁盘上,并作内存上的缓冲。当然这种做法其实跟现在系统的内存分页调度方式最终结果是类似的。但是如果一开始选择权就在系统的话,自由度更大。
从这个角度考虑下去,很容易想到的就是文件的结构化管理。为什么二进制文件比纯文本文件更难读懂?因为二进制文件没有统一的管理模式。同样是二进制的,c语言里调试结构体的时候就完全不会觉得费力,为什么呢?因为头文件里声明了结构体的各成员类型。如果能把结构体的声明嵌套在二进制文件里,使其成为自解释的,则二进制文件能够充分发挥其存取方便、节约空间的好处,同时防止其调试困难人类难以理解的缺点。既然文件头的规范已成定则,完全可以考虑把文件的结构声明放在文件尾。当然需要订立标准。假如让我来设计草案的话,可以如下所述:
(1) 为了兼容现有文件结构,自解释信息放在文件末尾,紧接在原始文件的后面。使用特殊的头部以区分其他文件。
(2) 文件结构为树状结构,从根部开始,使用“描述块”来描述每个节点的数据结构定义,直至叶子节点。
(3) 叶子节点使用字节数表示其单位大小
(4) 父节点可以是数组*、结构体
这里有一个需要讨论的问题,就是当父节点是数组的时候,如何确定数组的长度。通常有两种做法决定数组的长度,一者是使用特殊标记的结束符号,二者是使用一个数组长度的数值来确定。当数组长度非常长的时候,可能32位int无法表示,可以总是使用64位int又会浪费空间,假如未来出现超级巨大存储器,甚至可能64位int都不够表示,还需要更加巨大的数字。所以我认为使用结束符号表示数组结尾是更好的方法。当然由于这里只是YY,可以随便想。例如也可以使用一个配置选项来决定使用哪种方式表示。
另外结构体的表示,当其成员用到其他已定义的成员时,也可以使用序号表示那个成员的结构声明。
使用这样的一种方法,程序员想要操作文件系统时将会非常轻松,例如配置文件,可以认为是使用换行符隔开的一系列字符数组。每一个换行符隔开的行单元可以单独地被交换到内存,或者写回文件。由于在文件定义的时候就确定了文件是以行为单位独立的,操作系统在这个层次可以做大量优化。例如并行程序读写不同行时文件无需加锁,而是将这两个被读写的行交换到内存中进行操作。例如编译文件,在某一行插入时,不必对文件的后面部分依次推后重新写回,而可以只在那一个行上做内存缓冲和读写,当系统空闲或卸载磁盘前再做写磁盘操作(大大提高并行性并减少磁盘写数量)。对于大文件,系统可以自动对行进行索引,从而提高随机读写行的性能,等等等等。
另外能够方便程序员的是,这样的文件由于已经附加了结构说明,只需复制这个文件,无需附加其他说明,就可在其他的程序员那里方便地阅读和使用。例如一个游戏的资源包文件,其实是一个复杂的树状结构。如果附加定义清晰的结构说明,其他程序员即使没有源代码也可以轻松地理解其内容。当然如果为了保密,可在发布时去掉文件说明。由于仅是附加在文件尾的部分,去掉也不会对文件本身造成任何影响。
在这个角度YY得太多了。总之这样的思路就是,操作系统完全是独裁的,程序员只能提请求,但这个请求究竟以什么样的方式实现,有操作系统来决定。好处是,系统所处的地位比应用程序高很多。系统知道现在全局资源的情况。总的内存占用、磁盘访问频率、网络流量(甚至可以考虑将部分数据上传到云端作为一种持久化措施,程序员请求固化一段内容,甚至可以不知道是固化在本地了还是在云端了),等等,这些东西作为一个应用程序是没办法想太多的,想太多容易“过早优化”,可是完全不想最后查性能瓶颈又是各种麻烦。如果系统能够智慧地处理各种情况,根据当前系统状态动态选择最合适的策略,则系统性能可以做到最优化,硬件使用率可以达到最高。
但这只是从系统的角度考虑。
假如从应用程序的角度考虑呢?假如我是应用程序的开发者,我绝对不喜欢操作系统额外做很多事。我希望我做的事情没有副作用,可确定。这也能方便我调试,方便我bug复现。例如,假如真的系统可能把数据固化到云端,假如网络通讯部分驱动有bug,可能我请求一个变量,十次有三次不成功,七次成功。因为恰好那三次定义到云端了,而后来的七次定义在本地。如果是这样,一旦程序复杂,bug丛生,程序员会气急败坏。相信程序员,把一切都交给程序员,这就是Unix的系统逻辑。一个绝对民主的系统。
可是,当权利交给程序员的时候,程序员就成为独裁者了。好的代码自然能够绝对有效地利用系统提供的资源,但坏的代码不仅自身运行不好,还会占用其他程序的资源和空间,让其他程序都变得缓慢甚至无法运行。让应用程序在他可见的那个狭窄范围内,做系统级的性能优化决策,又实在太为难应用程序员了吧。相比无数应用程序群氓的独裁,莫不如系统一个人的独裁可靠一些。因为只需把一个系统做好,就可以让所有的应用程序有好的表现。或许这个思路更好?
1 comment on “系统的民主和独裁”
拜读了!老潘的博客质量相当之高啊。
Comments are closed.