荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: tang (独孤九剑〖玄铁重剑〗), 信区: Linux
标 题: 好书共赏－《Unix Internels》（二）
发信站: BBS 荔园晨风站 (Sat Nov 27 18:49:31 1999), 站内信件
【 以下文字转载自 tang 的信箱 】
【 原文由 tang.bbs@bbs.net.tsinghua.edu.cn 所发表 】
发信人: BlueOcean (Blue), 信区: Unix
标 题: 好书共赏－《Unix Internels》（二）
发信站: BBS 水木清华站 (Mon Apr 27 13:09:14 1998) WWW-POST
Chapter 4 Signals and Session Management
本节对UNIX的signal和session( &controlling terminals...) 作了详细的描述,
不只是详细而已,而且把各版本的一同都写清楚了,一般的书没有这麽清楚的.
Mach对signal的策略也是焦点之一,更可以看出mach不全是Unix.
在Unix下我们安装一个signal handler来处理signal.而Mach则是使用
IPC来处理signal (正式的名字叫exception). Mach的每个thread都有对应的
exception port.如果要处理exception,就是再用另外一个thread去listen这个
exception port.这是per-thread exception port.另外还有一个per-task
exception port. 如果thread的exception port没人听,就会转到task
exception port,在没有人听当然就让他死啦! task exception port给
谁用的呢? debugger是也!
Unix的debugger有个缺点,就是没办法debug fork出去的child.而透过IPC,
mach debugger就没有这个问题,只要mach debugger可以listen他的exception
port就行了. 使用IPC也让remote debugging变成一件容易的事.(mach有个
proxy server,可以把local port的message route到remote去,seeminglessly!)
Unix的debugger从前只能debug自己fork出去的child,如果是一个已经执行的
程式就没法度了. Mach则是如前面所说的,只要能够listen人家的exception
port即可. UNIX这方面也改进了,使用/proc file system也可以达到相同的作用.
你学过UNIX一定了解什麽是process group,可是你不一定清楚session是什麽.
session的概念是在SVR4和4.4BSD内成型的,因为以往只用process group的概念
没办法分清楚一个login session和一个session的某个job的不同. session的观念
算是蛮新的..在SVR3和4.3BSD以前都和process group混在一起.
Chapter 5 Process Scheduling
process scheduling的核心是clock interrupt,算是多工系统的心脏吧!
Kernel以callout的形式来使用之.
int id = timeout(void (*callout)(), caddr_t arg, long delta);
向注册一个callout function,於delta tick後启动.
许多kernel的机制都是这样子向timer注册达成的,包括scheduler.
一个系统的ap可分为三类:
* interactive - io intensive, 如shell, editor, GUI
* batch - cpu intensive,如software buil;ds, scientific compuutations.
* real-time - time critical,如放映影片, ap的需求是固定的放映速率,
如每秒20 frames. 一个系统如果只能提供一个不确定的速率,在
15-40间变化,而平均值为30,那是难以接受的.
Unix对前两项(i.e., time-sharing)都很在行,本章也对各种Unix的
run queue的处理做了深入的讨论.当然比较值得注意的还是Unix
对real time的支援.
以前, Unix Kernel不能支援realtime的原因是non-preemptive的缘故,
有时候kernel会作某件事太久,让process饿死. SVR4解决的方法是
把耗时的演算法切成几节,中间放入几个preemption point.在这些点
kernel就可以preempt,使得支援real-time成为可能.
Solaris kernel则更进一步,把大部分的data-structure都用适当的方法
保护起来(synchronize,如mutex lock, samaphore),让kernel变成真正的
preemptive.可见Solaris真的还不错.
传统的Unix则是利用non-preemptive kernel的特性省去了这些lock.
mach的scheduling policy有一点有趣的地方,在一个thread msg_send()
後,一般可能会把他block住,把message enqueue起来, 到run queue内找
一个thread来跑. 但是如果已经有人在等这个message,
mach则是直接scheduling receiver出来跑, message也不enqueue了,直接
copy到user-level address space.这样子增加IPC的效能,
因为省却了搜寻run queue的时间, 以及IPC enqueue/dequeue的时间.
Mach特别的地方是processor set的概念.一个task可以要求kernel配给他
n颗(a set,一组) CPU来跑.
Digital UNIX源自於mach,但是却没有使用mach的scheduler.
本章末也介绍了一些被提出来的演算法,比较有趣的是three-level scheduler.
要同时满足任意的time-sharing和real-time的需求是不太可能, 因为资
源有限.three-level scheduler引进了节制的观念, real-time process要先注册,
kernel能够reserve足够的resource才允许执行.而kernel也会reserve适当的资源,
确保time-sharing processes不会动弹不得.
在网路负荷过重的时候,kernel只要处理network activity就来不及了,
会导致receive livelock情形发生. 3-level scheduler可以把network
的处理当成real-time task,给予适当的配额就好了.不够用就drop掉嘛.
这样子保证大家有饭吃,不会活当机! [ real-time task有固定的priority,
和固定的resource配额 -- kernel保证他会有这些东西,就像有人保证每天
都会给你一颗面包一样,不会说放一堆面包给大家抢(time-sharing),一天
有时候可以抢好几颗,有时一颗也抢不到,要是有一个人很会抢,那其他的
人就要饿死了!]
Chapter 6 Interprocess Communications
本章对IPC programming做了一些复习.
传统的Unix IPC机制只有pipe. System V引进了SYSV IPC,包含semaphore,
shared memory和message queue. System V的STREAMS架构也是Unix
重要的IPC机制之一. 本书没有提到BSD socket介面,假设这个也是
IPC的话. Mach是一message passing为中心的kernel(message-passing
kernel),大部分的系统服务都是靠交换讯息达成的,所以本章也花了
不少篇幅介绍之.
特别的有:
SVR4使用STREAMS来实作pipe,所以SVR4 pipe是bi-directional.一个
pipe两端都可读又可写.其他的UNIX则要用一对pipe才可达到相同目的.□
System V semaphore有一个缺点: allocation和initialization不是单一步骤,
可以导致race condition发生.
在System V STREAMS下, IPC的message queue几乎可以淘汰了. STREAMS
功能强大(see最後一章) ,可以取代掉所有message queue的功能.
本章最深奥的就是介绍Mach IPC了. 相信大家也最感兴趣.
message := 一些有型别的data.型别分为两类, simple data,即一般的
资料. complex data,可能为out-of-line memory或是port rights.
(後述)
port := a protected queue of messages. 简单的说就是message queue的id.
跟file descriptor差不多,为一个整数,代表一个message queue.
message必须送到port(通信埠),而不是送给某个task或thread.
port rights := 一个port的存取权限, send rights和receive rights.这种
存取权是以task为控制对象,而不是thread. send rights允许
一个task(的所有threads)对某个port传送讯息. receive rights
类推. 一个port可以把send rights给好几个tasks,但是只能有
一个task有receive rights -- 拥有该port的task. 有receive
right的task,就自动有send right)
out-of-line memory := 传送大量的资料, message直接copy很没效率. 透过
virtual memory系统改memory mapping,用copy-on-write的方式可
以改进. in-line memory传送是message从sender copy到kernel,
再由kernel copy-to receiver. out-of-line memory则是kernel
改一些virtual memory mapping, 只有在sender/receiver
modify该资料时产生copy-on-write的page fault, 只发生
了一次copy.
complex data和simple data的不同是complex data需要kernel处理message的
内容,再翻译给receiver. simple data直接transfer就可以了.
每个task拥有task_self port的send-right. task_self port是kernel
拥有的. task透过task_self port与kernel沟通.task另外有一个task_notify
port的receive rights,用来接收(kernel)来的message. thread有thread_self
port,用来送message给kernel, reply用来接收kernel传回来的reply
(比如system call, rpc...). thread用的port,其 port rights为task所有.
另外还有exception port用来处理exception/signal/debug.前面讲过了.
一个message内的资料结构有一栏为reply_port. 如果sender需要reply就在
此栏填入自己拥有的port.(所以自己就有receive right). message passing之中,
kernel就会为receiver建立一个到reply_port的send right.
Port Name Space
port是一个整数,和file descriptor一样, 每个task拥有独自的命名空间.
ie.不同task的port id如果一样, say,编号100,并不是指到相同的port.
Port translations
由於port name space是task间互相独立的. kernel必须建立一个translation
来记住谁是谁. (Unix是用global file descriptor table达成的).
研读本章最令人感到不解的是port right. 因为port的kernel data structure里面
没有port right的纪录. 那到底mach把port right资料藏到哪里去呢?搞了老半天,
原来就是port translation. kernel的port translation就是port
right.大胆一点说,
就是mach kernel根本没有port right的观念.只要在port translation查的到的
port,就可以送message就对了.
port translations的每个entry,代表的都是一个connection.
一个entry包含下列资料: <task, local_name, kport, type>,代表的意义是
一个task的id是local_name的port, 拥有对kport (一个指向kernel的port data
structure的指标)的port right. port right是receive还是send呢?由type决定.
local_name就是所谓的port right的名字.
msg_send()用 <task, local_name,*,*>找到kport,再由
<port.owner_task,*,port,*>找到该port於task的local_name.
task删掉一个port, kernel要找到kport,再除掉<*,*, kport, *>,并且
通知相关的task.
task结束要清掉<task,*,*,*>的所有kports.
Kernel用两个hash table来快速存取translation, TP_table (key=<task,port>)
TL_table(key=<task,local_name>)
Port Rights Transfer
普通的port right transfer embed到message header里面,就是前面提
的reply port.这样子的port right transfer是把自己的port的send
right送给别人用的.比较复杂的就要用complex message. message里面,
告诉kernel要把他人的(send right)送给第三者. (本章没有提到详情).
这是mach name server的功能:除了之前提到的port之外, mach的每个
task还有一个bootstrap port,透过此port, task可以送message到mach
的name server. name server提供了存取其他server的机制.过程如下:
1. server向name server注册(透过bootstrap port)
2. client向name server询问如何与server沟通.
3. name server transfer一个到server的send right给client
4. client得到一个可以和server沟通的port,利用此port和server联系.
Mach的理想是把许多Unix kernel的机制变成user level server. name server
是开启这个机制的钥匙.
Port Interpolation
Port interpolation可以让别人偷走某task的send/receive rights.
Mach提供task_extract_send(), task_insert_send(), task_extract_receive(),
task_insert_receive()来干这档事. debugger就是这样拦截ipc message的.
netmsgserver
另外一个和Port interpolation很像的机制,就是Mach的remote IPC. 其实
说穿了, Mach remote IPC的达成只是靠netmsgserver作proxy而已.
Mach可以这样做的原因有二, 第一个是send_msg()只要知道自己的
local_port_name就行了,他不需要知道这个port怎样连,连到哪里去.这是
port name server和netmsgserver的工作, task尽管往name server告诉他的
port送就可以了.第二点是senders是匿名的. receiver无法从message得知
sender是谁.所以netmsgserver可以提供完全透明的服务.
Mach 3.0对IPC的问题做了一些改进,自己看吧. 这是Mach 2.5 IPC
会遇到的问题.
Chapter 7 Synchronization and Multiprocessors
提到Kernel synchronization的演算法和资料结构.特别是multiprocessor
下的问题. multiprocessor最大的问题在virtual memory的cache/tlb
synchronize 的问题.本章没有提到, 延至virtual memory再讨论.
Chapter 7讨论的内容颇为琐碎, 不适合摘要.
--
Buck barks in the darkness
※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: ns.nlsde.buaa.edu.cn]
--
※ 转载:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 210.39.3.94]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店