00000001.htm

一份很好的linux入门资料

&nbsp;<BR>
UI,&nbsp;Unix&nbsp;International,是AT&amp;T和Sun为主的联盟.主要的产物有SVR4和OpenLook.&nbsp;<BR>
OSF,&nbsp;Open&nbsp;Software&nbsp;Foundation为以IBM,DEC,HP为首的公司投资的子公司.&nbsp;<BR>
OSF对UNIX的贡献有Motif标准,DCE&nbsp;(Distributed&nbsp;Computing&nbsp;Environment).&nbsp;<BR>
&nbsp;<BR>
在NT出来搅局後,UI瓦解了,AT&amp;T不要UNIX了(专心於他的plan9作业系统?),&nbsp;<BR>
SVR4的传人变成了Sun的Solaris,不过Sun也不再坚持OpenLook,同时支援CDE&nbsp;<BR>
(Common&nbsp;Desktop&nbsp;Environment,讲白话一点就是Motif).&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;2&nbsp;The&nbsp;Process&nbsp;and&nbsp;the&nbsp;Kernel&nbsp;<BR>
&nbsp;<BR>
介绍Prcoess的各种资料结构与执行态,没什麽特别的.等於是Unix&nbsp;Progarmming&nbsp;<BR>
的小复习.&nbsp;<BR>
&nbsp;<BR>
比较特别的是vfork的描述.有些书会让我们有在现代的UNIX下,&nbsp;vfork&nbsp;=&nbsp;fork&nbsp;with&nbsp;<BR>
copy&nbsp;on&nbsp;write的错觉.实际上vfork後,&nbsp;child是和parent共用一块定址空间(比较像&nbsp;<BR>
multi-threading),&nbsp;child可以修改parent的资料.&nbsp;<BR>
可能目前unix的语意和原始的vfork&nbsp;<BR>
不一样了吧..&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;3&nbsp;Threads&nbsp;and&nbsp;Lightweight&nbsp;Processes&nbsp;<BR>
&nbsp;<BR>
这里提到Modern&nbsp;UNIX的特性之一:&nbsp;threads.&nbsp;在Win95/NT,&nbsp;OS2的吹捧之下&nbsp;<BR>
大家应该有点耳濡目染了吧.这边定义了Threads和Lightweight&nbsp;processes.&nbsp;<BR>
有些系统,&nbsp;threads&nbsp;=&nbsp;LWP,不过为了讨论的需要,本书threads&nbsp;!=&nbsp;LWP.&nbsp;<BR>
&nbsp;<BR>
thread是一个最小的执行单元,&nbsp;代表一个process在系统里面的活动状态.传统的&nbsp;<BR>
process就是仅有一个thread的程式.一个程式有5个thread就是说同一个程式里面&nbsp;<BR>
有五个工作同时在进行,也就是五个小程式独立互不干扰的一起跑的意思.(这&nbsp;<BR>
句话有语病,姑且当作对的好了)&nbsp;比较低阶一点的看法是一个process有5个&nbsp;<BR>
instruction&nbsp;flow和五个stack.如果还是很模糊,看看Mach的定义九比较清楚了.&nbsp;<BR>
&nbsp;<BR>
Thread有三种:kernel&nbsp;threads,&nbsp;lightweight&nbsp;processes,&nbsp;user&nbsp;threads.&nbsp;<BR>
&nbsp;<BR>
kernel&nbsp;threads就是kernel有好几个分身,一个分身可以处理一件事的意思.&nbsp;<BR>
这用来处理非同步事件很有用,&nbsp;kernel可以对每个非同步事件生个分身来处理.&nbsp;<BR>
kernel&nbsp;threads的操作非常轻便,几乎没有负担,而且对Kernel的结构有帮助.&nbsp;<BR>
支援kernel&nbsp;threads的kernel称作multithreaded&nbsp;kernel.&nbsp;<BR>
&nbsp;<BR>
Lightweight&nbsp;Process是有Kernel支援的user&nbsp;thread.也就是说,每个LWP,kernel&nbsp;<BR>
皆使用一个thread来处理/支援.於是LWP可以看成是kernel&nbsp;thread的延伸.操&nbsp;<BR>
作LWP的代价是很大的,因为他牵扯到Kernel的context&nbsp;switching.&nbsp;<BR>
&nbsp;<BR>
user&nbsp;threads是在使用者空间,透过library模拟的thread,不需要或仅需要极少的&nbsp;<BR>
kernel支援,context&nbsp;switching比较快,因为不用更改page&nbsp;table等等东西,&nbsp;<BR>
使用起来较为轻便快速.user&nbsp;threads提供操控视窗系统的绝佳解决方案.&nbsp;<BR>
&nbsp;<BR>
kernel基本上可以完全不知道user&nbsp;threads的存在,&nbsp;而一个系统可以&nbsp;<BR>
提供数个不同的&nbsp;library来提供不同policy.&nbsp;user&nbsp;threads才是一般应用程式&nbsp;<BR>
需要的multi-threading的形式,&nbsp;因为此方式没有kernel参与,&nbsp;所以最轻盈,&nbsp;<BR>
最有效率.&nbsp;提到这里,你是否对广告上,&nbsp;OS2和Win95/NT争multithreading支援&nbsp;<BR>
感到迷惑呢?他们真的不晓得在争哪个mulitthreading的功能耶...&nbsp;<BR>
&nbsp;<BR>
最有名的thread&nbsp;library有Mach's&nbsp;C&nbsp;threads,和POSIX&nbsp;pthreads.&nbsp;<BR>
&nbsp;<BR>
SunOS4.x所称的LWP指的是user&nbsp;threas,而不是本书的LWP.&nbsp;<BR>
&nbsp;<BR>
Solaris是由一组Kernel&nbsp;threads所构成,有一些用来执行LWP,有些负责一些系统的&nbsp;<BR>
任务.&nbsp;<BR>
&nbsp;<BR>
kernel&nbsp;thread比较有创意的应用是取代interrupt&nbsp;<BR>
handler.有interrupt产生时,kernel可以产&nbsp;<BR>
生一个thread(分身)用来处理该interrupt.一口气解决掉re-entrant的问题&nbsp;<BR>
&nbsp;<BR>
thread的scheduling有些意思,不过不方便以三言两语描述,也不甚有趣,就算了.&nbsp;<BR>
&nbsp;<BR>
Mach的Threads&nbsp;<BR>
&nbsp;<BR>
Mach&nbsp;kernel有两个基本观念:&nbsp;task和thread.&nbsp;<BR>
Task是静态的物件,由定址空间和系统资源(port&nbsp;rights)构成.&nbsp;<BR>
task提供了一个thread的执行环境.&nbsp;<BR>
thread是Mach的基本执行单元.&nbsp;<BR>
Mach提供了cthread函式库用来操作threads.&nbsp;<BR>
&nbsp;<BR>
Mach&nbsp;3.0&nbsp;Continuation&nbsp;<BR>
&nbsp;<BR>
Mach3.0对threads的改进颇有意思,名为continuation,其出发点是为了&nbsp;<BR>
节省stack的使用,在一个multi-threaded&nbsp;kernel下,&nbsp;thread越多(滥用:)&nbsp;<BR>
则stack&nbsp;space也消耗越多,亟待解决.&nbsp;<BR>
&nbsp;<BR>
以下的程式片断很常见,也是一般kernel&nbsp;thread会block的原因(也就是&nbsp;<BR>
需要stack的时候.&nbsp;<BR>
&nbsp;&nbsp;syscall(args)&nbsp;{&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;...&nbsp;/*&nbsp;比如说,安排DMA传输一块disk&nbsp;block....*/&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;thread_block();&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;wait&nbsp;until&nbsp;completed&nbsp;*/&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;process(args1);&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;return;&nbsp;<BR>
&nbsp;&nbsp;}&nbsp;<BR>
如果&nbsp;syscall&nbsp;block住的话,就要保留一个stack下来.要是可以让process()不需要&nbsp;<BR>
用到stack里面的资料的话,那就不用保留stack.当然事先要把tail所需的&nbsp;<BR>
参数存在static&nbsp;variable里.&nbsp;<BR>
所以原程式就变成这样:&nbsp;<BR>
&nbsp;&nbsp;syscall()&nbsp;{&nbsp;<BR>
&nbsp;&nbsp;&nbsp;...&nbsp;<BR>
&nbsp;&nbsp;&nbsp;thread_block(process);&nbsp;<BR>
&nbsp;&nbsp;&nbsp;/*&nbsp;not&nbsp;reached&nbsp;*/&nbsp;<BR>
&nbsp;}&nbsp;<BR>
&nbsp;&nbsp;process()&nbsp;{&nbsp;/*&nbsp;最终处理*/&nbsp;<BR>
&nbsp;&nbsp;&nbsp;...&nbsp;<BR>
&nbsp;&nbsp;&nbsp;thread_syscall_return(status);&nbsp;<BR>
&nbsp;&nbsp;}&nbsp;<BR>
&nbsp;<BR>
省下来的stack则要是下一个被wake&nbsp;up的thread刚好也是个continuation,&nbsp;<BR>
可以直接给他用,省下一点cache/TLB&nbsp;misses.&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
Digital&nbsp;UNIX&nbsp;<BR>
&nbsp;<BR>
讨论了OSF/1如何在Mach上利用tasks&amp;threads实做出合UNIX语意的Process出来.&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;4&nbsp;Signals&nbsp;and&nbsp;Session&nbsp;Management&nbsp;<BR>
&nbsp;<BR>
本节对UNIX的signal和session(&nbsp;&amp;controlling&nbsp;terminals...)&nbsp;作了详细的描述,&nbsp;<BR>
不只是详细而已,而且把各版本的一同都写清楚了,一般的书没有这麽清楚的.&nbsp;<BR>
&nbsp;<BR>
Mach对signal的策略也是焦点之一,更可以看出mach不全是Unix.&nbsp;<BR>
在Unix下我们安装一个signal&nbsp;handler来处理signal.而Mach则是使用&nbsp;<BR>
IPC来处理signal&nbsp;(正式的名字叫exception).&nbsp;Mach的每个thread都有对应的&nbsp;<BR>
exception&nbsp;port.如果要处理exception,就是再用另外一个thread去listen这个&nbsp;<BR>
exception&nbsp;port.这是per-thread&nbsp;exception&nbsp;port.另外还有一个per-task&nbsp;<BR>
exception&nbsp;port.&nbsp;如果thread的exception&nbsp;port没人听,就会转到task&nbsp;&nbsp;<BR>
exception&nbsp;port,在没有人听当然就让他死啦!&nbsp;task&nbsp;exception&nbsp;port给&nbsp;<BR>
谁用的呢?&nbsp;debugger是也!&nbsp;<BR>
&nbsp;<BR>
Unix的debugger有个缺点,就是没办法debug&nbsp;fork出去的child.而透过IPC,&nbsp;<BR>
mach&nbsp;debugger就没有这个问题,只要mach&nbsp;debugger可以listen他的exception&nbsp;<BR>
port就行了.&nbsp;使用IPC也让remote&nbsp;debugging变成一件容易的事.(mach有个&nbsp;<BR>
proxy&nbsp;server,可以把local&nbsp;port的message&nbsp;route到remote去,seeminglessly!)&nbsp;<BR>
&nbsp;<BR>
Unix的debugger从前只能debug自己fork出去的child,如果是一个已经执行的&nbsp;<BR>
程式就没法度了.&nbsp;Mach则是如前面所说的,只要能够listen人家的exception&nbsp;<BR>
port即可.&nbsp;UNIX这方面也改进了,使用/proc&nbsp;file&nbsp;system也可以达到相同的作用.&nbsp;<BR>
&nbsp;<BR>
你学过UNIX一定了解什麽是process&nbsp;group,可是你不一定清楚session是什麽.&nbsp;<BR>
session的概念是在SVR4和4.4BSD内成型的,因为以往只用process&nbsp;group的概念&nbsp;<BR>
没办法分清楚一个login&nbsp;session和一个session的某个job的不同.&nbsp;session的观念&nbsp;<BR>
算是蛮新的..在SVR3和4.3BSD以前都和process&nbsp;group混在一起.&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;5&nbsp;Process&nbsp;Scheduling&nbsp;<BR>
&nbsp;<BR>
process&nbsp;scheduling的核心是clock&nbsp;interrupt,算是多工系统的心脏吧!&nbsp;<BR>
Kernel以callout的形式来使用之.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;int&nbsp;id&nbsp;=&nbsp;timeout(void&nbsp;(*callout)(),&nbsp;caddr_t&nbsp;arg,&nbsp;long&nbsp;delta);&nbsp;<BR>
向注册一个callout&nbsp;function,於delta&nbsp;tick後启动.&nbsp;<BR>
许多kernel的机制都是这样子向timer注册达成的,包括scheduler.&nbsp;<BR>
&nbsp;<BR>
一个系统的ap可分为三类:&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;*&nbsp;interactive&nbsp;-&nbsp;io&nbsp;intensive,&nbsp;如shell,&nbsp;editor,&nbsp;GUI&nbsp;<BR>
&nbsp;&nbsp;&nbsp;*&nbsp;batch&nbsp;-&nbsp;cpu&nbsp;intensive,如software&nbsp;buil;ds,&nbsp;scientific&nbsp;compuutations.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;*&nbsp;real-time&nbsp;-&nbsp;time&nbsp;critical,如放映影片,&nbsp;ap的需求是固定的放映速率,&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;如每秒20&nbsp;frames.&nbsp;一个系统如果只能提供一个不确定的速率,在&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;15-40间变化,而平均值为30,那是难以接受的.&nbsp;<BR>
&nbsp;<BR>
Unix对前两项(i.e.,&nbsp;time-sharing)都很在行,本章也对各种Unix的&nbsp;<BR>
run&nbsp;queue的处理做了深入的讨论.当然比较值得注意的还是Unix&nbsp;<BR>
对real&nbsp;time的支援.&nbsp;<BR>
&nbsp;<BR>
以前,&nbsp;Unix&nbsp;Kernel不能支援realtime的原因是non-preemptive的缘故,&nbsp;<BR>
有时候kernel会作某件事太久,让process饿死.&nbsp;SVR4解决的方法是&nbsp;<BR>
把耗时的演算法切成几节,中间放入几个preemption&nbsp;point.在这些点&nbsp;<BR>
kernel就可以preempt,使得支援real-time成为可能.&nbsp;<BR>
&nbsp;<BR>
Solaris&nbsp;kernel则更进一步,把大部分的data-structure都用适当的方法&nbsp;<BR>
保护起来(synchronize,如mutex&nbsp;lock,&nbsp;samaphore),让kernel变成真正的&nbsp;<BR>
preemptive.可见Solaris真的还不错.&nbsp;<BR>
&nbsp;<BR>
传统的Unix则是利用non-preemptive&nbsp;kernel的特性省去了这些lock.&nbsp;<BR>
&nbsp;<BR>
mach的scheduling&nbsp;policy有一点有趣的地方,在一个thread&nbsp;msg_send()&nbsp;<BR>
後,一般可能会把他block住,把message&nbsp;enqueue起来,&nbsp;到run&nbsp;queue内找&nbsp;<BR>
一个thread来跑.&nbsp;但是如果已经有人在等这个message,&nbsp;<BR>
mach则是直接scheduling&nbsp;receiver出来跑,&nbsp;message也不enqueue了,直接&nbsp;<BR>
copy到user-level&nbsp;address&nbsp;space.这样子增加IPC的效能,&nbsp;<BR>
因为省却了搜寻run&nbsp;queue的时间,&nbsp;以及IPC&nbsp;enqueue/dequeue的时间.&nbsp;<BR>
&nbsp;<BR>
Mach特别的地方是processor&nbsp;set的概念.一个task可以要求kernel配给他&nbsp;<BR>
n颗(a&nbsp;set,一组)&nbsp;CPU来跑.&nbsp;<BR>
&nbsp;<BR>
Digital&nbsp;UNIX源自於mach,但是却没有使用mach的scheduler.&nbsp;<BR>