OS

글 8개

OS · Blocking IO

스레드가 왜 멈춰 서 있나 - 블로킹 I/O

파일이나 네트워크를 기다리는 동안 스레드는 그 자리에 멈춰 선다. 이 블로킹이 왜 스레드 풀과 연결 풀의 크기를 정하고, 비동기가 왜 나왔는지 - 밑바닥의 OS를 다시 백엔드 개념으로 이으며 시리즈를 닫는다.

OS · File Descriptor

파일도, 네트워크 소켓도, DB 연결도 프로그램은 작은 정수 하나로 가리킨다. 파일 디스크립터라는 이 번호가 무엇이고, 왜 유한하며, 안 닫으면 왜 새는지 - 연결 풀이 반납에 그토록 예민한 이유가 여기 있다.

OS · System Call

프로그램은 파일을 직접 읽거나 네트워크로 직접 보내지 못한다. OS에게 부탁해야 한다. 유저 모드와 커널 모드라는 두 세계, 그 경계를 넘는 창구인 시스템 콜, 그리고 그 넘나듦이 왜 공짜가 아닌지.

OS · Context Switch

CPU 코어는 몇 개뿐인데 스레드는 수천 개다. OS는 스레드를 아주 빠르게 번갈아 태워 동시에 도는 것처럼 보이게 한다. 그 바꿔 태우기에 드는 비용이, 왜 스레드가 많을수록 손해인지를 설명한다.

OS · Thread

한 프로세스 안에서 여러 일을 동시에 하는 실행 흐름이 스레드다. 같은 주소공간을 공유하되 자기 스택만 따로 갖는다. 이 공유가 왜 스레드를 싸게 만들면서 동시에 공유 상태 문제를 낳는지.

OS · Stack

같은 주소공간 안에서도 지역변수와 직접 할당한 객체는 사는 곳이 다르다. 함수마다 쌓였다 자동으로 치워지는 스택, 직접 얻어 오래 두는 힙 - 스택 오버플로와 메모리 누수가 왜 생기는지가 여기서 갈린다.

OS · Virtual Memory

두 프로그램이 똑같은 메모리 주소를 써도 서로 안 부딪힌다. 각 프로세스가 보는 주소는 가짜고, OS가 진짜 물리 메모리로 몰래 바꿔치기하기 때문이다. 이 한 겹이 격리를 공짜로 만든다.

OS · Process

디스크의 파일 하나가 실행되면 프로세스가 된다. 자기만의 메모리, 열어둔 자원 목록, 어디까지 실행했는지 - 프로세스가 받는 세 가지를 보면, 왜 프로그램끼리 서로의 메모리를 못 건드리는지가 풀린다.