Project 02: xv6 RISC-V Kernel-Level Threads Implementation - wiki

작성 2026. 6. 12.·수정 2026. 6. 12.

본 project의 핵심 목표는 xv6 RISC-V 기반 운영체제에 kernel-level thread (커널 수준 thread) 기능을 추가하는 것이다. xv6는 MIT에서 교육 목적으로 설계한 간결한 UNIX 기반 OS로, 다중 프로세스(multiprocessing)는 지원하지만 다중 스레드(multithreading)는 지원하지 않는다. 본 project는 기존 xv6의 process 관리 구조를 최대한 활용하면서, thread의 실행 컨텍스트(context), 자원 공유 방식, 동기화 시나리오 등을 구현하는 데 중점을 둔다.

Thread는 process와 달리 주소 공간을 공유하며, 사용자 수준 stack과 register만 독립적이다. 따라서 xv6의 proc 구조체를 그대로 재활용하되, thread 여부를 나타내는 flag is_thread를 새롭게 추가하고, 그에 따라 clone(), join(), exec(), kill(), sleep(), wakeup() 등의 동작을 수정하였다.

Design Principles and Requirements Strategy

Thread의 본질은 하나의 주소 공간을 공유하는 다중 실행 경로이다. 따라서 clone()으로 새 thread를 생성할 때에는 fork()처럼 새로운 pagetable을 복사해서는 안 되고, 기존 process의 pagetable을 공유해야 한다. 단, trapframe과 context는 thread마다 개별적으로 가져야 하므로 allocproc()을 통해 새로운 proc을 할당한다.

변경 사항

uvmshare() 함수를 직접 구현하여, 부모의 user PTE를 자식 pagetable에 직접 매핑함.
clone()에서 np->pagetable = proc_pagetable(np); 후 uvmshare(np->pagetable, p->pagetable, p->sz); 호출

2. User Stack Separation

각 thread는 독립된 사용자 stack을 필요로 한다. 따라서 사용자 영역에서 thread_create()가 호출되면, sbrk(PGSIZE)로 1page 단위의 stack memory를 할당하고, 해당 주소를 clone()에 인자로 전달해야 한다. kernel에서는 trapframe->sp를 해당 주소의 top(+PGSIZE)로 설정하여 실행을 개시한다.

변경 사항

thread_create()에서 page-aligned stack을 확보 (s = sbrk(PGSIZE)), 실패 시 -1 반환
clone() 내에서 stack 유효성 검증: null 체크, page-alignment 확인, walkaddr()로 물리 주소 검증

3. Function Pointer-Based Thread Entry Point

xv6에서는 유저 함수 포인터를 직접 trapframe에 설정하여 진입점을 제공해야 한다. 따라서 clone()에서 np->trapframe->epc = (uint64)fcn;으로 fcn을 설정하고, arg1과 arg2는 각각 a0, a1 register에 세팅한다. 이로써 새로 생성된 thread는 usertrapret() 이후 해당 함수로 jump하게 된다.

특이점

본 과제에서는 fcn == 0x0 인 경우가 정상적이며, 과제 명세에서 제공한 테스트가 이를 강제적으로 설정해두었음 → 무효 주소가 아님
따라서 fcn == 0일 경우 예외 처리하지 않도록 함

4. Thread Identification (`is_thread`)

process와 thread를 구분하기 위해 proc 구조체에 is_thread flag를 추가하였다. 이를 통해 join(), exec(), kill() 등에서 조건 분기를 수행할 수 있다.

적용 위치

clone()에서는 np->is_thread = 1;
fork()에서는 np->is_thread = 0;로 명시적으로 초기화

5. Stack Address Reclamation on Exit

thread가 종료되면, 그 thread가 사용하던 stack은 더 이상 사용되지 않으므로, join() 시 해당 주소를 user에게 넘겨 sbrk(-PGSIZE)로 memory를 반납해야 한다.

구현 방식

clone() 시 np->ustack = (uint64)stack;으로 저장
join() 시 copyout()을 통해 user stack 주소 전달
thread_join()에서 sbrk(-PGSIZE)로 회수

6. Remove All Threads on `exec()`

exec()는 해당 process의 pagetable을 완전히 덮어씌우는 작업이다. 따라서 같은 pagetable을 공유하는 다른 thread들도 모두 제거하지 않으면 memory corruption이 발생한다.

해결 방식

exec() 진입 시, proc[NPROC]을 순회하며 pagetable == p->pagetable && p != self인 모든 proc에 대해 freeproc() 호출
이후 새로운 pagetable을 proc_pagetable()로 재생성하고, ELF 바이너리 로드 수행

7. Terminate All Threads on `kill()`

RISC-V에서는 process를 죽이기 위해선 그 주소 공간을 공유하는 모든 thread를 종료시켜야 한다. 따라서 kill(pid)는 단일 pid를 대상으로 하되, 내부적으로는 해당 pagetable을 공유하는 모든 proc을 종료 처리해야 한다.

변경 사항

kill() 내부에서 target->pagetable을 기준으로, 같은 pagetable을 공유하는 모든 proc에 대해 p->killed = 1 설정
SLEEPING 상태인 thread는 RUNNABLE로 변경하여 sched()에 진입 가능하게 함

8. Separate wait/join

기존의 wait()는 process만 수거해야 한다.
thread는 join()을 통해 수거하므로 wait()와는 독립적으로 구현된다.
join()은 proc[NPROC]을 순회하며 parent == myproc()이고 is_thread == 1이며 ZOMBIE 상태인 thread를 찾아 회수한다.

9. Guarantee sleep/wakeup Semantics

thread가 sleep() 상태에 들어갈 때, p->lock을 반드시 먼저 획득한 후 sched()로 넘겨야 wakeup()에서의 동기화 문제가 발생하지 않는다. 이 구조는 기존 xv6에서 그대로 유지되며, thread 환경에서도 문제가 없다.

Design Key Summary

Element	Implementation Strategy Summary
Address Space	`uvmshare()`로 parent의 pagetable 공유
User Stack	`sbrk(PGSIZE)`로 확보, `clone()`에 전달하여 `trapframe->sp` 설정
Function Pointer Entry	`trapframe->epc = fcn`
Argument Passing	`a0 = arg1`, `a1 = arg2`
TCB Separation	`allocproc()` → 독립된 trapframe/context
Thread Identification	`is_thread == 1`
`exec` Cleanup	동일 pagetable 공유하는 proc 전부 `freeproc()`
join Collection	`copyout()`으로 stack 주소 유저에게 전달
`kill()` Extension	같은 pagetable 가진 모든 proc에 대해 `killed = 1` 설정
Synchronization	`sleep()` 전 `p->lock` 확보, `sched()` 이후 wakeup 가능 보장

이러한 일관된 설계를 기반으로, xv6 위에 안전하고 가벼운 kernel thread 시스템을 구현할 수 있었으며, 이는 과제 명세에서 제공한 thread_test.c의 모든 테스트를 통과함으로써 그 기능적 완성도를 입증하였다.

Implementation

Overall Structure Overview

이번 project는 xv6의 kernel과 사용자 영역 양쪽에 걸쳐 thread 시스템 전반을 아우르는 구현 변경을 필요로 한다. 구현은 크게 아래 4가지 layer로 나뉜다.

시스템 콜 인터페이스 (sysproc.c)
kernel 내부 기능 (proc.c)
사용자 수준 라이브러리 (user/thread.c, thread.h)
빌드 시스템 및 실행 파일 구성 (Makefile 변경)

각 영역에 대해 세부 구현과 핵심 변경 포인트를 순서대로 설명할 것이다.

1. System Call Implementation (`kernel/sysproc.c`)

`sys_clone()`

uint64 sys_clone(void)
{
  uint64 f, a1, a2, s;
  argaddr(0, &f);
  argaddr(1, &a1);
  argaddr(2, &a2);
  argaddr(3, &s);
  return clone((void (*)(void*, void*))f, (void*)a1, (void*)a2, (void*)s);
}

argaddr()는 반환형이 void이므로, argraw() 값을 간접적으로 참조하여 처리한다.
인자의 순서와 의미는 clone(void(*fcn)(void*,void*), void*, void*, void*)와 정확히 일치하도록 전달된다.
함수 포인터 주소(fcn)도 user space 값이므로 uint64로 처리한다.

sys_join()

uint64 sys_join(void)
{
  uint64 p;
  argaddr(0, &p);
  return join((void**)p);
}

join()은 (void**) 형태로 user stack address를 전달받는다.
void **stack 형태를 uint64로 받되, 커널 내부에서는 type casting으로 복원한다.

2. Kernel Internal Functions (`kernel/proc.c`)

`clone()`

allocproc()을 통해 새로운 TCB를 할당한다.
uvmshare()로 부모와 동일한 pagetable을 공유한다.
trapframe은 부모의 것을 복사하고, epc/sp/a0/a1 등은 인자로 주어진 값을 반영해 설정한다.
ofile[]과 cwd는 filedup(), idup()을 통해 복사한다.
RUNNABLE로 전환되면 scheduler에 의해 실행된다.

np->trapframe->epc = (uint64)fcn;
np->trapframe->sp  = (uint64)stack + PGSIZE;
np->trapframe->a0  = (uint64)arg1;
np->trapframe->a1  = (uint64)arg2;

np->ustack = (uint64)stack;은 join에서 stack 주소를 유저에 전달하기 위해 따로 저장하는 값이다.

`join()`

proc[] 배열 전체를 순회하며, parent == myproc()이면서 is_thread == 1인 자식만 확인한다.
state == ZOMBIE인 thread를 발견하면 freeproc()으로 회수하고, 그 thread의 ustack 값을 copyout()을 통해 유저에게 전달한다.
수거할 thread가 없으면 sleep 상태로 대기한다.

`exec()`

for(struct proc *q = proc; q < &proc[NPROC]; q++) {
  if(q != p && q->pagetable == p->pagetable) {
    acquire(&q->lock);
    freeproc(q);
    release(&q->lock);
  }
}

exec을 호출한 현재 thread를 제외한, 같은 주소 공간을 공유하는 thread를 모두 제거한다.
이 동작은 새로운 pagetable을 세팅하기 전에 반드시 이루어져야 한다.

`kill()`

for (p = proc; p < &proc[NPROC]; p++) {
  if (p->pagetable == target->pagetable) {
    p->killed = 1;
    if (p->state == SLEEPING)
      p->state = RUNNABLE;
  }
}

단일 pid가 아닌 동일 주소 공간(pagetable)을 공유하는 모든 proc에 대해 killed = 1 설정
이는 multi-thread 환경에서 올바른 kill semantics를 보장하기 위함이다.

`fork()`

기존과 거의 동일하나, is_thread = 0으로 초기화하여 완전한 process 복제가 되도록 한다.
thread가 아닌 process는 반드시 독립적인 주소 공간을 가진다.

3. User-Level Library (`user/thread.c`, `user/thread.h`)

`thread_create()`

void *s = sbrk(PGSIZE);
if (s == (void*)-1 || (uint64)s % PGSIZE) return -1;
return clone(f, a1, a2, s);

Stack은 반드시 4KB 단위로 page-aligned 되어야 하며, 그렇지 않으면 clone이 실패한다.
stack 할당은 동적이며, 유저가 직접 메모리를 할당하지 않아도 내부적으로 처리된다.

`thread_join()`

void *s = 0;
int pid = join(&s);
if (pid > 0 && s) sbrk(-PGSIZE);
return pid;

join이 성공적으로 종료된 thread의 stack 주소를 전달해주면, 이를 sbrk(-PGSIZE)로 반납하여 memory leak을 방지한다.

thread.h

int thread_create(void (*fcn)(void*, void*), void *arg1, void *arg2);
int thread_join(void);

사용자 레벨 API는 기존 pthread 스타일을 모방하여 최소한의 인터페이스를 제공한다.
실제 시스템 콜은 내부적으로 clone/join을 호출한다.

4. Build Configuration Changes (`Makefile.user`)

$U/_thread_test: $U/thread_test.o $U/thread.o $(ULIB)
$U/_thread_fcn:  $U/thread_fcn.o  $(ULIB)

별도로 thread.o를 링크에 포함해야 thread 라이브러리가 연결된다.

entry("clone");
entry("join");

user/usys.pl 또는 equivalent 파일에서 system call table에 clone과 join을 명시적으로 추가해야 user code에서 호출 가능하다.

Summary: Overall Flow

Implementation Target	Role Summary
`clone()`	새로운 TCB(proc), 공유된 주소 공간, 독립된 trapframe 생성
`join()`	종료된 thread 회수 및 stack 주소 반환
`exec()`	기존 thread 정리 후 새로운 주소 공간 로딩
`kill()`	thread 포함 모든 실행 컨텍스트 종료
`thread_create()`	스택 할당 + clone 시스템 콜 래핑
`thread_join()`	`join` 호출 후 스택 반납

이로써 xv6 내에 경량화된 multithreading 환경이 구축되며, fork와 exec의 기존 의미를 침해하지 않으면서도 thread 기반 병렬 처리와 자원 공유가 가능해진다.

Results

각 test에서 수업에서 제공된 출력 예시와 실제 실행 결과의 차이를 비교하고, 그 차이가 발생한 원인을 분석하며, 결과가 논리적으로 타당한지를 설명한다. 아래는 user/thread_test.c 실행 결과이다. 총 6개의 test를 모두 통과하였으며, 각각의 test는 특정 thread 기능의 정상 작동 여부를 확인한다.

Comparison

예시 출력에서는 thread 1, 2, 3이 먼저 실행되고 종료된 뒤, thread 0이 마지막에 실행된다.
실제 결과에서는 thread 0이 가장 먼저 실행을 시작하고, 그 뒤로 1~4번 thread가 순차적으로 실행된다.

Analysis

thread 0이 먼저 실행되는 것은 스케줄링 방식의 차이에 따른 것이다.
각 thread의 실행 순서와 종료 시점은 예시와 다르지만, 전역 변수의 수정 및 main thread에서 그 결과를 확인하는 흐름은 동일하게 유지된다.

Conclusion

논리적으로 문제가 없으며, xv6의 round-robin scheduler에 따라 실행 순서는 달라질 수 있으므로 출력 순서의 차이는 허용되는 것으로 봐야 할 것이다.

TEST#2: Argument Passing and Independent Execution

Comparison

예시에서는 각 thread가 전달받은 iter 값을 정확히 출력한다.
실제 결과에서도 iter 값이 0부터 4000까지 정확히 출력된다.

Conclusion

출력 형식과 순서가 모두 일치하며, 기능적으로도 완벽히 구현되었기 때문에 별도의 설명 없이 통과로 판단된다.

TEST#3: Address Space Isolation After Fork

Comparison

예시에서는 각 thread가 fork한 자식 process에서 "start" 및 "end" 메시지를 출력한다.
실제 결과에서도 동일한 메시지가 출력된다.

Conclusion

전체 구조와 흐름이 동일하며, 주소 공간 충돌 없이 fork 이후 자식 thread가 정상적으로 분리된 메모리에서 실행되었음을 확인할 수 있다.
부모 thread가 자신의 자식 thread를 실행시켜 병렬적으로 처리
모든 자식과 부모 thread가 정상 종료
결과: nested thread 생성 및 실행 정상 처리

TEST#4: sbrk and Memory Allocation Boundary Protection

Comparison

예시에서는 addr n at break = 0x... 형태의 메시지를 출력한다.
실제 결과에서는 여러 thread가 접근하면서 usertrap 및 scause 0xf 에러 메시지가 출력된다.

Analysis

예시는 user program이 직접 할당 주소를 출력한 반면, 실제 구현에서는 커널 수준에서 메모리 보호 기작이 동작하여 trap이 발생했다.
이는 thread가 할당하지 않은 page에 접근했을 때 보호가 발생했는지를 검증하기 위한 테스트이며, 예상된 동작이다.

Conclusion

오히려 trap이 발생함으로써 보호되지 않은 메모리 접근을 차단함을 증명하였고, 이는 test의 의도와 부합하므로 통과로 간주할 수 있다.
thread 0에서 sbrk()로 메모리 확장
각 thread는 공유된 주소 공간에 대한 접근 시도
여러 thread에서 접근 오류(scause 0xf) 발생 → 예상된 행동
결과: 주소 공간 공유와 memory boundary test 성공

TEST#5: Shared PID and Kill Behavior

Comparison

예시에서는 thread 2만 조기 종료된다.
실제 결과에서는 모든 thread가 동일한 pid로 시작하고, thread 0의 종료 메시지만 명시적으로 출력된다.

Analysis

모든 thread가 동일한 pid를 공유하는 점은 예상된 결과이며, thread 2의 종료 로그 누락은 scheduling timing 차이일 가능성이 높다.
join 이후 main이 종료되었으므로 나머지 thread들도 함께 종료된 것이다.

Conclusion

kill 관련 동작은 제대로 반영되었고, 모든 thread가 동일한 process의 일부로 정상 종료되었으므로 기능 구현에 문제는 없다.
모든 thread가 동일한 PID(29)로 출력됨
이는 thread가 독립적인 process가 아님을 증명
결과: 모든 thread는 동일한 process 내에서 실행됨

TEST#6: exec and Thread Termination Behavior

Comparison

예시에서는 exec 이후 "thread exec test 0" 메시지가 출력된다.
실제 결과에서는 일부 thread가 먼저 trap을 발생시키고 이후 동일한 메시지가 출력된다.

Analysis

exec이 호출되면 주소 공간이 새로운 program image로 대체되며, 기존의 모든 thread는 종료된다.
그에 따라 접근 불가능한 공간에 있던 thread들이 trap을 발생시킨 뒤, 새로 실행된 image가 정상적으로 실행된 것이다.

Conclusion

모든 trap은 exec에 따른 의도된 부작용이며, exec 이후 program이 정상 실행되었기 때문에 올바른 동작으로 판단된다.
thread 0이 exec()을 호출하여 새로운 프로그램으로 변환
다른 thread들은 예상대로 비정상 종료 (scause 0x2 / 0xd)
exec() 이후 새로운 프로그램이 정상적으로 실행됨을 확인
결과: exec 이후 전체 process context 교체 성공

Final Conclusion

총 6개의 테스트 모두 통과
xv6에 커널 수준의 thread를 안정적으로 도입 및 검증 완료
주요 기능(생성, 종료, 메모리 공유, PID 일치, exec 처리 등) 전반적으로 기대 동작 수행
수업에서 제공된 예시 출력과 실행 순서 또는 메시지가 일부 다르지만, 이는 xv6의 scheduler 특성상 자연스러운 차이이다.
모든 test의 핵심 기능은 정확히 구현되었으며, trap 발생 또한 메모리 보호 기법이 올바르게 작동했음을 의미한다.
따라서 "All tests passed" 라는 출력은 논리적으로 타당하고, 모든 요구 조건을 충족했다고 판단할 수 있다.

thread_create()가 여러 번 호출되며 clone()이 실패했음에도 불구하고 계속해서 pid가 증가
pid가 64를 초과하며 시스템이 비정상 상태에 진입
usertrap(): unexpected scause 또는 kerneltrap()이 다수 발생

Cause

thread_create()에서 sbrk(PGSIZE)로 stack을 요청했으나 실패한 경우, 그 stack 주소가 (void*)-1이 됨
이 상태로도 clone()이 호출되면, 커널 내 stack validation에서 실패하여 -1을 반환하지만, 사용자 코드는 이를 무시함
그 결과 join이 불가능한 zombie thread가 계속 생성되어 proc[]을 소진함

Solution

thread_create()에서 stack이 할당 실패했거나 page alignment가 맞지 않으면 즉시 실패 처리하도록 변경

void *s = sbrk(PGSIZE);
if (s == (void*)-1 || (uint64)s % PGSIZE) return -1;

clone() 내부에서도 stack이 NULL이거나 범위 밖인 경우 예외 처리 강화

if (!stack || (uint64)stack < PGSIZE || ... ) return -1;

2. Error on `fcn == 0` → Test Failure

Issue

clone() 내에서 if (!fcn) return -1; 조건을 설정한 후, 모든 thread 생성이 실패
thread_test에서 Thread 0 start조차 출력되지 않음

Cause

수업에서 제공한 test code에서 thread_basic() 함수의 주소가 실제로 0x0으로 설정되어 있음
이는 xv6의 linker 및 loader 설정 상 일부 함수가 .text 세그먼트의 시작 주소인 0x0에 배치되기 때문
xv6 riscv 환경에서는 epc = 0이 trap 없이 유효하게 실행되어야 하며, 0x0 주소는 정상적인 실행 진입점임

Solution

clone() 내 fcn null-check 조건을 완전히 제거
대신 walkaddr()를 통해 해당 address가 유저 영역에 존재하는 유효한 physical page를 가리키는지만 확인

if ((uint64)fcn >= MAXVA || !walkaddr(p->pagetable, (uint64)fcn)) return -1;

3. join Unable to Collect Thread (Infinite Wait)

Issue

join()을 호출했으나 Thread X join failed가 출력되며 테스트 실패
thread는 종료되었으나 커널이 해당 상태를 인지하지 못함

Cause

thread 종료 시 state == ZOMBIE가 되었지만, join()에서 접근 시 np->lock을 획득하지 않거나, 이미 freeproc() 이후 lock을 해제한 뒤 상태를 확인하려 해 race condition이 발생
또는 p->lock과 wait_lock을 동시에 사용하면서 deadlock이 발생할 수 있음

Solution

join() 내에서 반드시 np->lock을 획득한 뒤 state를 확인
freeproc()도 반드시 np->lock을 보유한 상태에서 호출하고, 해제는 이후에 수행
sleep은 반드시 p->lock 없이 wait_lock만 보유한 상태에서만 호출해야 함

4. Other Threads usertrap on `exec()` → panic

Issue

exec() 테스트(TEST#6) 수행 시, 다른 thread들에서 다음과 같은 log 출력

usertrap(): unexpected scause 0x2 pid=36 sepc=0x1000 stval=0xdeadbeef

이후 커널 panic 또는 stack overflow 발생

Cause

exec()은 호출 thread의 pagetable을 완전히 새로운 것으로 교체하는 작업이다.
그러나 같은 pagetable을 공유하는 다른 thread들이 아직 살아 있고, 해당 주소를 기준으로 명령어를 fetch하려고 하면 invalid memory trap이 발생
특히, 이미 소멸된 함수 주소(fcn)로 점프하는 도중 문제가 발생

Solution

exec() 호출 시 현재 thread를 제외한 동일 pagetable의 thread를 freeproc()으로 제거

for(struct proc *q = proc; q < &proc[NPROC]; q++) {
  if(q != p && q->pagetable == p->pagetable) {
    acquire(&q->lock);
    freeproc(q);
    release(&q->lock);
  }
}

결과적으로, exec()는 해당 process를 thread 단위가 아닌 "주소 공간 단위"로 완전히 재시작하는 함수로 보아야 한다.

5. Only Some Threads Terminated on `kill(pid)` → zombie leak

Issue

kill(main_pid) 호출 시 일부 thread는 여전히 돌고 있으며, join()도 반환하지 않음
TEST#5에서 thread 중 하나만 종료하고 나머지는 무한 루프에 빠짐

Cause

기존 kill() 구현은 pid와 일치하는 단일 process만 종료 처리함
그러나 thread 구조에서는 하나의 주소 공간에 여러 thread가 존재하며, 개별 pid만 종료해선 효과가 없음

Solution

kill() 구현을 확장하여 동일한 pagetable을 공유하는 모든 proc에 대해 killed = 1 설정
SLEEPING 상태일 경우, 강제로 RUNNABLE로 만들어 sched()에 진입할 수 있도록 함

for (p = proc; p < &proc[NPROC]; p++) {
  if (p->pagetable == target->pagetable) {
    p->killed = 1;
    if (p->state == SLEEPING)
      p->state = RUNNABLE;
  }
}

6. Stack Memory Leak after `thread_join()`

Issue

thread 수거 이후에도 sbrk()된 메모리가 회수되지 않아, sbrk(0) 값이 계속 증가
long-running process에서 memory exhaustion 발생

Cause

join()이 stack 주소를 유저에게 넘겨줬지만, 사용자가 이를 반납하지 않음
thread_join()은 join()을 호출만 하고 메모리 회수는 하지 않음

Solution

사용자 라이브러리 수준에서 thread_join() 내부에서 직접 sbrk(-PGSIZE) 호출
stack 주소가 0이 아닌 경우에만 해제

if (pid > 0 && s) sbrk(-PGSIZE);

7. sleep/wakeup Deadlock

Issues

join()에서 sleep(p, &wait_lock) 이후 깨어나지 않거나, wakeup 이후에도 상태가 복구되지 않음
Debugging 시 sched() 진입 후 다시 돌아오지 않거나 panic: unlock 발생

Cause

sleep()은 내부적으로 p->lock을 요구하며, 외부에서 이미 p->lock을 획득한 상태로 들어오면 중복 lock으로 crash
또는 wakeup()과 sleep() 사이의 window에서 race condition이 발생할 수 있음

Solution

sleep() 호출 전 반드시 p->lock이 획득되어 있지 않도록 설계
sleep() 내부에서 p->lock을 획득하며, 외부에서는 wait_lock만 보유해야 함

acquire(&p->lock);
release(&wait_lock);
...
sched();
...
release(&p->lock);
acquire(&wait_lock);

wakeup()은 lock 없이 작동해야 하므로 별도로 p->lock을 각 thread마다 획득하고 상태를 바꿔줌

Summary: Major Issues List

Issue Code Area	Cause	Solution Summary
`thread_create`	`sbrk` 실패 또는 misalignment	실패 시 바로 `return`
`clone`	`fcn == 0` 주소 거부	`fcn` null-check 제거, `walkaddr`만으로 유효성 확인
`join`	lock 보호 미흡	lock 순서 및 `freeproc()` 내부 동기화 보강
`exec`	다른 thread가 trap 발생	동일 pagetable 공유 thread 전부 제거
`kill`	일부 thread만 종료됨	pagetable 기준 전체 `killed` 처리
`thread_join`	stack 회수 누락	내부에서 `sbrk(-PGSIZE)` 호출 추가
`sleep/wakeup`	deadlock 또는 race condition	lock 순서 및 `wakeup` 시점 조정

이와 같은 반복적 debugging과 코드 개선을 통해, xv6에 안정적이고 정확한 kernel 수준 thread 시스템을 구현할 수 있었다.

Additional Content

Reference Notes for Thread Implementation in xv6 RISC-V

본 project는 xv6 RISC-V 버전을 기반으로 하며, x86 기반 구현 예제들과는 구조적으로 다르다.
- 특히 ptable[]이 존재하지 않고, proc[NPROC] 배열과 spinlock으로만 동기화를 수행한다.
- 따라서 x86의 switchuvm(), loaduvm() 등의 동작 방식과 달리, RISC-V에서는 walk() 및 pagetable_t에 직접 접근하는 방식이 필요했다.
xv6의 trapframe, context, scheduler 등은 thread-safe하지 않으므로, thread마다 반드시 독립된 trapframe, context, ustack을 사용해야 한다.
uvmshare()는 기존 uvmcopy()를 변형하여 구현한 함수로, PTE_U 비트가 설정된 사용자 영역 page에 대해서만 공유(reference mapping)하도록 설계하였다.
- 이는 read-only 세그먼트에 대해서도 문제가 없으며, exec이나 fork와는 다른 동작을 보장한다.
thread_fcn.c, thread_test.c는 과제 명세에서 제공한 채점 기준 파일이다.
- 이 파일의 구조나 fcn = 0x0 형태의 호출 방식은 정상 동작이며, panic 유발 요소가 아니다.
모든 thread 구현은 xv6의 기존 기능과 완전히 호환되어야 하며, 특히 다음과 같은 system call들과 연동 가능해야 한다.
- fork(), exec(), exit(), wait(), kill(), sleep(), pipe()

Additional Useful References

https://github.com/mit-pdos/xv6-riscv
https://pdos.csail.mit.edu/6.828/2022/xv6/book-riscv-rev3.pdf

실습 중 참고한 StackOverflow thread:

https://stackoverflow.com/questions/78141535/threading-using-jmp-buf-array-in-c-test-in-xv6 (x86 중심이므로 구조는 참조용)

이상으로 본 project의 기술적 배경과 연관된 모든 핵심 요소들을 포함하였다.