[TIL] [WEEK9-10] Pintos Project(2) System Call(2)

📍프로세스 관련 시스템 콜 구현

구현 목록: halt, exit, exec, wait, fork

1. halt()

/* power_off() 호출해 Pintos 종료 */
void halt(void)
{
	power_off();
}

2. exit()

/* 현재 실행 중인 유저 프로그램 종료하는 시스템 콜 */
void exit(int status)
{
    /* 실행 중인 스레드 가져오기 */
    struct thread *t = thread_current();
	/* 해당 스레드의 종료 상태 저장 */
    t->exit_status = status;
    /* 종료 메세지 출력 후 스레드 종료 */
	printf("%s: exit(%d)\n", t->name, status);
	thread_exit();
}

3. exec()

/* 현재 프로세스가 cmd_line에서 이름이 주어지는 실행 가능한 프로세스로 변경 */
/* 이 때, 주어진 인자 전달 -> 성공 시 반환 x, 실패 시 exit state -1 반환 및 프로세스 종료 */
/* 이 함수는 호출한 스레드의 이름은 바꾸지 않음 & file descriptor는 호출 시 열린 상태로 있다 */
int exec(const char *file)
{
	check_address(file);
    
	/* 수정 가능하도록 copy하기 위한 메모리 공간 */
	char *file_name = palloc_get_page(PAL_ZERO); 

	if (file_name == NULL)
	{
		exit(-1);
	}

	/* file을 file_name으로 복사 */
	strlcpy(file_name, file, PGSIZE); 

	/* process_exec 함수 호출로 파일 실행 */
	if (process_exec(file_name) == -1) 
	{
		exit(-1);
	}
}

위 세 개 시스템 콜은 본래 상태로도 구현할 수 있지만, wait()과 fork() 시스템 콜을 구현하기 위해선 프로세스 계층 구조를 먼저 구현해야 한다.

🛠️ 프로세스 계층 구조

프로세스는 실행 도중 시스템 호출을 통해 다른 프로세스를 생성할 수 있다.

• 부모 프로세스: 새 프로세스를 생성한 프로세스
• 자식 프로세스: 부모 프로세스에 의해 생성된 프로세스

물론 자식 프로세스는 또 다른 프로세스를 생성할 수 있다. 이렇게 생성된 이들이 또 다른 애들을 낳는 형식으로 여러 프로세스가 동시 실행된다. (약간 트리 구조)

현재 PintOS에는 부모/자식 프로세스를 명시해주는 정보가 없기 때문에 부모/자식의 구분이 없고,
부모가 자식 프로세스의 정보를 알지 못 해 자식 프로세스가 시작/종료되기 전에 부모 프로세스가 종료되어버리는 현상이 발생한다. 즉, 이는 프로그램이 실행되지 않는다는 의미다.

이를 고치기 위해 우리는 프로세스 계층 구조를 도입하고, 세마포어를 활용해 자식 프로세스가 종료될 때 부모 프로세스에게 시그널을 주고 종료하게 될 수 있도록 수정해야 한다. (부모가 자식을 기다리고 종료될 수 있도록)

👉🏻 프로세스 디스크립터에 부모/자식 필드를 추가하고, 이를 관리하는 함수 구현하기

• 부모 프로세스 정보 저장하는 멤버 변수 추가
• 자식 프로세스 리스트 멤버 변수 추가

/* Project(2) */
struct intr_frame parent_if; /* 부모 프로세스의 인터럽트 프레임 */
struct list child_list;		 /* 자식 리스트 */
struct list_elem child_elem;
struct file *running_f; /* 실행 중인 파일 */

int exit_status; /* 종료 상태 */

struct semaphore exit_sema; /* 자식 프로세스 exit 대기 세마포어 */
struct semaphore wait_sema; /* 자식 프로세스 종료 대기 세마포어 */
struct semaphore fork_sema; /* 자식의 load 완료 대기 세마포어 */

• 각종 멤버 변수 추가/초기화

/* thread.c/init_thread() */
list_init(&t->child_list);
t->exit_status = 0;

/* thread.c/thread_create() */
sema_init(&t->exit_sema, 0);
sema_init(&t->load_sema, 0);
sema_init(&t->wait_sema, 0);
sema_init(&t->fork_sema, 0);

list_push_back(&thread_current()->child_list, &t->child_elem);

• 자식 프로세스 검색 함수 구현

/* Project(2) Process hierarchy */
struct thread *get_child_process(int pid)
{
	/* 자식 리스트에 접근하여 프로세스 디스크립터 검색 */
	/* 해당 pid가 존재하면 프로세스 디스크립터 반환 */
	/* 리스트에 존재하지 않으면 NULL 리턴 */
	struct thread *t = thread_current();
	struct list_elem *e = list_begin(&t->child_list);

	for (e; e != list_end(&t->child_list); e = list_next(e))
	{
		struct thread *t = list_entry(e, struct thread, child_elem);
		if (t->tid == pid)
			return t;
	}
	return NULL;
}

이제 wait()과 fork() 시스템 콜을 구현해보자.

4. wait()

int wait(pid_t pid)
{
	return process_wait(pid);
}

시스템 콜 자체는 별 게 없다. process_wait()만을 호출한다. 그럼 process_wait()을 타고 들어가보자.

위에서 말했던 것처럼 부모 프로세스는 자식 프로세스가 종료되길 기다려야 한다. 이를 생각하고 process_wait()을 올바르게 작성한다.

/* 자식 프로세스가 종료될 때까지 기다리고, 종료 상태 반환 */
int process_wait(tid_t child_tid UNUSED)
{
	/* 자식 프로세스 받아오기 */
	struct thread *child = get_child_process(child_tid);

	if (child == NULL)
	{
		return -1;
	}

	/* 자식 프로세스가 종료될 때까지 대기 = 해당 프로세스가 종료될 때 sema_up */
	sema_down(&child->wait_sema);
	/* 자식 프로세스가 종료되었으면 자식 리스트에서 해당 자식 삭제 */
	list_remove(&child->child_elem);
	/* 자식의 대기 상태 이탈 */
	sema_up(&child->exit_sema);

	return child->exit_status;
}

그런데 wait() 구현을 위해 생각하다 보면, process_exit()과 연관이 있을 거라는 걸 알 수 있다.
그럼 process_exit()에도 관련 내용을 작성해주자.

void process_exit(void)
{
	struct thread *curr = thread_current();

	/* 해당 프로세스의 fdt의 모든 값을 0으로 만들어줌, 즉 모든 열린 파일 닫기 */
	for (int i = 0; i < FDTCOUNT_LIMIT; i++)
	{
		close(i);
	}

	/* fd table 메모리 해제 */
	palloc_free_multiple(curr->fdt, FDT_PAGES);

	/* 실행 중인 파일 닫기 */
	file_close(curr->running_f);
	process_cleanup();

	/* 자식 종료를 대기하는 부모 프로세스를 대기 상태에서 이탈되도록 */
	sema_up(&curr->wait_sema);
	/* 부모 프로세스가 자식을 리스트에서 지울 수 있도록 대기 */
	sema_down(&curr->exit_sema);
}

sema가 많이 헷갈렸는데, 뇌피셜이긴 하지만 정리를 하자면

• process_wait
  부모가 자식이 종료되길 기다리기 위해 sema_down(wait_sema)로 잠에 듬
• process_exit
  자식의 수행이 끝나면 process_exit에서 부모에게 sema_up(wait_sema)로 종료를 알려 부모의 대기 상태를 풀고, 부모가 나를 지울 수 있도록 sema_down(exit_sema)로 기다림
• process_wait
  부모는 자식이 종료되었으니 대기에서 풀려, 해당 자식을 자식 리스트에서 지우고, 지우길 기다리는 자식에게 sema_up(exit_sema)로 대기 상태를 풀어줌

이렇게 하면 wait() 구현도 끝이 난다.
마지막 fork()를 구현해보자.

5. fork()

/* 현재 프로세스의 복제본인 새 프로세스 생성 */
pid_t fork(const char *thread_name, struct intr_frame *f)
{
	check_address(thread_name);
	return process_fork(thread_name, f);
}

fork도 시스템 콜 자체는 별 게 없다.
인자가 포인터이기 때문에 유효성 검사를 한 후 process_fork()을 호출한다.
/ 현재 프로세스를 복제해 새 프로세스를 생성 /

tid_t process_fork(const char *name, struct intr_frame *if_ UNUSED)
{
	struct thread *t = thread_current();
	memcpy(&t->parent_if, if_, sizeof(struct intr_frame));

	/* 인자로 받은 name으로 된 새 스레드 생성 */
	tid_t pid = thread_create(name, PRI_DEFAULT, __do_fork, t);

	if (pid == TID_ERROR)
	{
		return TID_ERROR;
	}

	/* 부모 프로세스의 자식 리스트에서 방금 새로 생성된 자식 프로세스 가져오기 */
	struct thread *child = get_child_process(pid);
	/* 자식 프로세스의 __do_fork를 대기 */
	/* __do_fork에서 복제가 완료되면 sema_up을 해줌으로써 대기 이탈되며 종료 */
	sema_down(&child->fork_sema);

	return pid;
}

맨 처음에 굳이 실행 중인 부모 프로세스의 contexts를 복사하는 이유는 if 정보를 직접 넘길 시, 부모 프로세스가 계속 실행하며 값이 변할 수 있기 때문이다.
때문에 부모 프로세스의 parent_if에 if값을 복사한 후, 부모 프로세스를 __do_fork의 인자로 담아준다.

이렇게 모든 시스템 콜의 구현이 끝났다. 나는 총 95개의 Test-case 중 94개를 pass 했는데, 마지막까지 multi-oom을 통과하지 못 했다. 해당 케이스는 메모리 누수를 검사한다고 하는 것 같은데.. 도저히 어느 부분인 지 모르겠다. 코드를 작성하는 중간중간 메모리 관리를 잘 해야겠다.

마지막으로 테스트 케이스들 그냥 안 되면 어떻게든 통과하게 만들기 위해 막고라로 쳐내느랴... 사실 기억이 잘 안 나지만, 기억나는 트러블 슈팅 몇 개 작성하고 마무리하겠다.

[트러블 슈팅]

• fork가 안 됐던 문제
  : duplicate_pte에서 첫 번째 조건문 parent_page가 kernel_page인 경우 즉시 반환하라고 되어 있어서 false인 줄 알았는데, true로 해줘야 했음
• rox 관련 TC들이 통과되지 않았던 문제
  : process_exit에서 running file을 file_close 해야 함 & load의 done에서 file_close(file)를 지워야 함
  -> 즉, load에서 실행하고 done에서 파일 닫아버리고 있었었음
• 몇 개 테스트가 통과되지 않았던 건
  : wait_sema를 적용하지 않았어서
• 마지막으로 메모리 해제와 lock&sema 관리 잘 하기 중요 -> multi-oom test-case가 메모리 누수 관리 요구

이건 트러블 슈팅은 아닌데, 디버깅을 정말 잘 활용해야겠다고 다시 한 번 느꼈다.
나도 모르게 자꾸 디버깅을 활용하지 않게 되는 것 같다.
printf()든 뭐든 디버깅을 하다보면 시스템이 어떻게 흘러가는지 파악할 수 있다.
오류가 났을 때나 TC가 fail이 떴을 때 뿐만 아니더라도 함수 흐름이 어떻게 되는 지 알고 싶을 때에도 큰 작용을 한다.