⭐ 欢迎来到虫虫下载站！ | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站
📤 上传资源

📄 00000002.htm

📁 一份很好的linux入门资料
💻 HTM
📖 第 1 页 / 共 2 页
字号:
🔍
12 
<HTML><HEAD>  <TITLE>BBS水木清华站∶精华区</TITLE></HEAD><BODY><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>发信人:&nbsp;BlueOcean&nbsp;(Blue),&nbsp;信区:&nbsp;Unix&nbsp;<BR>标&nbsp;&nbsp;题:&nbsp;好书共赏－《Unix&nbsp;Internels》（二）&nbsp;<BR>发信站:&nbsp;BBS&nbsp;水木清华站&nbsp;(Mon&nbsp;Apr&nbsp;27&nbsp;13:09:14&nbsp;1998)&nbsp;m2mWWW-POST0m0m&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>&nbsp;<BR>本章末也介绍了一些被提出来的演算法,比较有趣的是three-level&nbsp;scheduler.&nbsp;<BR>要同时满足任意的time-sharing和real-time的需求是不太可能,&nbsp;因为资&nbsp;<BR>源有限.three-level&nbsp;scheduler引进了节制的观念,&nbsp;real-time&nbsp;process要先注册,&nbsp;<BR>kernel能够reserve足够的resource才允许执行.而kernel也会reserve适当的资源,&nbsp;<BR>确保time-sharing&nbsp;processes不会动弹不得.&nbsp;<BR>&nbsp;<BR>在网路负荷过重的时候,kernel只要处理network&nbsp;activity就来不及了,&nbsp;<BR>会导致receive&nbsp;livelock情形发生.&nbsp;3-level&nbsp;scheduler可以把network&nbsp;<BR>的处理当成real-time&nbsp;task,给予适当的配额就好了.不够用就drop掉嘛.&nbsp;<BR>这样子保证大家有饭吃,不会活当机!&nbsp;[&nbsp;real-time&nbsp;task有固定的priority,&nbsp;<BR>和固定的resource配额&nbsp;--&nbsp;kernel保证他会有这些东西,就像有人保证每天&nbsp;<BR>都会给你一颗面包一样,不会说放一堆面包给大家抢(time-sharing),一天&nbsp;<BR>有时候可以抢好几颗,有时一颗也抢不到,要是有一个人很会抢,那其他的&nbsp;<BR>人就要饿死了!]&nbsp;<BR>&nbsp;<BR>&nbsp;<BR>Chapter&nbsp;6&nbsp;Interprocess&nbsp;Communications&nbsp;<BR>&nbsp;<BR>本章对IPC&nbsp;programming做了一些复习.&nbsp;<BR>传统的Unix&nbsp;IPC机制只有pipe.&nbsp;System&nbsp;V引进了SYSV&nbsp;IPC,包含semaphore,&nbsp;<BR>shared&nbsp;memory和message&nbsp;queue.&nbsp;System&nbsp;V的STREAMS架构也是Unix&nbsp;<BR>重要的IPC机制之一.&nbsp;本书没有提到BSD&nbsp;socket介面,假设这个也是&nbsp;<BR>IPC的话.&nbsp;Mach是一message&nbsp;passing为中心的kernel(message-passing&nbsp;<BR>kernel),大部分的系统服务都是靠交换讯息达成的,所以本章也花了&nbsp;<BR>不少篇幅介绍之.&nbsp;<BR>&nbsp;<BR>特别的有:&nbsp;<BR>SVR4使用STREAMS来实作pipe,所以SVR4&nbsp;pipe是bi-directional.一个&nbsp;<BR>pipe两端都可读又可写.其他的UNIX则要用一对pipe才可达到相同目的.□&nbsp;<BR>&nbsp;<BR>System&nbsp;V&nbsp;semaphore有一个缺点:&nbsp;allocation和initialization不是单一步骤,&nbsp;<BR>可以导致race&nbsp;condition发生.&nbsp;<BR>&nbsp;<BR>在System&nbsp;V&nbsp;STREAMS下,&nbsp;IPC的message&nbsp;queue几乎可以淘汰了.&nbsp;STREAMS&nbsp;<BR>功能强大(see最後一章)&nbsp;,可以取代掉所有message&nbsp;queue的功能.&nbsp;<BR>&nbsp;<BR>本章最深奥的就是介绍Mach&nbsp;IPC了.&nbsp;相信大家也最感兴趣.&nbsp;<BR>message&nbsp;:=&nbsp;一些有型别的data.型别分为两类,&nbsp;simple&nbsp;data,即一般的&nbsp;<BR>
12

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -