操作系统ucore lab7实验报告

练习0

填写已有实验

本实验依赖实验1~实验6.请把已做的实验1~实验6的代码填入本实验中代码中有lab1、lab2、lab3、lab4、lab5、lab6的注释相应部分，并确保编译通过。

注意：为了能够正确执行lab7的测试应用程序，可能需对已完成的实验1~实验5的代码进一步改进



发现缺失的是

kdebug.c、trap.c、default_pmm.c、pmm.c、swap_fifo.c、vmm.c、proc.c、sche.c

八个文件的相关代码，补全后不需要在6的基础上改了

练习1

理解内核级信号量的实现和基于内核级信号量的哲学家就餐问题(不需要编码)

哲学家就餐问题

  首先通过查阅资料，理解哲学家就餐问题

  哲学家就餐问题，即有五个哲学家,他们的生活方式是交替地进行思考和进餐。哲学家们公用一张圆桌,周围放有五把椅子,每人坐一把。在圆桌上有五个碗和五根筷子,当一个哲学家思考时,他不与其他人交谈,饥饿时便试图取用其左、右最靠近他的筷子,但他可能一根都拿不到。只有在他拿到两根筷子时,方能进餐,进餐完后,放下筷子又继续思考。

  筷子是临界资源，一段时间只允许一位哲学家使用。为了表示互斥，用一个信号量表示一只筷子，五个信号量构成信号量数组。本文中算法用类C语言描述伪码算法。算法描述如下：n用五支筷子的信号量构成信号量数组：

Semaphore chopstick[5]={1，l，1，l，1}；
Pi()
{
do
{
p(chopstick[i]);//取左边的筷子
p(chopstick[(i+1) % 5]);//取右边的筷子
eat;                //进餐
v(chopstick[i]);//放回左边的筷子
v(chopstick[(i+1) % 5]);//放回右边的筷子
think;
}while(1);
}

思考：

  当哲学家饥饿时，总是先去拿他左边的筷子，执行

wait(chopstick[I])

，成功后，再去拿他右边的筷子，执行

wait(chopstick[I+1]%5)；

成功后便可进餐。进餐毕，先放下他左边的筷子，然后再放下右边的筷子。当五个哲学家同时去取他左边的筷子，每人拿到一只筷子且不释放，即五个哲学家只得无限等待下去，引起死锁。

  这就很好的知道同步互斥问题很重要，然后分析下信号量。

  在分析之前先对信号量进行简介，看书上关于

Operating Systems Internals and Design Principles

第5章

同步互斥

中对信号量实现的原理性描述：

struct semaphore {
int count;
queueType queue;
};
void semWait(semaphore s)
{
s.count--;
if (s.count < 0) {
/* place this process in s.queue */;
/* block this process */;
//入队，调度出去
}
}
void semSignal(semaphore s)
{
s.count++;
if (s.count<= 0) {
/* remove a process P from s.queue */;
/* place process P on ready list */;
//出队，放置准备列表
}
}

  基于上诉信号量实现可以认为，当多个（>1）进程可以进行互斥或同步合作时，一个进程会由于无法满足信号量设置的某条件而在某一位置停止，直到它接收到一个特定的信号（表明条件满足了）。为了发信号，需要使用一个称作信号量的特殊变量。为通过信号量s传送信号，信号量的V操作采用进程可执行原语

semSignal(s)

；为通过信号量s接收信号，信号量的P操作采用进程可执行原语

semWait(s)

；如果相应的信号仍然没有发送，则进程被阻塞或睡眠，直到发送完为止。

  ucore中信号量参照上述原理描述，建立在开关中断机制和

wait queue

的基础上进行了具体实现。信号量的数据结构定义如下：

typedef struct {
int value;                           //信号量的当前值
wait_queue_t wait_queue;     //信号量对应的等待队列
} semaphore_t;

接下来进入代码的分析。

  lab7和之前的lab6的大体执行流程都与实验六相同，查看到

proc.c

文件，发现

init_main

中有问题



  函数在开始执行调度之前多执行了一个

check_sync

函数

check_sync函数

void check_sync(void){

int i;

//check semaphore
sem_init(&mutex, 1);
for(i=0;i<N;i++){
sem_init(&s[i], 0);
int pid = kernel_thread(philosopher_using_semaphore, (void *)i, 0);
if (pid <= 0) {
panic("create No.%d philosopher_using_semaphore failed.\n");
}
philosopher_proc_sema[i] = find_proc(pid);
set_proc_name(philosopher_proc_sema[i], "philosopher_sema_proc");
}

//check condition variable
monitor_init(&mt, N);
for(i=0;i<N;i++){
state_condvar[i]=THINKING;
int pid = kernel_thread(philosopher_using_condvar, (void *)i, 0);
if (pid <= 0) {
panic("create No.%d philosopher_using_condvar failed.\n");
}
philosopher_proc_condvar[i] = find_proc(pid);
set_proc_name(philosopher_proc_condvar[i], "philosopher_condvar_proc");
}
}

  根据注释可以看到，该函数分为了两个部分，第一部分是实现
4000
基于信号量的哲学家问题,第二部分是实现基于管程的哲学家问题。

  就先分析前一部分。首先实现初始化了一个互斥信号量，然后创建了对应5个哲学家行为的5个信号量，并创建5个内核线程代表5个哲学家，每个内核线程完成了基于信号量的哲学家吃饭睡觉思考行为实现。

philosopher_using_semaphore

函数

然后分析

philosopher_using_semaphore

int philosopher_using_semaphore(void * arg) /* i：哲学家号码，从0到N-1 */
{
int i, iter=0;
i=(int)arg;
cprintf("I am No.%d philosopher_sema\n",i);
while(iter++<TIMES)
{ /* 无限循环 */
cprintf("Iter %d, No.%d philosopher_sema is thinking\n",iter,i); /* 哲学家正在思考 */
do_sleep(SLEEP_TIME);
phi_take_forks_sema(i);
/* 需要两只叉子，或者阻塞 */
cprintf("Iter %d, No.%d philosopher_sema is eating\n",iter,i); /* 进餐 */
do_sleep(SLEEP_TIME);
phi_put_forks_sema(i);
/* 把两把叉子同时放回桌子 */
}
cprintf("No.%d philosopher_sema quit\n",i);
return 0;
}

[b]相关定义：[/b]















  核心是

phi_take_forks_sema

和

phi_put_forks_sema

两个函数，

  然后up和down函数就分别调用了

__up

函数和

__down

函数，而这两个函数分别对应着信号量的V，P操作。

__up(semaphore_t *sem, uint32_t wait_state)

  具体实现信号量的V操作，首先关中断，如果信号量对应的wait queue中没有进程在等待，直接把信号量的value加一，然后开中断返回；如果有进程在等待且进程等待的原因是semophore设置的，则调用wakeup_wait函数将waitqueue中等待的第一个wait删除，且把此wait关联的进程唤醒，最后开中断返回。

static __noinline void __up(semaphore_t *sem, uint32_t wait_state) {
bool intr_flag;
local_intr_save(intr_flag);
{
wait_t *wait;
//没有进程等待
if ((wait = wait_queue_first(&(sem->wait_queue))) == NULL) {
sem->value ++;//信号量的value加一
}
else {//有进程在等待
assert(wait->proc->wait_state == wait_state);
//将等待队列中的第一个进程删除，并将该进程唤醒
wakeup_wait(&(sem->wait_queue), wait, wait_state, 1);
}
}
local_intr_restore(intr_flag);//开启中断返回
}

__down(semaphore_t *sem, uint32_t wait_state, timer_t *timer)

  具体实现信号量的P操作，首先关掉中断，然后判断当前信号量的value是否大于0。如果是>0，则表明可以获得信号量，故让value减一，并打开中断返回即可；如果不是>0，则表明无法获得信号量，故需要将当前的进程加入到等待队列中，并打开中断，然后运行调度器选择另外一个进程执行。如果被V操作唤醒，则把自身关联的wait从等待队列中删除（此过程需要先关中断，完成后开中断）。

static __noinline uint32_t __down(semaphore_t *sem, uint32_t wait_state) {
bool intr_flag;
local_intr_save(intr_flag);
if (sem->value > 0) {//当前信号量value大于0
//直接让value减一
sem->value --;
//开中断返回
local_intr_restore(intr_flag);
return 0;
}
//当value小于等于0时，无法获得信号量
wait_t __wait, *wait = &__wait;
//将当前的进程加入到等待队列中
wait_current_set(&(sem->wait_queue), wait, wait_state);
local_intr_restore(intr_flag);
//运行调度器
schedule();

local_intr_save(intr_flag);//关中断
//被V操作唤醒，从等待队列移除
wait_current_del(&(sem->wait_queue), wait);
local_intr_restore(intr_flag);//开中断
//如果不是等待的
if (wait->wakeup_flags != wait_state) {
return wait->wakeup_flags;
}
return 0;
}

信号量的计数器value具有有如下性质：

value> 0，表示共享资源的空闲数

vlaue< 0，表示该信号量的等待队列里的进程数

value= 0，表示等待队列为空

练习2

完成内核级条件变量和基于内核级条件变量的哲学家就餐问题（需要编码）

  首先掌握管程机制，然后基于信号量实现完成条件变量实现，然后用管程机制实现哲学家就餐问题的解决方案（基于条件变量）。

原理

  一个管程定义了一个数据结构和能为并发进程所执行(在该数据结构上)的一组操作,这组操作能同步进程和改变管程中的数据。

管程主要由这四个部分组成

1、管程内部的共享变量;

2、管程内部的条件变量;

3、管程内部并发执行的进程;

4、对局部于管程内部的共享数据设置初始值的语句。

  管程相当于一个隔离区，它把共享变量和对它进行操作的若干个过程围了起来，所有进程要访问临界资源时，都必须经过管程才能进入，而管程每次只允许一个进程进入管程,从而需要确保进程之间互斥。

  但在管程中仅仅有互斥操作是不够用的。进程可能需要等待某个条件C为真才能继续执行。

  所谓条件变量，即将等待队列和睡眠条件包装在一起，就形成了一种新的同步机制，称为条件变量。一个条件变量CV可理解为一个进程的等待队列,队列中的进程正等待某个条件C变为真。每个条件变量关联着一个断言

Pc

。当一个进程等待一个条件变量,该进程不算作占用了该管程,因而其它进程可以进入该管程执行,改变管程的状态,通知条件变量CV其关联的断言Pc在当前状态下为真。

因而条件变量两种操作如下：

-

wait_cv

： 被一个进程调用,以等待断言Pc被满足后该进程可恢复执行. 进程挂在该条件变量上等待时,不被认为是占用了管程。

-

signal_cv

：被一个进程调用,以指出断言Pc现在为真,从而可以唤醒等待断言Pc被满足的进程继续执行。

分析具体的代码。

  ucore中的管程机制是基于信号量和条件变量来实现的。管程的数据结构monitor_t如下：

typedef struct monitor{
// 二值信号量，只允许一个进程进入管程，初始化为1
semaphore_t mutex;      // the mutex lock for going into the routines in monitor, should be initialized to 1
//用于进程同步操作的信号量
semaphore_t next;       // the next semaphore is used to down the signaling proc itself, and the other OR wakeuped waiting proc should wake up the sleeped signaling proc.
// 睡眠的进程数量
int next_count;         // the number of of sleeped signaling proc
// 条件变量cv
condvar_t *cv;          // the condvars in monitor
} monitor_t;

  管程中的条件变量cv通过执行wait_cv，会使得等待某个条件C为真的进程能够离开管程并睡眠，且让其他进程进入管程继续执行；而进入管程的某进程设置条件C为真并执行

signal_cv

时，能够让等待某个条件C为真的睡眠进程被唤醒，从而继续进入管程中执行。发出signal_cv的进程A会唤醒睡眠进程B，进程B执行会导致进程A睡眠，直到进程B离开管程，进程A才能继续执行，这个同步过程是通过信号量next完成的；而next_count表示了由于发出singal_cv而睡眠的进程个数。

条件变量

condvar_t

的数据结构如下：

typedef struct condvar{
semaphore_t sem;        // the sem semaphore  is used to down the waiting proc, and the signaling proc should up the waiting proc
// 在这个条件变量上的睡眠进程的个数
int count;              // the number of waiters on condvar
// 此条件变量的宿主管程
monitor_t * owner;      // the owner(monitor) of this condvar
} condvar_t;

  条件变量的定义中也包含了一系列的成员变量，信号量sem用于让发出wait_cv操作的等待某个条件C为真的进程睡眠，而让发出signal_cv操作的进程通过这个sem来唤醒睡眠的进程。count表示等在这个条件变量上的睡眠进程的个数。owner表示此条件变量的宿主是哪个管程。

  开始分析管程的实现。ucore设计实现了条件变量

wait_cv

操作和

signal_cv

操作对应的具体函数，即

cond_wait

函数和

cond_signal

函数，此外还有

cond_init

初始化函数。





  简单分析一下

cond_wait

函数的实现。可以看出如果进程A执行了

cond_wait

函数，表示此进程等待某个条件C不为真，需要睡眠。因此表示等待此条件的睡眠进程个数cv.count要加一。接下来会出现两种情况。

- 情况一：如果

monitor.next_count

如果大于0，表示有大于等于1个进程执行

cond_signal

函数且睡着了，就睡在了

monitor.next

信号量上。假定这些进程形成S进程链表。因此需要唤醒S进程链表中的一个进程B。然后进程A睡在

cv.sem

上，如果睡醒了，则让

cv.count

减一，表示等待此条件的睡眠进程个数少了一个，可继续执行。

- 情况二：如果

monitor.next_count

如果小于等于0，表示目前没有进程执行

cond_signal

函数且睡着了，那需要唤醒的是由于互斥条件限制而无法进入管程的进程，所以要唤醒睡在

monitor.mutex

上的进程。然后进程A睡在

cv.sem

上，如果睡醒了，则让

cv.count

减一，表示等待此条件的睡眠进程个数少了一个，可继续执行了！

  对照着再来看cond_signal的实现。

  首先进程B判断

cv.count

，如果不大于0，则表示当前没有睡眠的进程，因此就没有被唤醒的对象了，直接函数返回即可；

  如果大于0，这表示当前有睡眠的进程A，因此需要唤醒等待在

cv.sem

上睡眠的进程A。由于只允许一个进程在管程中执行，所以一旦进程B唤醒了别人（进程A），那么自己就需要睡眠。故让

monitor.next_count

加一，且让自己（进程B）睡在信号量

monitor.next

上。如果睡醒了，这让

monitor.next_count

减一。

根据分析，补充代码

cond_signal函数

// Unlock one of threads waiting on the condition variable.
void
cond_signal (condvar_t *cvp) {
//LAB7 EXERCISE1: YOUR COD
c701
E
cprintf("cond_signal begin: cvp %x, cvp->count %d, cvp->owner->next_count %d\n", cvp, cvp->count, cvp->owner->next_count);
/*
*      cond_signal(cv) {
*          if(cv.count>0) {
*             mt.next_count ++;
*             signal(cv.sem);
*             wait(mt.next);
*             mt.next_count--;
*          }
*       }
*/
if(cvp->count>0)
{//当前存在执行cond_wait而睡眠的进程
cvp->owner->next_count ++;//睡眠的进程总个数加一
up(&(cvp->sem));//唤醒等待在cv.sem上睡眠的进程
down(&(cvp->owner->next));//自己需要睡眠
cvp->owner->next_count --;//睡醒后等待此条件的睡眠进程个数减一
}
cprintf("cond_signal end: cvp %x, cvp->count %d, cvp->owner->next_count %d\n", cvp, cvp->count, cvp->owner->next_count);
}

cond_wait函数

// Suspend calling thread on a condition variable waiting for condition Atomically unlocks
// mutex and suspends calling thread on conditional variable after waking up locks mutex. Notice: mp is mutex semaphore for monitor's procedures
void
cond_wait (condvar_t *cvp) {
//LAB7 EXERCISE1: YOUR CODE
cprintf("cond_wait begin:  cvp %x, cvp->count %d, cvp->owner->next_count %d\n", cvp, cvp->count, cvp->owner->next_count);
/*
*         cv.count ++;
*         if(mt.next_count>0)
*            signal(mt.next)
*         else
*            signal(mt.mutex);
*         wait(cv.sem);
*         cv.count --;
*/
cvp->count++;//需要睡眠的进程个数加一
if(cvp->owner->next_count > 0)
{
//唤醒进程链表中的下一个进程
up(&(cvp->owner->next));
}
else
{
//唤醒睡在monitor.mutex上的进程
up(&(cvp->owner->mutex));
}
down(&(cvp->sem));//将此进程等待
//睡醒后等待此条件的睡眠进程个数减一
cvp->count--;
cprintf("cond_wait end:  cvp %x, cvp->count %d, cvp->owner->next_count %d\n", cvp, cvp->count, cvp->owner->next_count);
}

  分析完毕后，就可以完成哲学家就餐问题。

phi_take_forks_condvar函数

void phi_take_forks_condvar(int i) {
down(&(mtp->mutex));
//--------into routine in monitor--------------
// LAB7 EXERCISE1: YOUR CODE
// I am hungry
// try to get fork
//哲学家i饥饿
state_condvar[i]=HUNGRY;
// 试图拿叉子
phi_test_condvar(i);
while (state_condvar[i] != EATING)
{
cprintf("phi_take_forks_condvar: %d didn't get fork and will wait\n",i);
//如果得不到叉子就阻塞
cond_wait(&mtp->cv[i]);
}
//--------leave routine in monitor--------------
//如果阻塞则唤醒
if(mtp->next_count>0)
up(&(mtp->next));
else
up(&(mtp->mutex));//离开临界区
}

phi_put_forks_condvar函数

void phi_put_forks_condvar(int i) {
down(&(mtp->mutex));
//--------into routine in monitor--------------
// LAB7 EXERCISE1: YOUR CODE
// I ate over
// test left and right neighbors
//哲学家进餐结束
state_condvar[i]=THINKING;
//看一下左边是否能拿叉子
phi_test_condvar(LEFT);
//看一下右边是否能拿叉子
phi_test_condvar(RIGHT);
//--------leave routine in monitor--------------
if(mtp->next_count>0)
up(&(mtp->next));
else
up(&(mtp->mutex));
}

实验结果

通过

make qemu

得到结果如下图：



make run-matrix



对比实验指导书，实验成功！

实验收获

  通过本次实验，结合哲学家就餐问题，理解了什么是同步互斥，互斥是指某一资源同时只允许一个进程对其进行访问，具有唯一性和排它性，但互斥不用限制进程对资源的访问顺序，即访问可以是无序的。同步是指在进程间的执行必须严格按照规定的某种先后次序来运行，即访问是有序的，这种先后次序取决于要系统完成的任务需求。在进程写资源情况下，进程间要求满足互斥条件。在进程读资源情况下，可允许多个进程同时访问资源。针对开关中断的顺序以及多者互斥问题的理解，在代码的逻辑理解方面还是存在着一些问题。