目录
Uthread: switching between threads (moderate)
6.1 Uthread: switching between threads (moderate)
前言:
本节实验与线程有关,内容是多线程的同步与安全,难度不高,可以提前学习一点线程相关的知识,做起来会更轻松。
本节实验要求:
Uthread: switching between threads (moderate)
在本练习中,您将为用户级线程系统设计上下文切换机制,然后实现它。为了让您开始,您的xv6有两个文件:user/uthread.c和user/uthread_switch.S,以及一个规则:运行在Makefile中以构建uthread
程序。uthread.c包含大多数用户级线程包,以及三个简单测试线程的代码。线程包缺少一些用于创建线程和在线程之间切换的代码。
你的工作:
您的工作是提出一个创建线程和保存/恢复寄存器以在线程之间切换的计划,并实现该计划。完成后,make grade
应该表明您的解决方案通过了uthread
测试。
完成后,在xv6上运行uthread
时应该会看到以下输出(三个线程可能以不同的顺序启动):
$ make qemu
...
$ uthread
thread_a started
thread_b started
thread_c started
thread_c 0
thread_a 0
thread_b 0
thread_c 1
thread_a 1
thread_b 1
...
thread_c 99
thread_a 99
thread_b 99
thread_c: exit after 100
thread_a: exit after 100
thread_b: exit after 100
thread_schedule: no runnable threads
$
该输出来自三个测试线程,每个线程都有一个循环,该循环打印一行,然后将CPU让出给其他线程。
然而在此时还没有上下文切换的代码,您将看不到任何输出。
您需要将代码添加到user/uthread.c中的thread_create()
和thread_schedule()
,以及user/uthread_switch.S中的thread_switch
。一个目标是确保当thread_schedule()
第一次运行给定线程时,该线程在自己的栈上执行传递给thread_create()
的函数。另一个目标是确保thread_switch
保存被切换线程的寄存器,恢复切换到线程的寄存器,并返回到后一个线程指令中最后停止的点。您必须决定保存/恢复寄存器的位置;修改struct thread
以保存寄存器是一个很好的计划。您需要在thread_schedule
中添加对thread_switch
的调用;您可以将需要的任何参数传递给thread_switch
,但目的是将线程从t
切换到next_thread
。
提示:
thread_switch
只需要保存/还原被调用方保存的寄存器(callee-save register,参见LEC5使用的文档《Calling Convention》)。为什么?- 您可以在user/uthread.asm中看到
uthread
的汇编代码,这对于调试可能很方便。 - 这可能对于测试你的代码很有用,使用
riscv64-linux-gnu-gdb
的单步调试通过你的thread_switch
,你可以按这种方法开始:
(gdb) file user/_uthread
Reading symbols from user/_uthread...
(gdb) b uthread.c:60
这将在uthread.c的第60行设置断点。断点可能会(也可能不会)在运行uthread
之前触发。为什么会出现这种情况?
Using threads (moderate)
在本作业中,您将探索使用哈希表的线程和锁的并行编程。您应该在具有多个内核的真实Linux或MacOS计算机(不是xv6,不是qemu)上执行此任务。最新的笔记本电脑都有多核处理器。
这个作业使用UNIX的pthread线程库。您可以使用man pthreads
在手册页面上找到关于它的信息,您可以在web上查看,例如这里、这里和这里。
文件notxv6/ph.c包含一个简单的哈希表,如果单个线程使用,该哈希表是正确的,但是多个线程使用时,该哈希表是不正确的。在您的xv6主目录(可能是~/xv6-labs-2020
)中,键入以下内容:
$ make ph
$ ./ph 1
请注意,要构建ph
,Makefile使用操作系统的gcc,而不是6.S081的工具。ph
的参数指定在哈希表上执行put
和get
操作的线程数。运行一段时间后,ph 1
将产生与以下类似的输出:
100000 puts, 3.991 seconds, 25056 puts/second
0: 0 keys missing
100000 gets, 3.981 seconds, 25118 gets/second
您看到的数字可能与此示例输出的数字相差两倍或更多,这取决于您计算机的速度、是否有多个核心以及是否正在忙于做其他事情。
ph
运行两个基准程序。首先,它通过调用put()
将许多键添加到哈希表中,并以每秒为单位打印puts的接收速率。之后它使用get()
从哈希表中获取键。它打印由于puts而应该在哈希表中但丢失的键的数量(在本例中为0),并以每秒为单位打印gets的接收数量。
通过给ph
一个大于1的参数,可以告诉它同时从多个线程使用其哈希表。试试ph 2
:
$ ./ph 2
100000 puts, 1.885 seconds, 53044 puts/second
1: 16579 keys missing
0: 16579 keys missing
200000 gets, 4.322 seconds, 46274 gets/second
这个ph 2
输出的第一行表明,当两个线程同时向哈希表添加条目时,它们达到每秒53044次插入的总速率。这大约是运行ph 1
的单线程速度的两倍。这是一个优秀的“并行加速”,大约达到了人们希望的2倍(即两倍数量的核心每单位时间产出两倍的工作)。
然而,声明16579 keys missing
的两行表示散列表中本应存在的大量键不存在。也就是说,puts应该将这些键添加到哈希表中,但出现了一些问题。请看一下notxv6/ph.c,特别是put()
和insert()
。
你的工作:
为什么两个线程都丢失了键,而不是一个线程?确定可能导致键丢失的具有2个线程的事件序列。在answers-thread.txt中提交您的序列和简短解释。
[!TIP] 为了避免这种事件序列,请在notxv6/ph.c中的put
和get
中插入lock
和unlock
语句,以便在两个线程中丢失的键数始终为0。相关的pthread调用包括:
pthread_mutex_t lock; // declare a lock
pthread_mutex_init(&lock, NULL); // initialize the lock
pthread_mutex_lock(&lock); // acquire lock
pthread_mutex_unlock(&lock); // release lock
当make grade
说您的代码通过ph_safe
测试时,您就完成了,该测试需要两个线程的键缺失数为0。在此时,ph_fast
测试失败是正常的。
不要忘记调用pthread_mutex_init()
。首先用1个线程测试代码,然后用2个线程测试代码。您主要需要测试:程序运行是否正确呢(即,您是否消除了丢失的键?)?与单线程版本相比,双线程版本是否实现了并行加速(即单位时间内的工作量更多)?
在某些情况下,并发put()
在哈希表中读取或写入的内存中没有重叠,因此不需要锁来相互保护。您能否更改ph.c以利用这种情况为某些put()
获得并行加速?提示:每个散列桶加一个锁怎么样?
Barrier(moderate)
在本作业中,您将实现一个屏障)(Barrier):应用程序中的一个点,所有参与的线程在此点上必须等待,直到所有其他参与线程也达到该点。您将使用pthread条件变量,这是一种序列协调技术,类似于xv6的sleep
和wakeup
。
您应该在真正的计算机(不是xv6,不是qemu)上完成此任务。
文件notxv6/barrier.c包含一个残缺的屏障实现。
$ make barrier
$ ./barrier 2
barrier: notxv6/barrier.c:42: thread: Assertion `i == t' failed.
2指定在屏障上同步的线程数(barrier.c中的nthread
)。每个线程执行一个循环。在每次循环迭代中,线程都会调用barrier()
,然后以随机微秒数休眠。如果一个线程在另一个线程到达屏障之前离开屏障将触发断言(assert)。期望的行为是每个线程在barrier()
中阻塞,直到nthreads
的所有线程都调用了barrier()
。
你的工作:
您的目标是实现期望的屏障行为。除了在ph
作业中看到的lock原语外,还需要以下新的pthread原语;详情请看这里和这里。
// 在cond上进入睡眠,释放锁mutex,在醒来时重新获取
pthread_cond_wait(&cond, &mutex);
// 唤醒睡在cond的所有线程
pthread_cond_broadcast(&cond);
确保您的方案通过make grade
的barrier
测试。
pthread_cond_wait
在调用时释放mutex
,并在返回前重新获取mutex
。
我们已经为您提供了barrier_init()
。您的工作是实现barrier()
,这样panic就不会发生。我们为您定义了struct barrier
;它的字段供您使用。
有两个问题使您的任务变得复杂:
- 你必须处理一系列的
barrier
调用,我们称每一连串的调用为一轮(round)。bstate.round
记录当前轮数。每次当所有线程都到达屏障时,都应增加bstate.round
。 - 您必须处理这样的情况:一个线程在其他线程退出
barrier
之前进入了下一轮循环。特别是,您在前后两轮中重复使用bstate.nthread
变量。确保在前一轮仍在使用bstate.nthread
时,离开barrier
并循环运行的线程不会增加bstate.nthread
。
使用一个、两个和两个以上的线程测试代码。
6.1 Uthread: switching between threads (moderate)
这节实验需要实现用户线程上下文切换的功能,其实与lab3的alarm那个实验有点像,都是需要保存线程上下文也就是寄存器和栈。
首先是修改user/uthread_switch.S,主要是实现保存寄存器和加载新的寄存器的功能:
thread_switch:
sd ra, 0(a0)
sd sp, 8(a0)
sd s0, 16(a0)
sd s1, 24(a0)
sd s2, 32(a0)
sd s3, 40(a0)
sd s4, 48(a0)
sd s5, 56(a0)
sd s6, 64(a0)
sd s7, 72(a0)
sd s8, 80(a0)
sd s9, 88(a0)
sd s10, 96(a0)
sd s11, 104(a0)
ld ra, 0(a1)
ld sp, 8(a1)
ld s0, 16(a1)
ld s1, 24(a1)
ld s2, 32(a1)
ld s3, 40(a1)
ld s4, 48(a1)
ld s5, 56(a1)
ld s6, 64(a1)
ld s7, 72(a1)
ld s8, 80(a1)
ld s9, 88(a1)
ld s10, 96(a1)
ld s11, 104(a1)
ret /* return to ra */
此外,我们还需要在线程的thread结构体中,新增字段来保存寄存器的值:
// user/uthread.c
struct context {
uint64 ra;
uint64 sp;
// callee-saved
uint64 s0;
uint64 s1;
uint64 s2;
uint64 s3;
uint64 s4;
uint64 s5;
uint64 s6;
uint64 s7;
uint64 s8;
uint64 s9;
uint64 s10;
uint64 s11;
};
struct thread {
char stack[STACK_SIZE]; /* the thread's stack */
int state; /* FREE, RUNNING, RUNNABLE */
// 保存线程上下文
struct context threadContext;
};
然后是实现thread_create(),这个函数的作用是创建并初始化一个线程,并设置线程的ra、sp寄存器:
// user/uthread.c
void
thread_create(void (*func)())
{
struct thread *t;
for (t = all_thread; t < all_thread + MAX_THREAD; t++) {
if (t->state == FREE) break;
}
t->state = RUNNABLE;
// ra保存的是返回地址,也就是func的地址
t->threadContext.ra = (uint64)func;
// sp保存的是栈指针
t->threadContext.sp = (uint64)(t->stack) + STACK_SIZE;
}
最后,再实现thread_schedule()函数就行,这个函数主要完成的就是线程的调度工作,也就是调用thread_switch来切换线程上下文:
// user/uthread.c
void
thread_schedule(void)
{
......
if (current_thread != next_thread) { /* switch threads? */
next_thread->state = RUNNING;
t = current_thread;
current_thread = next_thread;
// 表示将线程t的上下文切换成线程current_thread的上下文
thread_switch(&t->threadContext, ¤t_thread->threadContext);
} else
next_thread = 0;
}
6.2 Using threads (moderate)
这一节实验要实现的是线程之间的数据安全问题,主要是用锁来对资源进行保护。代码量非常少,完成的思路就是将原本粒度大的锁住整个哈希表的锁变成粒度小的只锁住一个槽的锁,通过增加一个大小为哈希表size的锁数组,并修改notxv6/ph.c中的put()和get()来实现:
// notxv6/ph.c
pthread_mutex_t lock[NBUCKET];
static
void put(int key, int value)
{
// 获取哈希表中的槽的索引
int i = key % NBUCKET;
// is the key already present?
// 只在对应的槽上加锁
pthread_mutex_lock(&lock[i]);
......
pthread_mutex_unlock(&lock[i]);
}
static struct entry*
get(int key)
{
int i = key % NBUCKET;
pthread_mutex_lock(&lock[i]);
......
pthread_mutex_unlock(&lock[i]);
return e;
}
此外,由于我们新建了一个锁的数组,我们还需要对数组中的每一个锁进行初始化:
// notxv6/ph.c
int
main(int argc, char *argv[])
{
pthread_t *tha;
......
for(int i = 0;i < NBUCKET; i++){
pthread_mutex_init(&lock[i], NULL);
}
......
printf("%d gets, %.3f seconds, %.0f gets/second\n",
NKEYS*nthread, t1 - t0, (NKEYS*nthread) / (t1 - t0));
}
6.3 Barrier(moderate)
这节实验需要利用到条件变量,要求是保证所有参与到循环的线程需要在达到某个条件后停止,直到所有线程都达到这个条件,才能开始下一轮的循环。代码也不难,思路就是每有一个线程达到条件就将计数加一,并等到条件信号达到。当计数和线程大小相等时,条件变量被满足,此时就可以发出条件信号,所有线程可以进入下一次循环,代码如下:
// notxv6/barrier.c
static void
barrier()
{
// YOUR CODE HERE
//
// Block until all threads have called barrier() and
// then increment bstate.round.
//
// 获得的锁会在pthread_cond_wait中被释放
pthread_mutex_lock(&bstate.barrier_mutex);
// 有一个线程完成条件,则满足条件的线程数+1
bstate.nthread++;
// 如果此时线程数 < 参与线程数,则等待条件信号发出
if(bstate.nthread < nthread)
{
pthread_cond_wait(&bstate.barrier_cond, &bstate.barrier_mutex);
}
// 如果满足条件线程数 = 参与线程数,则轮数+1并且发出条件信号
else if(bstate.nthread == nthread)
{
bstate.nthread = 0;
bstate.round++;
pthread_cond_broadcast(&bstate.barrier_cond);
}
pthread_mutex_unlock(&bstate.barrier_mutex);
}