손가든 개발일지

2주차를 마치며 3주차에 들어가기 전에 바쁘게 달려오느라 작성하지 못했던 TIL을 작성해보려 한다. pintos 운영체제 유저 프로세스 관리에 대해 구현하면서 가장 큰 의미는 프로세스의 생명 주기 동안 어떤일이 벌어지는지 머리속에 그림으로 정리할 수 있게 되었다는 것이다. 비록 실제로 운영되는 리눅스, 윈도우, MACOS 에서 하나의 상황(예를 들면 wait)을 서로 다른 방식으로 대처 하고 있다 하더라도 그 상황을 왜, 어떻게 처리 해주어야 하는지 이해할 수 있는 기간이었다. 오늘은 이러한 생각들을 최대한 기억에 오래 남기기 위해 코드와 함께 알게된 것들을 기록해 보겠다. system call 시스템 콜에 대해 먼저 이야기 해보자. 유저 프로그램이 시스템 콜을 호출하면, 커널 영역의 system cal..

핀토스 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..