programmer life guidance 101

19. Kernel Preemption 19.1 Mutual Exclusion — 상호 배제 컴퓨터 시스템을 얘기할 때 가장 중요한 파트 중 하나가 상호 배제 문제이다. 시스템이 정상적으로 작동하기 위해서는 이 상호 배제 개념은 반드시 필요하다. 설명을 진행하기 전, 먼저 X++이라는 연산이 정확하게 어떻게 이루어져 있는지부터 이해하고 가자. 우리가 보통 프로그래밍 언어를 사용할 때 X++과 같은 단항연산자를 사용하면, 하나의 명령만으로 덧셈이 정상적으로 이루어지는 것 같지만 실제로 동작하는 기계 입장에서 이 단항연산 과정은 3단계로 나누어진다. 그 과정은 아래와 같다. X를 저장소로부터 읽어서 CPU 레지스터로 읽어들인다. CPU 안에서 ALU 연산을 진행한다. CPU 로부터 나온 결과를 다시 저장소에..

18. Kernel Scheduling (커널 스케쥴링) 리눅스에서는 어떤 프로세스가 다음에 실행될 프로세스일까? 물론 priority(우선순위)가 가장 큰 프로세스가 실행될 것이다. 하지만 time slice를 가지고 있는지도 반드시 확인해야 한다. 타임 슬라이스(time slice)에 대한 설명은 아래 그림을 보면서 살펴보도록 한다. 먼저 위쪽 네모박스 안의 내용을 살펴보자. CPU가 어떤 프로세스에게 할당될 때는 일종의 시간제한이 있게 된다. 위 예시에서는 100ms라고 되어 있다. 하지만 안타깝게도 이마저도 못쓰게 되는 경우가 발생할 수 있다. 현재 프로세스보다도 더 급한 작업이 요구되었을 때, CPU를 또다시 빼앗길 수 있다. 위 네모박스 안에서는 20ms를 사용하다가 CPU를 뺏겨버렸고 남은 ..

17. Process State 프로세스의 상태에는 ready, running, waiting이 존재한다. running은 프로세스 입장에서는 최상의 상태이며, running 중 Disk I/O를 요구하는 사건이 발생하면 CPU가 해당 프로세스의 상태를 waiting으로 바꾼다. waiting의 경우 시그널의 상황에 따라 2가지의 반응이 있을 수 있는데 이 부분은 중요한 내용은 아니므로 넘어가도록 한다. I/O가 끝나고 상태는 wait에서 ready로 넘어가게 된다(CPU는 항상 바쁘다). I/O가 끝나고 ready list에 참여해서 기다리다 보면 자신의 차례가 올 것이다. 차례가 오는 것을 Scheduler dispatches라고 표현한다. dispatch과정을 상세하게 풀어보자면, **context..

16. Kernel Thread(커널 스레드) 이번 5번째 강의에서는 프로세스간 CPU 점유권의 이동이 어떤 매커니즘으로 이루어지는지를 다루게 된다. CPU를 할당해준다는 것은 단순히 프로세스의 우선순위 말고도 고려해야할 것들이 많다. 리눅스 운영체제는 과연 이러한 숙제를 어떻게 풀고 있는지 지금부터 살펴보려 한다. 먼저 강의노트 4에서 다뤘던 내용들을 잠시 떠올려보자. 스레드(Thread)가 있고 프로세스(Process)가 있었다. 프로세스는 부모의 것(Task basic info + files, fs, tty, mm, signals)을 전부 그대로 복사한 것(heavy-weight creation)이고,반대로 최소한으로 복사(light-weight creation)한 것이 스레드이다. 또한 커널은 메..

15. Process Copy 지금까지는 프로세스가 생성 되는 과정에 대해서 알아보았다. 부모 프로세스가 자식 프로세스를 생성 할 때 두가지 오버 헤드가 생긴다는 것을 배웠다. 첫번째는 PCB를 복사할 때 생기고 두번째는 image를 복사 할 때 생긴다. PCB는 하얀색 도화지의 속성(크기, 질감, 모양)이라면 image는 그 도화지 위에 색칠된 그림이라고 볼 수 있다. 그렇기에 PCB보다는 image를 복사해 오는 오버 헤드가 더 크게 발생한다. 부모 프로세스한테 ls를 명령하면 바로 자식 프로세스가 자신만의 속성을 갖고 생성되는 것이 아니라, 먼저 부모 프로세스의 상태 정보를 복사하고 그 위에 자식 프로세스가 갖는 속성을 덮어 씌운다. 근데 생각해보면 이런 과정 자체가 너무 비효율적인 과정이라고 생각..

14. Process Create 부모 프로세스가 자식 프로세스를 만들어 내는 작업을 할 때는 두번의 오버헤드(overhead)가 발생한다. 이 오버헤드들은 fork()를 하는 도중 발생하며, 첫번째 오버헤드는 부모 프로세스의 이미지를 자식에게 복사할 때 생기고 두번째는 부모 프로세스의 PCB를 자식 프로세스에 복사하며 생긴다. 작업 과정을 자세히 알아보기 전에 먼저 PCB의 구성에 대해 알아보자. # Note 오버헤드: 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간, 메모리 등을 말한다. A라는 처리를 10초만에 했지만 안전성 고려 때문에 처리가 15초가 걸리는 B의 방식은 오버헤드가 5초가 발생한 것이다. 또한 이러한 B의 방식을 개선해 12초가 걸리면 오버헤드가 3초 단축되었다고 말한다. 14..

12. 총정리 지금까지 다뤘던 내용들을 총 엮어서 설명을 진행한다. 꽤나 복잡한 그림이 엮여 나오니 설명과 함께 따라오도록 노력해보자. 일단 아래 그림에 분홍색 구간은 커널이다. 커널 안에는 여러가지 시스템 콜이 존재하고 있다. 그리고 이 시스템 콜들은 context_switch()와 같은 내부함수와 연관이 있으며 각 하드웨어 자원마다 자료구조가 존재(struct CPU)한다. 아래 그림 또한 그림에 오류가 있는 부분이 있는데, 오류가 난 부분은 설명하면서 함께 나오니 너무 걱정할 필요는 없다. fork()를 진행하면 커널로 진입한다. 커널에서 fork( )는 부모 프로세스와 똑같은 image를 생성한다. 점선으로 표시된 이유는 아직 CPU 제어가 부모 프로세스에 있기 때문에 자식 프로세스로 향하는 선은..

11. Context Switch (유저 모드와 커널 모드 사이의 전환) 지금부터 설명하는 내용은, 설명과 함께 그림을 봐야 이해가 잘되니 이 점 꼭 유의해서 설명을 차근차근 살펴보자. 유저가 쉘이 띄어 준 프롬프트에 명령어(“ls”)를 입력한다. 쉘 입장에서 이 프로세스를 실행시키기 위해서 fork( )를 실행한다. 여기서 쉘은 부모 프로세스가 되고 새롭게 생기는 프로세스는 자식 프로세스가 된다. fork()가 동작하면서 쉘의 PCB와 쉘의 a.out(코드)을 그대로 복사한다. 그러나 CPU는 아직 쉘에게 할당되어 있기 때문에 ls가 실행되거나 하진 않는다. 부모 프로세스 쉘이 wait( )을 호출하게 되고 쉘은 잠들게 된다. 잠들면서 부모 프로세스는 CPU의 대기 리스트(queue)에 들어가게 된다...

9. 주요 시스템 콜 동작 원리 2강에서 설명했던 fork()의 작동 원리에 대해서 이어서 설명한다. fork()뿐만아니라 이번 3강에서는 다양한 시스템 콜에 대해 학습한다. 또한 데몬(Daemon)과 서버(Server)에 대해서도 간단히 학습할 것이다. 시작하기 앞서 이번 강의에서 등장할 그림들에 오류가 있다는 점을 언급하고 싶다. 오류가 있는 부분은 별도로 빨간색으로 마크해서 원래 있어야할 곳으로 표식을 해놓거나 중간 중간 어떤 부분에 오류가 있는지를 언급을 했으니 부디 설명을 읽으면서 헷갈리지 않길 바란다. 9.1 Fork(2)의 동작 원리 그림에서 수정된 사안이 하나 있는데, printf(“I am parent!\n”)부분이 else 구문에 속해야하는 것이 맞다. 이점을 주의해서 아래 설명을 보자..

8. Child Process 생성하기 컴퓨터를 부팅하면 제일 먼저 커널 프로세스가 로드된다. 그리고 이 커널은 터미널이 켜질때 마다 그에 해당하는 Shell, 즉 Child Process를 만든다. Shell은 사용자의 입력을 기다리고 입력이 들어오면 그에 따른 작업을 수행해주는 프로그램이다. 사용자가 Mail이라고 입력하면 Mail이라는 Child Process가 생성 된다. 이처럼 프로세스들이 진행될 때는 자식 프로세스(Child Process)가 생성되면서 진행된다. 따라서 커널을 공부할 때 Child Process는 반드시 알아야하는 개념이다. 지금부터의 설명은 아래 그림과 함께 살펴보도록 한다. # Note 잠시 여기서 프로그램과 프로세스의 차이에 대해 알아보자. 프로그램과 프로세스의 차이는 ..

7. Process Management 시스템 콜에 대한 내용은 이 정도로 정리하고, Process Management에 대한 내용으로 넘어가자. Process Management는 커널이 하는 아주 중요한 임무 중 하나로서 반드시 짚고 넘어가야 할 부분 중 하나다. 7.1 OS Kernel 1강에서 우리는 운영체제가 어떤 역할을 하는지를 배웠다. 운영체제는 하드웨어 자원을 관리하고 프로그램들을 지원해주는 역할을 한다. 이와 마찬가지로 운영체제의 핵심인 커널 또한 같은 역할을 한다. 위 그림을 살펴보자. 커널은 위로는 프로그램들을 지원하고 밑으로는 하드웨어(CPU, Memory, Disk, TTY)를 관리하는 데이터와 기능들을 가지고 있는 프로그램이다. # Note 실제로 위 아래 개념이 존재하는 것은 ..

6. 시스템 콜(System Call) 시스템 콜(System Call)은 것은 정확히 언제 일어나는 것일까? 우리가 I/O관련 function을 하려고 하면 그때 바로 일어나는 것일까? 이것을 알아보기 위해 먼저 밑에 그림을 보자. 리눅스 명령어는 옆에 붙은 숫자에 따라 커맨드(1), 시스템 콜(2), 라이브러리 함수(3)*로 구분된다.* 위 그림의 좌측을 보면 유저 영역 안에 내가(유저)가 작성한 코드 my code가 있다. 이 코드에서 printf()를 호출(call) 하는데 이 printf() 코드는 내가 작성한 게 아니라 library function이다. C언어를 배울 때 #include 를 하는 이유를 생각해보면 금방 이해할 것이다. 그럼 이제 printf()가 내가 작성한 코드 my cod..

5. 인터럽트와 트랩 인터럽트는 시스템 내에서 하드웨어가 생성한 흐름 변경이다. 인터럽트 원인을 처리하기 위해 인터럽트 처리기가 사용된다. 제어는 인터럽트된 컨텍스트 및 명령으로 리턴된다. 트랩은 소프트웨어가 생성한 인터럽트다. 장치 폴링의 필요성을 없애기 위해 인터럽트를 사용하여 I/O의 완료를 알릴 수 있다. 트랩을 사용하여 운영 체제 루틴을 호출하거나 산술 오류를 포착 할 수 있다. 인터럽트는 하드웨어 인터럽트이며 트랩은 소프트웨어 호출 인터럽트이다. 하드웨어 인터럽트 발생은 일반적으로 다른 하드웨어 인터럽트를 비활성화하지만 트랩에는 해당되지 않는다. 트랩이 제공 될 때까지 하드웨어 인터럽트를 허용하지 않으려면 명시 적으로 인터럽트 플래그를 지워야한다. 일반적으로 컴퓨터의 인터럽트 플래그는 트랩이 ..

3. printf("Hello World!")의 진실 그러면 이제 우리가 한 가지 궁금한 점이 있다. 우리는 프로그램을 만들 때 소스코드에 입출력과 관련된 함수를 작성한다. printf()를 사용하거나 get()등 디스크에 접근해서 값을 읽어오거나 화면에 문자를 출력하는 함수를 사용한다. 우리가 작성한 코드와 프로그램은 유저모드에서 아무런 제약없이 사용할 수 있었는데, 왜 I/O가 금지되었다고 말을 하는 것일까? 정답은 “소스코드에서만 그렇게 보인다”이다. 소스코드에서는 개발자가 입출력을 관리하는 것처럼 보이지만, 소스코드를 컴파일 한 후에 바이너리 파일을 열어보면 I/O와 관련된 instruction은 전혀 존재하지 않는다. 위에서 언급했듯이 I/O를 하고 싶으면 커널이 가지고 있는 function을 ..

2. 운영체제 비교, 리눅스 vs 윈도우 2.1 자원의 소모에 대하여 운영체제에는 종류가 굉장히 많지만 가장 대표적이라고 일컬어지는 리눅스와 윈도우를 한 번 비교해보려 한다. 윈도우는 개인 컴퓨터(Personal Computer)에 사용되는 운영체제다. 개인 컴퓨터에 쓰인다는 것은 나홀로 사용자라는 것, 즉 싱글유저 시스템이라는 의미다. 리눅스가 멀티유저 시스템으로 만들어진 것과는 상반된다. 싱글유저 시스템일 때는 보안문제에 대해서 신경을 별로 안 써도 되지만, 멀티유저 시스템일 때는 보안에 특히 신경을 써야 한다. 이유는 간단하다. 멀티유저 시스템은 그 안에 내 파일 뿐만 아니라 다른 사람의 파일 또한 존재하기 때문이다. 내가 다른 사람의 파일을 멋대로 읽고 쓸 수 있다면? 즉 삭제하고 변경할 수 있다..