손가든 개발일지

핀토스 2주차 과제를 끝마치며 '유저 프로세스 관리' 해주는 운영체제까지 구현할 수 있었다. 유저 프로세스는 디스크에 있는 프로그램을 읽어 가상 메모리를 만들어야 하고, 권한이 없는 자원에 대한 요청(시스템콜)을 받아내어 요청을 처리해주는 작업(시스템 콜 핸들러)을 수행하도록 코드를 구현했다. 오늘은 유저 프로그램 관리 코드를 작성하면서 알 수 없었던 의문의 오류들이 발생시키는 이유에 대해 고민해보고 이를 해결했던 트러블 슈팅 사례들에 대해 다뤄보겠다. 문제 1 : 'process_exec' 함수 -> 'parsing' 중에 timer_interrupt가 터지면 발생하는 ERROR 문제 상황은 다음과 같았다. test 중 'multi-recurse'를 테스트하는 중에 간헐적으로 timer_interrup..

금주에 오랜만에 퀴즈를 응시했다. 이번주는 운영체제와 관련된 문제들이 출제됬다. 1. 커널 모드에서 실행될 수 있는 작업의 예 / 커널에서 실행하는 작업들이 사용자 모드에서 실행되어선 안되는 이유 커널 모드에서는 파일 시스템, 메모리, I/O 자원 요청 관리를 수행한다. 이에 대한 접근은 사용자 모드에서 실행되어서는 안된다. 운영체제는 운영체제의 중요한 업무의 세가지인 '하드웨어를 추상화하여 디자인' / '각 프로세스가 독립적인 컴퓨터로 수행되기 위한 보호와 분리' / '컴퓨터 자원의 공유' 를 수행한다. 만약 사용자 모드에서 공유 자원을 직접 관리하게 되면 독립적인 컴퓨터로 수행되기 위한 보호와 분리가 통제되지 못한다. 따라서 사용자 모드는 system call() 함수로 커널에 공유 자원의 데이터를 ..

이번주부터는 pintos 운영체제 안에서 유저 프로그램을 실행시킬 수 있도록 해야 한다. pintos는 1개의 프로세스에 1개의 스레드만 존재하는 단일 스레드 프로세서이기 때문에 유저 프로세스를 실행했을 때는 기본적으로 1개의 스레드가 프로세스의 job을 수행한다고 추상화하는 것으로 그림을 그려 나갈 예정이다. 하지만 부모 프로세스가 자식 프로세스를 실행시킨 뒤 wait하는 방식으로, 하나의 프로세스로부터 파생된 프로세스는 각각 1개의 스레드를 가진다는 것을 짚고 넘어가야 할 것 같다. 유저 프로그램 실행 일단 가장 먼저 사용자가 '디스크에 존재하는 프로그램의 이름'을 터미널에 호출하며 유저 프로그램을 실행시킬 때 어떤 일이 발생하는지 확인해보자. 그 전에 우리는 사용자가 찾을 데이터가 존재할 가상의 ..

pintos 2주차로, 유저 프로그램을 실행시키는 과제를 수행하면서 인터럽트 프레임이라는 처음 듣는 키워드가 나왔다. 인터럽트 프레임이 유저 스레드를 동작시키는 시스템 안에서 매우 중요한 요소인 것 같다. 이번 포스팅을 통해 인터럽트 프레임이 무엇인지, 인터럽트 프레임을 통해서 프로세스를 실행할 때 어떤 작업들을 수행하는지 알아보자. Interrupt Frame 이란 ? 인터럽트 프레임은 실행 중이던 프로세서에서 인터럽트 서비스 루틴이 실행되면, 현재 상태를 사후 복구하기 위해 실행 중이던 상태를 저장하는 데이터 구조(struct)이다. 이는 현재 수행중인 프로세스가 작업을 중단하고 인터럽트에 응답해서 특정한 코드가 실행될 때 사용된다. 인터럽트 프레임은 프로세스의 커널 스택에 위치하는데, 이 때 커널 ..

지난주 일요일 pintos 공부를 하고 있는 극악의 지옥주로 바쁜 와중에도 알고리즘 스터디에 참여해준 전사들이 있다. 그 전사들과 DP 문제 하나로 서로 다른 접근법에 대해 토의하며 하루를 마쳤는데 아직 나는 DP 문제를 보면, 어떻게 접근 해야될지 몰라 손쓸 새도 없이 포기할 수 밖에 없었다. 그래서 의미 있게 pintos 2주차를 시작하기 전에 DP 알고리즘적 접근법에 대해 포스팅하며 머리를 환기하고자 한다. BaekJun - #1309 : 동물원 (Dynamic Programming) https://www.acmicpc.net/problem/1309 1309번: 동물원 첫째 줄에 우리의 크기 N(1≤N≤100,000)이 주어진다. www.acmicpc.net 이 문제는 DP 알고리즘을 통해 문제를 ..

MLFQS를 구현을 모두 완료했다. MLFQS를 구현하면서 발생했던 Trouble Shooting에 대해서 얘기해 보자. 상황 1 : mlfqs-load-1 테스트에서 'kernel panic' 발생 밑에서부터 위로 시간 순으로 call stack 출력하는 상황에서 'pass()' 를 통해 패스하는 도중에 debug_panic이 발생했다. 이 상황에서는 디버깅도 의미가 없었다. 고민 중에 핀토스 깃북에 FAQ에 나와 똑같은 테스트의 상황에 대처하는 글을 확인했다. 글을 읽어보면 다음과 같다. pass()로 테스트를 통과하는 도중 kernel_panic이 발생한 것만 같지만, 사실은 fail을 출력한 것이고, call stack 주소를 불러오는데 오류가 발생하여 fail 다음 함수인 pass의 주소를 가져..

이번 포스팅은 donate 메커니즘을 pintos 운영체계의 lock에 코드로 적용한 방식을 리뷰해보겠다. Lock 의 우선순위 donate 적용 과정 1. thread 구조체에 새롭게 무엇이 저장되어야 하는가? 2. 우선순위를 언제, 누가 donate 해야 하고, 어떻게 내 우선순위로 돌아올 수 있는가? 3. lock wait 때문에 어떤 상황이 발생할 수 있고, 그 대처를 어떻게 해주어야 하는가? 4. 이 외의 상황 인지 - 한개의 락을 여러 스레드가 기다리고 있을 수 있다. - 여러개의 락을 한 스레드가 소유할 수 있다. - 한 스레드는 단 하나의 락만 기다릴 수 있다. - 락을 소유한 스레드가 다른 락을 기다릴 수 있다. 1. thread 구조체에 새롭게 무엇이 저장되어야 하는가? thread.h..

이번 포스팅에서는 예전 포스팅에서 공부했던 Synchronization(동기화) 를 스케줄링에 맞게 코드를 수정하고 다음 포스팅에는 priority-donate라는 동기화 중 특정 상황의 솔루션을 적용해보겠다. pintos에 있는 synchronization pintos에는 synchronization을 지키기 위해 semaphore와 lock, cond(monitor)가 존재한다. 해당 로직들은 모두 구조체로 구조체의 구조를 타고 가 보면 최 하단에는 결국 semaphore 방식으로 임계영역의 동기화를 보장하도록 설계되어있다. semaphore 구조체 안에서는 해당 임계구역에 진입하려고 시도했지만 block된 쓰레드를 모아두는 리스트를 가지고 있다. synchronization을 위한 구조체들의 구조는..

오늘까지 donate priority 구현을 마쳤다. 스케줄링에 대해 이해하는 것은 어렵지 않지만 실제로 운영체제에 어떤 요소들을 삽입하여 구현하는 것이 쉽지 않았다. 확실히 핀토스가 실제 운영체제보다 엄청 작은 코드량을 가지지만, 그래도 몇만줄 되는 방대한 양의 코드가 동작하는 방식을 이해하고 생각한 뒤 원하는 방식으로 동작하도록 코드를 짠다는 것이 굉장이 어려운 부분인 것 같다. 아무튼 포스팅 순서는 우리가 원하는 동작이 무엇인지 생각한 뒤 실제로 그것을 어떻게 구현했는지 확인해보겠다. 시작 전에.. 지금까지는 FIFO 로 4틱마다 context_switching이 진행되고 있었다. 하지만 지금부터 priority를 도입하면 다음과 같은 상황으로 전환된다. 1. 4ticks 후 yield interr..

pintos 운영체계에 대해 학습하며 얻는 과제들이 어려운 점은 무엇이 잘못되고 있는지 파악하는 것부터 시작이기 때문인 것 같다. 밥 먹으며 동료들과 얘기를 나누면서 든 생각은 핀토스에서는 문제의 질문부터 찾아내는 것이 시작인 것 같다. 그래서 그 첫번째 문제점인 쓰레드가 sleep할 때, CPU를 점유하면서 쉬고 있는 상황을 개선해 보았다. 문제 인식 현재 쓰레드가 timer_sleep 될 경우 해당 쓰레드가 격리되는 방식에 대해 살펴보기 위해 초기 timer_sleep() 함수를 살펴보자. /* Suspends execution for approximately TICKS timer ticks. */ void timer_sleep (int64_t ticks) { int64_t start = timer_..