《ucore lab7》实验报告
作者:互联网
资源
练习1: 理解内核级信号量的实现和基于内核级信号量的哲学家就餐问题(不需要编码)
题目
完成练习0后,建议大家比较一下(可用meld等文件diff比较软件) 个人完成的lab6和练习0完成后的刚修改的lab7之间的区别,分析了解lab7采用信号量的执行过程。执行 make grade ,大部分测试用例应该通过。
请在实验报告中给出内核级信号量的设计描述,并说明其大致执行流程。
请在实验报告中给出给用户态进程/线程提供信号量机制的设计方案,并比较说明给内核级提供信号量机制的异同。
解答
1 描述内核级信号量的设计及执行流程
- 信号量结构体的定义如下。可见,信号量结构体由共享变量value和等待队列wait_queue构成,其中wait_queue是一个链表(为简便起见,下文简称为wq)。
typedef struct {
int value;
wait_queue_t wait_queue;
} semaphore_t;
- 信号量初始化。将value设置为输入的值,将wq初始化为空链表。
void sem_init(semaphore_t *sem, int value) {
sem->value = value;
wait_queue_init(&(sem->wait_queue));
}
- 等待队列wq的每个元素均为wait_t结构,其中proc字段用来标记当前等待元素对应的进程,wait_queue用来标识当前等待元素所在的等待队列wq,wait_link用来建立当前等待元素与等待队列wq的链接。
typedef struct {
struct proc_struct *proc;
uint32_t wakeup_flags;
wait_queue_t *wait_queue;
list_entry_t wait_link;
} wait_t;
- up操作。进行up操作前需要暂时屏蔽中断。如果等待队列wq没有元素,则将value加1然后返回,否则唤醒wq的首元素,即将其从wq中删除,然后将对应进程加入RUNNABLE队列。疑问:如果等待队列非空,为什么不需要将value加1?答:这和down是对称的。如果wq非空,意味着value <= 0,更具体地说,wq中的每个元素在执行down操作时value <= 0,根据down的实现,此时不会将value减1,因此up操作中唤醒一个wq中的元素也不需要将value加1.这和PPT中的实现不太相同,PPT中不管value是多少,up操作开头就加1,down操作开头就减1.但两种实现都是有效的。
if ((wait = wait_queue_first(&(sem->wait_queue))) == NULL) {
sem->value ++;
}
else {
assert(wait->proc->wait_state == wait_state);
wakeup_wait(&(sem->wait_queue), wait, wait_state, 1);
}
- down操作。进行down操作前同样暂时屏蔽中断。如果value大于0,则将其减1,然后返回。否则,设置当前进程的state为SLEEPING,并将当前进程加入等待队列,然后调用schedule让出CPU,进入睡眠,等到被唤醒时,再从wq中将其删除。
if (sem->value > 0) {
sem->value --;
local_intr_restore(intr_flag);
return 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);
wait_current_del(&(sem->wait_queue), wait);
local_intr_restore(intr_flag);
if (wait->wakeup_flags != wait_state) {
return wait->wakeup_flags;
}
return 0;
- try_down操作。检查value,若大于0,则将value减1,并返回1;若不大于0,则返回0.
bool try_down(semaphore_t *sem) {
bool intr_flag, ret = 0;
local_intr_save(intr_flag);
if (sem->value > 0) {
sem->value --, ret = 1;
}
local_intr_restore(intr_flag);
return ret;
}
2 描述基于内核级信号量的哲学家就餐问题的实现
内核线程initproc执行init_main,init_main执行check_sync,check_sync内部测试哲学家就餐问题的解决方案。
check_sync分为两部分,初始化解决哲学家就餐问题需要用到的信号量和条件变量。现在只关注信号量部分。首先调用sem_init初始化信号量,将信号量的value设置为1、wq初始化为空,然后调用kernel_thread创建了5个使用信号量的内核线程。
这5个使用信号量的内核线程的执行函数都是philosopher_using_semaphore。在philosopher_using_semaphore开头首先打印哲学家ID,然后进行4次循环,即进行4次思考和吃饭。首先哲学家思考10个ticks,这通过调用do_sleep来模拟。do_sleep首先将当前进程的state设置为SLEEPING,然后为进程创建一个expires为10 ticks的定时器,并添加到定时器列表中,最后调用schedule让出CPU给其他进程。
10个ticks过去后,思考完毕,哲学家调用phi_take_forks_sema尝试拿起两把叉子。为了保护state_sema和s被互斥访问,设置了互斥量mutex。因此, phi_take_forks_sema对mutex执行down操作,进入临界区,然后将自己的state_sema标记为HUNGRY,接着调用phi_test_sema来检查是否能拿到两只叉子。若能拿到,则将自己的state_sema标记为EATING,然后离开临界区,开始吃饭,时间同样为10个ticks;若不能拿到,则通过对s[i]执行down操作而堵塞。
10个ticks过去后,吃饭完毕,哲学家调用phi_put_forks_sema把两把叉子同时放回桌子。同样,为了保护state_sema和s被互斥访问,phi_put_forks_sema先对mutex执行down操作,进入临界区,然后将自己的state_sema标记为THINKING,接着两次调用phi_test_sema来检查左右邻居是否能进餐。若能就餐,则对s[i]执行up操作,这时会唤醒其他哲学家。等到哲学家离开临界区、进入下一次的思考后,会发生进程切换,使得其他哲学家可以就餐。
3 输出结果
输出结果如下所示。下面简单分析下从开始到5位哲学家均完成第一次就餐的执行过程。
I am No.0 philosopher_sema
Iter 1, No.0 philosopher_sema is thinking
I am No.1 philosopher_sema
Iter 1, No.1 philosopher_sema is thinking
I am No.2 philosopher_sema
Iter 1, No.2 philosopher_sema is thinking
I am No.3 philosopher_sema
Iter 1, No.3 philosopher_sema is thinking
I am No.4 philosopher_sema
Iter 1, No.4 philosopher_sema is thinking
I am the child.
waitpid 8 ok.
exit pass.
Iter 1, No.0 philosopher_sema is eating
Iter 1, No.2 philosopher_sema is eating
Iter 2, No.0 philosopher_sema is thinking
Iter 1, No.4 philosopher_sema is eating
Iter 2, No.2 philosopher_sema is thinking
Iter 1, No.1 philosopher_sema is eating
Iter 2, No.4 philosopher_sema is thinking
Iter 1, No.3 philosopher_sema is eating
Iter 2, No.1 philosopher_sema is thinking
Iter 2, No.0 philosopher_sema is eating
Iter 2, No.3 philosopher_sema is thinking
Iter 2, No.2 philosopher_sema is eating
Iter 3, No.0 philosopher_sema is thinking
Iter 2, No.4 philosopher_sema is eating
Iter 3, No.2 philosopher_sema is thinking
Iter 2, No.1 philosopher_sema is eating
Iter 3, No.4 philosopher_sema is thinking
Iter 2, No.3 philosopher_sema is eating
Iter 3, No.1 philosopher_sema is thinking
Iter 3, No.0 philosopher_sema is eating
Iter 3, No.3 philosopher_sema is thinking
Iter 3, No.2 philosopher_sema is eating
Iter 4, No.0 philosopher_sema is thinking
Iter 3, No.4 philosopher_sema is eating
Iter 4, No.2 philosopher_sema is thinking
Iter 3, No.1 philosopher_sema is eating
Iter 4, No.4 philosopher_sema is thinking
Iter 3, No.3 philosopher_sema is eating
Iter 4, No.1 philosopher_sema is thinking
Iter 4, No.0 philosopher_sema is eating
Iter 4, No.3 philosopher_sema is thinking
Iter 4, No.2 philosopher_sema is eating
No.0 philosopher_sema quit
Iter 4, No.4 philosopher_sema is eating
No.2 philosopher_sema quit
Iter 4, No.1 philosopher_sema is eating
No.4 philosopher_sema quit
Iter 4, No.3 philosopher_sema is eating
No.1 philosopher_sema quit
No.3 philosopher_sema quit
check_sync调用kernel_thread创建了5个哲学家线程,它们依次进入RUNNABLE队列rq中,此时rq中的元素从头到尾依次是:0,1,2,3,4.
哲学家0首先被执行,进入philosopher_using_semaphore,打印自己的ID,然后开始思考(调用do_sleep来延时)。哲学家1~4执行类似过程,最终rq为空,timer依次为0,1,2,3,4.
哲学家0的延时最先结束,因此回到philosopher_using_semaphore继续执行,接下来是拿起两只叉子,由于哲学家0是第一个拿叉子的,可以畅通无阻地拿起叉子吃饭(调用do_sleep来延时)。此时只有哲学家0占用叉子,rq为空,timer依次为1,2,3,4,0.
接着哲学家1的延时结束,同样试图拿起两把叉子,发现左边的叉子被哲学家0拿了,因此无法吃饭,只好把自己的state标志为SLEEPING,然后对s[1]执行down操作,把自己添加到s[1]->wq中,并调用schedule让出CPU。此时只有哲学家0占用叉子,rq为空,timer依次为2,3,4,0.
哲学家2~4的过程类似,其中哲学家2可以拿起叉子吃饭,哲学家3和4吃不了饭,均通过down操作进入堵塞状态。此时哲学家0和2占用叉子,rq为空,timer依次为0,2.
哲学家0的延时再次结束,这时他同时放下两把叉子,并且检查到左边的哲学家4满足就餐条件,因此对s[4]执行up操作,从而把哲学家4唤醒;检查到右边的哲学家1不满足就餐条件(1右边的叉子还被2占用),因此不做处理。最后哲学家0进行下一轮的思考。此时只有哲学家2占用叉子,rq为4,timer为2,0.
由于哲学家4已被唤醒,哲学家1和3被堵塞,因此接下来是哲学家4继续运行,此时rq清空。这里会不会出现哲学家2的延时结束后先于哲学家4运行呢?不会,因为即使哲学家2的定时结束了,也要先加入rq等待调度。哲学家4拿起叉子,开始吃饭。此时哲学家2和4占用叉子,rq为空,timer为2,0,4.
哲学家2的延时结束后重新执行,首先检查到左边的哲学家1满足就餐条件,因此对s[1]执行up操作,从而把哲学家1唤醒。然后检查到右边的哲学家3不满足就餐条件(3右边的叉子被4占用),因此不做处理。最后哲学家2进行下一轮的思考。此时只有哲学家4占用叉子,rq为1,timer为0,4,2.
哲学家1被唤醒,开始拿起叉子吃饭。此时哲学家1和4在用叉子,rq为空,timer为0,4,2,1.
哲学家0的延时结束后,试图拿起叉子吃饭,但左右叉子均被占用,因此被堵塞。此时哲学家1和4占用叉子,rq为空,timer为4,2,1.
哲学家4的延时结束后,同时放下2个叉子,然后检查左边的哲学家3满足就餐条件,因此对s[3]执行up操作,从而把哲学家3唤醒。再检查右边的哲学家0,发现不满足就餐条件,因此不作处理。最后哲学家4进行下一轮的思考。此时只有哲学家1占用叉子,rq为3,timer为2,1,4.
哲学家3被唤醒,开始拿起叉子吃饭。此时哲学家1和3在用叉子,rq为空,timer为2,1,4,3. 后续执行流程类似,不再赘述。
4 描述给用户态进程/线程提供信号量机制的设计方案,并与内核级做对比(待完成)
练习2: 完成内核级条件变量和基于内核级条件变量的哲学家就餐问题(需要编码)
题目
首先掌握管程机制,然后基于信号量实现完成条件变量实现,然后用管程机制实现哲学家就餐问题的解决方案(基于条件变量) 。执行: make grade 。如果所显示的应用程序检测都输出ok,则基本正确。如果只是某程序过不去,比如matrix.c,则可执行 make run-matrix命令来单独调试它。大致执行结果可看附录。
请在实验报告中给出内核级条件变量的设计描述,并说明其大致执行流程。
请在实验报告中给出给用户态进程/线程提供条件变量机制的设计方案,并比较说明给内核级提供条件变量机制的异同。
请在实验报告中回答:能否不用基于信号量机制来完成条件变量?如果不能,请给出理由,如果能,请给出设计说明和具体实现。
解答
1 描述内核级条件变量的设计及执行流程
- 条件变量的结构体定义如下。主要是一个信号量sem、一个表示等待条件变量的进程数目count,而owner用来寻找条件变量所属的管程。
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;
- 条件变量的主要操作有2个:wait和signal。wait用于进程因无法获取所需的资源时而将自己堵塞,signal用于另一个进程释放或生成相关资源后通知之前处于wait状态的进程而解除堵塞。cond_wait的实现如下所示。首先将count加1,表示自己将要等待条件变量。然后判断管程的next_count是否大于0.此时未完全理解,大致分析一下:如果next_count大于0,说明是其他进程执行signal操作而将自己唤醒、并让出CPU给自己执行的,因此这里需要对管程的next信号量执行up操作,把发布signal信号的进程唤醒,不然对方将一直堵塞。如果next_count不大于0,说明没人因发布signal信号而堵塞,这时只需对管程的mutex执行up操作而退出临界区。接着对sem执行down操作,堵塞自己,让出CPU给其他进程。等到其他进程发布signal信号而唤醒本进程时,再将count减1,表示自己不再等待条件变量。
cvp->count++;
if (cvp->owner->next_count > 0)
{
up(&cvp->owner->next);
}
else
{
up(&cvp->owner->mutex);
}
down(&cvp->sem);
cvp->count--;
- cond_signal的实现如下所示。首先判断count是否大于0,若否则说明没有进程在等待条件变量,因此不作任何处理。若是,则说明有进程在等待条件变量,首先将管程的next_count加1,表示自己由于发布signal给其他进程解堵塞而将自己堵塞,然后对sem执行up操作,从而把之前等待信号量sem的进程唤醒,然后对管程的next执行down操作,从而将自己堵塞。等到其他进程唤醒本进程后,在将管程的next_count减1,表示自己不再等待next信号量。
if (cvp->count > 0)
{
cvp->owner->next_count++;
up(&cvp->sem);
down(&cvp->owner->next);
cvp->owner->next_count--;
}
2 用管程机制(基于条件变量)解决哲学家就餐问题
原代码中已经提供哲学家就餐问题的大部分实现,再结合注释不难完成剩下的编码。无论是用管程还是信号量,此问题的框架是相同的:哲学家都是先思考一段时间,然后拿起叉子吃饭,吃了一段时间后,放下叉子继续思考,如此反复。思考和吃饭的过程都通过do_sleep来实现,实际上就是利用定时器进行延时。因此,主要的差别在于拿叉子和放叉子两个功能的实现。
拿叉子(phi_take_forks_condvar):首先对管程的mutex执行down操作进入临界区,这是确保任何时候最多只有一个进程进入管程。然后将自己的state设置为HUNGRY。接着测试是否满足就餐条件:自己的state是HUNGRY,而且左右的哲学家的state都不是EATING。如果满足,则将自己的state设置为EATING,然后对管程的mutex执行up操作而退出临界区,从而完成拿叉子操作。如果不满足就餐条件,则调用cond_wait将自己堵塞。
放叉子(phi_put_forks_condvar):同样,首先对管程的mutex执行down操作进入临界区,然后将自己的state设置为THINKING。接下来测试左右哲学家是否满足就餐条件,若满足,则调用cond_signal将对应进程唤醒,而把自己堵塞。
3 输出结果
输出结果如下所示。下面简单分析从开始到5位哲学家均完成第一次就餐的执行流程。
Iter 1, No.0 philosopher_condvar is thinking
I am No.1 philosopher_condvar
Iter 1, No.1 philosopher_condvar is thinking
I am No.2 philosopher_condvar
Iter 1, No.2 philosopher_condvar is thinking
I am No.3 philosopher_condvar
Iter 1, No.3 philosopher_condvar is thinking
I am No.4 philosopher_condvar
Iter 1, No.4 philosopher_condvar is thinking
Iter 1, No.0 philosopher_condvar is eating
Iter 1, No.2 philosopher_condvar is eating
Iter 1, No.4 philosopher_condvar is eating
Iter 2, No.0 philosopher_condvar is thinking
Iter 1, No.1 philosopher_condvar is eating
Iter 2, No.2 philosopher_condvar is thinking
Iter 1, No.3 philosopher_condvar is eating
Iter 2, No.4 philosopher_condvar is thinking
Iter 2, No.1 philosopher_condvar is thinking
Iter 2, No.0 philosopher_condvar is eating
Iter 2, No.2 philosopher_condvar is eating
Iter 2, No.3 philosopher_condvar is thinking
Iter 2, No.4 philosopher_condvar is eating
Iter 3, No.0 philosopher_condvar is thinking
Iter 2, No.1 philosopher_condvar is eating
Iter 3, No.2 philosopher_condvar is thinking
Iter 2, No.3 philosopher_condvar is eating
Iter 3, No.4 philosopher_condvar is thinking
Iter 3, No.0 philosopher_condvar is eating
Iter 3, No.1 philosopher_condvar is thinking
Iter 3, No.2 philosopher_condvar is eating
Iter 3, No.3 philosopher_condvar is thinking
Iter 3, No.4 philosopher_condvar is eating
Iter 4, No.0 philosopher_condvar is thinking
Iter 3, No.1 philosopher_condvar is eating
Iter 4, No.2 philosopher_condvar is thinking
Iter 3, No.3 philosopher_condvar is eating
Iter 4, No.4 philosopher_condvar is thinking
Iter 4, No.0 philosopher_condvar is eating
Iter 4, No.1 philosopher_condvar is thinking
Iter 4, No.2 philosopher_condvar is eating
Iter 4, No.3 philosopher_condvar is thinking
Iter 4, No.4 philosopher_condvar is eating
No.0 philosopher_condvar quit
Iter 4, No.1 philosopher_condvar is eating
No.2 philosopher_condvar quit
Iter 4, No.3 philosopher_condvar is eating
No.4 philosopher_condvar quit
No.1 philosopher_condvar quit
No.3 philosopher_condvar quit
内核线程initproc调用check_sync检查使用管程来解决哲学家就餐问题的方案。check_sync首先调用monitor_init初始化管程,然后调用kernel_thread创建5个内核线程,分别对应5位哲学家,并先将5位哲学家的state初始化为THINKING。此时无人占用叉子,RUNNABLE队列rq的元素依次为0,1,2,3,4,timer为空。
5个哲学家线程依次执行philosopher_using_condvar,打印自己的ID,然后开始思考(实际上是调用do_sleep进行延时)。此时无人占用叉子,rq为空,timer依次是0,1,2,3,4.
哲学家0的延时最先结束,调用phi_take_forks_condvar试图拿起2把叉子就餐,整个过程如下:对mtp->mutex执行down操作进入临界区(以保证互斥执行此函数),将自己的state设置为HUNGRY,调用phi_test_condvar拿到2把叉子,将自己的state改为EATING,调用cond_signal唤醒之前由于执行cond_wait而堵塞的进程(由于没有,此处啥也没做)。然后对mtp->mutex执行up操作而离开临界区,开始吃饭(实际上是调用do_sleep来延时)。此时哲学家0占用叉子,rq为空,timer是1,2,3,4,0.
接着哲学家1延时结束,同样调用phi_take_forks_condvar试图拿起2把叉子就餐,但由于左边的叉子正在被哲学家0占用,哲学家1只能调用cond_wait进行等待。具体而言包括3步:将mtp->cv[1]->count加1,表示自己要等待该条件变量,然后对mtp->mutex执行up操作而离开临界区,最后对mtp->cv[1]->sem执行down操作而堵塞。此时哲学家0占用叉子,rq为空,timer是2,3,4,0.
哲学家2的执行过程与哲学家0相同,哲学家3、4的执行过程和哲学家1相同。最终,哲学家0和2占用叉子,rq为空,timer为0,2。
哲学家0延时结束,调用phi_put_forks_condvar同时放下2把叉子。首先对mtp->mutex执行down操作而进入临界区,将自己的state修改为THINKING,然后调用phi_test_condvar检查左右的哲学家状态。首先检查到左边的哲学家4满足就餐条件,于是将哲学家4的state修改为EATING,并对mtp->cv[4]执行cond_signal以唤醒哲学家4.具体而言包括3步:将mtp->next_count加1,表示唤醒哲学家4后自己要进入等待状态,然后对mtp->cv[4]->sem执行up操作,这将唤醒哲学家4,最后对mtp->next执行down操作而堵塞。这时哲学家2占用叉子,rq为4,timer为2.
哲学家4被唤醒后,退出cond_wait,对mtp->next执行up操作,从而将哲学家0唤醒。然后哲学家4开始吃饭。(这里可以看到管程的“临时退出临界区”的特点:上一步中哲学家0进入临界区,发现哲学家4满足就餐条件后,将其唤醒,让哲学家4临时进入临界区吃饭,最后哲学家4再把哲学家0唤醒,让哲学家0继续执行。)此时哲学家2和4占用叉子,rq为0,timer为2,4.
哲学家0继续检查右边的哲学家1,发现其不满足就餐条件,不作处理,然后对mtp->mutex执行up操作而退出临界区。最后哲学家0进入下一轮的思考。此时哲学家2和4占用叉子,rq为空,timer为2,4,0.
哲学家2延时结束,调用phi_put_forks_condvar同时放下2把叉子。其执行流程与步骤6类似,只是哲学家2唤醒的是哲学家1.此时哲学家4占用叉子,rq为1,timer为4,0.
哲学家1被唤醒后的执行流程与步骤7类似:退出cond_wait,对mtp->next执行up操作,从而将哲学家2唤醒。然后哲学家1开始吃饭。此时哲学家1和4占用叉子,rq为2,timer为4,0,1.
哲学家2被唤醒后的执行流程与步骤8类似:继续检查出右边的哲学家3,发现其不满足就餐条件,不作处理,然后对mtp->mutex执行up操作而退出临界区。最后哲学家2进入下一轮的思考。此时哲学家1和4占用叉子,rq为空,timer为4,0,1.
哲学家4延时结束,调用phi_put_forks_condvar同时放下2把叉子,其执行流程与步骤6类似:首先检查到左边的哲学家3满足就餐条件,于是将其唤醒,并将自己堵塞。此时哲学家1占用叉子,rq为3,timer为0,1.
哲学家3被唤醒后的执行流程与步骤7类似:退出cond_wait,对mtp->next执行up操作,从而将哲学家4唤醒。然后哲学家3开始吃饭。此时哲学家1和3占用叉子,rq为4,timer为0,1,3.
4 描述给用户态进程/线程提供条件变量机制的设计方案,并与内核级做对比(待完成)
5 回答问题:能否不用基于信号量机制来完成条件变量(待完成)
扩展练习 Challenge : 在ucore中实现简化的死锁和重入探测机制(待实现)
题目
在ucore下实现一种探测机制,能够在多进程/线程运行同步互斥问题时,动态判断当前系统是否出现了死锁产生的必要条件,是否产生了多个进程进入临界区的情况。 如果发现,让系统进入monitor状态,打印出你的探测信息。
扩展练习 Challenge : 参考Linux的RCU机制,在ucore中实现简化的RCU机制
题目
在ucore 下实现Linux的RCU同步互斥机制。可阅读相关Linux内核书籍或查询网上资料,可了解RCU的设计实现细节,然后简化实现在ucore中。 要求有实验报告说明你的设计思路,并提供测试用例。参考资料: Linux 2.6内核中新的锁机制--RCU
标签:哲学家,ucore,condvar,Iter,lab7,philosopher,叉子,实验报告,sema 来源: https://www.cnblogs.com/wuhualong/p/ucore_lab7_report.html