본문으로 건너뛰기

제 III 편: 병행성

쓰레드, 락, 컨디션 변수, 세마포어

📄️ 제26장: 병행성: 개요

지금까지 운영체제가 다루는 기본 개념들의 발전 과정을 살펴보았다. 하나의 물리적 CPU를 다수의 가상 CPU로 확장하여 마치 여러 개의 프로그램이 동시에 실행하는 듯한 착시를 만들었다. 그리고 개별적인 프로세스가 모두 독립적으로 많은 가상 메모리를 가지는 것처럼 보이게 만들었다. 주소 공간(address space)이라는 개념을 통해 각 프로그램들이 마치 자신만의 메모리를 가지고 있는 것처럼 동작하는데, 사실은 운영체제가 물리 메모리를 여러 개의 주소 공간이 서로 번갈아 가면서 사용하게 한다.

📄️ 제28장: 락

병행성에 대한 소개 이후 병행 프로그램의 근본적인 문제 몇 개를 살펴보았다. 여러 개의 명령어들을 원자적으로 실행해보고 싶지만 단일 프로세서의 인터럽트로 인해서 (또는 멀티 쓰레드를 여러 프로세서에 병행 실행하려고 해서) 그렇게 할 수가 없었다. 이 장에서는 앞서 다룬 락(lock)을 이용하여 이 문제를 직접적으로 다루고자 한다. 프로그래머들은 소스 코드의 임계 영역을 락으로 둘러서 그 임계 영역이 마치 하나의 원자 단위 명령어인 것처럼 실행되도록 한다.

📄️ 제29장: 락 기반의 병행 자료 구조

다른 주제로 넘어가기 전에 먼저 흔하게 사용되는 자료 구조에서 락을 사용하는 방법을 살펴보자. 자료 구조에 락을 추가하여 쓰레드가 사용할 수 있도록 만들면 그 구조는 쓰레드 사용에 안전(쓰레드 안전, thread safe)하다고 할 수 있다. 물론, 락이 어떤 방식으로 추가 되느냐에 따라 그 자료 구조의 정확성과 성능을 좌우할 것이다. 주어진 도전은 다음과 같다.

📄️ 제31장: 세마포어

다양한 범주의 병행성 문제 해결을 위해서는 락과 조건 변수가 모두 필요하다. 정확한 역사를 파악하기는 어렵지만, 이 사실을 최초로 인지한 사람 중에 Edsger Dijkstra(우리말로 "다이직스트라"라고 발음하면 대략 비슷하다)가 있다 [GR92]. 그는 "최단 경로" 알고리즘이라고 하는 그래프 이론으로 유명할 뿐만 아니라 Dij59] "Goto 문의 유해성 (Goto Statements Considered Harmful)"(제목이 정말 멋있다!) 이라는 구조화 프로그래밍에 관한 격렬한 논쟁을 이끌어낸 것으로도 유명하다 [[Dij68a]. 이번 장에서 다루게 될 세마포어(semaphore)라는 동기화 기법도 그가 개발한 것이다 [Dij68b]; [Dij72]. Dijkstra와 그의 동료들은 모든 다양한 동기화 관련 문제를 한 번에 해결할 수 있는 그런 기법을 개발하고자 했다. 그리고 세마포어가 탄생했다. 실로 엄청난 사건이 아니라 할 수 없다. 이제 보게 되겠지만, 세마포어는 락과 컨디션 변수로 모두 사용할 수 있다.

📄️ 제32장: 병행성 관련 오류

수년 동안 병행성 관련 오류 해결을 위해 연구자들이 엄청난 시간과 노력을 들였다. 대부분의 초기 연구는 교착 상태(deadlock)에 초점이 맞추어져 있었다. 이번 장에서는 좀 더 심도 있게 살펴보기로 한다 [CES71]. 최근의 연구들은 다른 종류의 병행성 버그들을 다루고 있다 (비 교착 상태 버그). 이번 장에서는 실제 코드들을 예로 사용하여 병행성 문제들을 살펴보고 어떤 문제들을 조심해야 하는지 보도록 하겠다. 우리가 이번 장에서 다룰 핵심 문제는 다음과 같다.

📄️ 제33장: 이벤트 기반의 병행성 (고급)

이제까지는 쓰레드를 병행 프로그램을 제작하는 유일한 도구인 것처럼 언급했다. 인생의 많은 일들이 대부분 그렇듯, 운영체제에서도 방법이 하나만 있는 경우는 거의 없다. 특히, GUI 기반 프로그램이나 [Ous96] 인터넷 서버 [PDZ99]에서는 다른 스타일의 병행 프로그래밍이 사용된다. 이런 스타일을 이벤트 기반의 병행성(event-based concurrency)이라 한다. node.js [N1313]와 같은 서버 프레임워크에서 사용되지만, 그 시작점은 지금부터 다룰 C와 유닉스 시스템이다.