pintOS | Project1: Threads 구현

 

 

핀토스... 정글에서 공부하는 프로젝트 중 끝판왕이라고 불리는 만큼 정말 험난하다. 1기 분들도 핀토스 얘기만 나오면 한숨이 먼저 나왔던 기억이...

 

여하튼 pintOS는 threads, user porgrams, virtual memory, file system 등 운영체제의 개념들을 직접 구현하면서 더 깊게 이해하는데 도움을 주는 교육용 운영체제다.

 

pintos에 대한 자세한 설명은 ↓

Introduction · GitBook

 

 

1. 이번 주 목표

이번 주차의 목표는 운영체제 중 Thread를 직접 구현해보면서 스레드에 대한 이해도를 높이는 것이다. 

 

스레드(Thread) 정리 참조 ↓

운영체제(Operating System) | 스레드(Thread)

 

pintos에서 구현해야 하는 기능들은 alarm clock, priority shceduling, advanced scheduling(mlfqs)이다. 이 중에서 alarm clock과 priority scheduling에서 semaphore, lock 부분 구현은 필수였고, priority schduling에서 condition variable과 advanced scheduling은 옵션이었다.

 

우리 조의 목표는 일단 advanced scheduling 전까지는 무조건 다 구현하고, 시간이 되면 이 부분도 도전하는 것이었다.

 

 

2. 공부한 개념 정리

| Alarm clock

Alarm은 호출한 프로세스를 정해진 시간 후에 다시 시작하는 커널의 내부 함수이다. 

 

실행 중인 프로세스에 I/O자원 요청 등 외부 인터럽트가 발생했을 때, 프로세스는 block상태가 되어야 한다. 그 후 자원을 할당 받았을 때 다시 ready상태로 넘어가야 한다. 그러나 기존 pintos에서는 block단계로 가는 부분이 구현되어 있지 않았고, 이를 구현하는 것이 프로젝트1의 가장 첫 미션이었다.  

 

| Priority

현재 ready상태에 들어 있는 FIFO(First-In, First-Out)방식으로 구현되어 있다. 즉 ready queue에 먼저 들어간 스레드가 먼저 나오는, 선착순 방식이다.

 

ready queue에 먼저 들어간 프로세스가 먼저 실행

 

하지만 이렇게 되면 문제가 발생할 수 있다. 위의 그림을 예로 들자면, P1프로세스가 실행하는데 10초가 걸리고, P2프로세스가 실행하는데 3초, P3이 2초, P4가 1초가 걸린다고 가정해보자. P2, P3, P4는 잠깐 실행하고 나오면 되는데, P1이 10초나 실행하게 되면서 긴 대기 시간을 가지게 된다. 이를 Busy waiting 이라고 하고, 우리는 각각의 프로세스에 priority를 넣어(스레드에 우선순위를 부여하여) ready list에 스레드가 들어가는 순서를 변경할 수 있다.

 

| Semaphore / Lock / Condition Variable

여러 프로세스가 같은 공유자원(shared data)을 사용하려고 할 때, 문제가 발생할 수 있다. 

 

위의 그림처럼 같은 자원을 가지고 같은 작업을 수행하는데 인터럽트가 발생하면서 수행 순서가 달라질 때, 결과가 바뀔 수 있다. 이러한 문제는 세마포, 락, 모니터 등의 방법으로 해결할 수 있다. 자세한 개념은 추후 운영체제 동기화 부분을 정리할 때 다시 작성하도록 하겠다..

 

| MLFQS(Multi level Feedback Queue Schedule)

위와 동일. 스케줄링 정리할 때 더 자세하게 정리하기!

 

 

3. 구현 및 성과 달성 결과

코드 결과 : https://github.com/dapsu/pintos-kaist

 

훌륭한 조원들 덕분에 All pass 할 수 있었음....!!!

 

 

4. 팀워크 리와인드

우리 조 같은 경우 프로젝트 시작 후 3일 동안은 각자 개념 공부에 몰입했다. 서로에게 적합한 공부 방법이 있기 때문에 따로 공부했었고, 모르는 부분들은 물어보며 해결했다. 그리고 서로 공부한 개념들을 설명하고 공유하면서 이해도를 탄탄하게 만들었다.

 

프로젝트 진행 역시 마찬가지였다. 매일 범위를 정하여 구현해오고, 다음날 아침 10시에  한 테이블에 모여서 내가 구현한 것을 설명해주고 회의를 하면서 팀의 코드를 완성시켜나갔다.

 

이 과정에서 각각의 브랜치들을 마스터 브랜치에 merge할 때, 같은 코드가 위치가 달라서 merge conflict가 발생하지 않는 경우들이 생겼었다. 그래서 새로 추가하는 변수나 함수들은 그 파일의 가장 하단에 적기로 규칙을 만들었다. 앞으로 남은 한 주 동안에도 더 탄탄하게 만들어갈 수 있을 것 같다.

 

그리고 나는 advanced 부분은 하지 않으려고 했다. 어렵기도 했고(어렵다고 들었고) 운영체제 기본 개념들을 더 깊게 이해하는 것이 중요하다고 생각했기 때문이다. 하지만 조원들은 주어진 과제는 다 끝내보자고 설득했고, 결국 마지막 옵션 과제에 도전하게 되었다. 막상 직접 공부해보니 못 할 정도는 아니었다. 조원들 덕분에 더 많은 것을 배울 수 있었다. 굳굳