42 Seoul - 007_philosopher

🤔 philosopher : 동시성(Concurrency)의 두 가지 난제, 교착상태와 경쟁상태

동시성.

컴퓨터 공학을 배우면서, 그리고 실제 프로그래밍 하게 되면 특히나 고민되는 영역이다. 막연히 로망 같은 키워드로, 이걸 활용하면 정말 말도 안되게 성능이 좋아질 것 같다는, 그런 생각. 그런 로망을 실현하는 과제라는 점을 알게 되었을 때 한껏 신이 났었다. 물론 끔찍하단건 이젠 일상이다

so_long이 프로그램의 상태를 시각적 세계로 확장하는 경험이었다면, philosopher는 눈에 보이지 않는 시간의 축 위에서 여러 실행 흐름이 얽힐 때 발생하는 문제, 즉 동시성(Concurrency)의 심연을 들여다보는 과제다.

이 프로젝트는 컴퓨터 과학의 고전적인 ‘식사하는 철학자들’ 문제를 통해, 현대 멀티코어 환경에서 동작하는 모든 소프트웨어가 필연적으로 마주하는 두 가지 핵심 난제를 우리 앞에 제시한다:

자원 경쟁(Resource Competition)과 실행 흐름의 동기화(Synchronization).

이 과제는 단순히 스레드와 뮤텍스 API를 사용하는 법을 배우는 것을 넘어선다.

왜 동기화가 필요한지, 잘못된 동기화가 어떻게 시스템 전체를 마비시키는지, 그리고 교착상태와 경쟁상태라는 유령 같은 버그를 피하기 위해 얼마나 정교한 논리적 설계가 필요한지를 직접 증명하고 체감하는, 시스템 프로그래밍의 통과 의례와도 같은 과정이었다.

📜 문제의 본질: 한정된 자원과 비결정적 실행 순서

‘식사하는 철학자들’ 문제는 동시성 시스템의 축소판이다.

• 철학자 (Philosopher): 스레드(Thread) 또는 프로세스(Process)와 같은 독립적인 실행 단위를 상징한다.
• 포크 (Fork): 데이터베이스 커넥션, 파일 핸들러, 하드웨어 장치 등 동시에 접근할 수 없는 공유 자원(Shared Resource)을 상징한다.
• 식사 (Eating): 공유 자원을 점유하여 작업을 수행하는 임계 영역(Critical Section)을 의미한다.

이 모델에서 발생하는 근본적인 문제는, 각 스레드의 실행 순서와 시점을 운영체제의 스케줄러가 결정하기 때문에 비결정적(Non-deterministic)이라는 사실에서 출발한다. 이 비결정성이 두 가지 치명적인 버그를 낳는다.

1. 교착 상태 (Deadlock): 둘 이상의 스레드가 서로가 점유한 자원을 기다리며 더 이상 진행하지 못하는 상태. 이는 다음의 4가지 조건(Coffman Conditions)이 모두 충족될 때 발생한다.
   • 상호 배제 (Mutual Exclusion): 자원은 한 번에 하나의 스레드만 사용할 수 있다.
   • 점유 대기 (Hold and Wait): 자원을 하나 점유한 상태에서 다른 자원을 추가로 요청하며 대기한다.
   • 비선점 (No Preemption): 다른 스레드가 점유한 자원을 강제로 빼앗을 수 없다.
   • 환형 대기 (Circular Wait): 각 스레드가 다음 스레드가 점유한 자원을 요구하는 원형의 대기열이 형성된다.
2. 경쟁 상태 (Race Condition): 여러 스레드가 동시에 공유 자원에 접근하여 수정할 때, 실행 순서에 따라 결과가 의도와 다르게 나오는 상황. printf와 같은 단순한 출력 함수조차도 내부적으로 여러 단계로 동작하기에, 동기화 없이는 메시지가 뒤섞여 깨지는 경쟁 상태를 유발한다.
3. 기아 상태 (Starvation): 특정 스레드가 자원을 할당받을 기회를 영원히 얻지 못하는 상태를 말한다. 교착 상태는 모든 스레드가 멈추지만, 기아 상태는 다른 스레드들은 정상 동작하는 와중에 일부 스레드만 고립된다는 차이가 있다. 어찌 보면 시스템이 정상적으로 동작하는 것과 같은 느낌을 제시하지만, 정상적이지 못한 스레드에서 나오는 데이터, 상태 값, 그 외에도 시스템 상호작용에서 의존성이 존재한다면 시스템 전체가 오작동, 오판이 이루어질 수 있는 심각한 문제이다.

🛠️ Part 1: 스레드와 뮤텍스를 이용한 동기화 (Mandatory)

이 파트의 목표는 공유 메모리 모델의 동시성 단위인 스레드(Thread)와, 임계 영역을 보호하기 위한 가장 기본적인 동기화 도구인 뮤텍스(Mutex)를 사용하여 문제를 해결하는 것이다.

간단히 설명하면 철학자들은 양손으로 포크를 잡아야 먹을 수 있고, 필수 먹는 시간이 곧 생명 연장이 가능하고, 포크를 내려 놓고 생각-잠에 들어가는 과정이 되어야 비로소 다른 자원(포크)들을 다른 철학자가 취하고 다시 자신의 필요한 양의 먹기,철학자는 죽을 수 있고, 궁극적으로 제시되는 수준의 포크 갯수, 철학자 수, 그 외에도 먹는 시간 등의 조건을 달성하는 것이 핵심 목표이다.

• 솔루션의 핵심: 교착 상태를 유발하는 4가지 조건 중 하나를 깨뜨리는 것이다. 모든 철학자가 ‘왼쪽 포크 -> 오른쪽 포크’ 순서로 자원을 요청하면 환형 대기(Circular Wait) 조건이 성립하기 쉽다. 이를 해결하기 위해선 결국 환형 대기가 생기지 않도록, 순서나, 잡는 방법이 서로 다른 진영을 능동적으로 만들어주면 된다. 이때 가장 쉽고 적절한 것으로 짝수 번호 철학자는 왼쪽부터, 홀수 번호 철학자는 오른쪽부터 포크를 집도록 순서를 비대칭적으로 설계했다. 이 간단한 규칙의 변화가 자원 요청의 의존성 고리를 끊어 환형 대기를 원천적으로 방지한다. 추가로 하나 더 팁, 내지는 최적화를 하는 방법이 있다면, 먹기를 시작하는 것이 일제히 될 필요가 없다는 점도 중요하다. 홀수, 짝수로 먹되, 그 시작도 약간의 딜레이를 가지고 시작하게 함으로써 같은 그룹에서도 우선 먼저 먹게하는 사람과 나중 먹게 하는 사람을 만들어, 가능한 경쟁 관계가 바로 생기지 않도록 유도하는 것은, 초기 성능에 꽤나 중요한 역할을 했었다.
• 모니터링 스레드의 필요성: 동시에 각 철학자 스레드가 자신의 사망 여부를 스스로 판단하게 할 경우, 다른 스레드가 점유한 뮤텍스로 인해 블로킹되어 자신의 상태를 제때 확인하지 못할 수 있다. 따라서 철학자들의 상태를 감시하고 시뮬레이션을 종료하는 역할은, 철학자들이 사용하는 뮤텍스로부터 자유로운 별도의 모니터링 스레드(Watchdog)가 수행해야만 안정적인 감시가 가능하다고, 무엇보다 적절한 출력 및 사망 처리를 표시해줄 수 있어 반드시 필요했다.

🚀 Part 2: 프로세스와 세마포어를 이용한 IPC (Bonus)

보너스 파트는 독립적인 메모리 공간을 가진 프로세스(Process)를 fork()로 생성하고, 프로세스 간 통신(IPC, Inter-Process Communication)을 통해 동기화 문제를 해결할 것을 요구한다.

• 프로세스 모델의 차이: 스레드와 달리 프로세스는 메모리를 공유하지 않으므로, 뮤텍스처럼 메모리 주소를 공유하는 방식으로는 동기화할 수 없다. 따라서 커널 수준에서 관리되는 IPC 객체를 사용해야 한다.
• 세마포어 (Semaphore): 뮤텍스가 단 하나의 실행 흐름만 허용하는 잠금(lock)이라면, 세마포어는 정해진 개수(N)만큼의 실행 흐름을 동시에 허용하는 계수기(counter)이다. 이 문제에서는 모든 포크를 하나의 자원 풀로 보고, 포크의 총 개수를 카운트로 하는 세마포어 하나로 관리할 수 있다. 철학자는 sem_wait으로 포크 하나를 획득(카운트 감소)하고, sem_post로 반납(카운트 증가)한다. 이는 N개의 자원을 관리하는 데 있어 N개의 뮤텍스를 사용하는 것보다 훨씬 간결하고 직관적인 모델을 제공한다.
• 프로세스 모니터링: 부모 프로세스가 waitpid를 통해 자식 프로세스들의 종료 상태를 감시한다. 한 명의 철학자라도 사망(비정상 종료)하면, 부모 프로세스는 다른 모든 자식 프로세스들에게 kill 시그널을 보내 전체 시뮬레이션을 정리하는 역할을 수행한다.

✨ 성찰 및 배운 점

philosopher는 멀티 프로세싱, 멀티 스레딩이 ‘필요하지만’ 왜 ‘필수가 아닌가?’ 라는 것의 답과도 같은 프로젝트였다. 단지 일을 많이, 여럿이 한다고 그 일을 잘 한다고 볼 수 없으며, 오히려 정보의 처리, 정보의 소통 과정이 오히려 작업의 딜레이를 만들수 있다는, trade-off 가 있음을 보여주었다. 또한 동시성 버그가 왜 재현하기 어렵고 디버깅하기 힘든지, 그리고 왜 처음부터 신중한 설계가 중요한지를 가르쳐주었다.

• 동시성 설계의 중요성: 동시성 문제는 나중에 수정하는 것이 거의 불가능에 가깝다. 시스템 설계 단계부터 어떤 자원이 공유되고, 어떤 임계 영역이 존재하며, 어떤 동기화 전략을 사용할지 명확히 정의해야 함을 깨달았다.
• 동기화 도구의 이해: 뮤텍스는 상호 배제가 필요할 때, 세마포어는 자원 풀링(Pooling)이나 복잡한 실행 순서 제어가 필요할 때 사용하는 등, 각 동기화 도구의 본질적인 목적과 사용 사례를 구분하는 능력을 기를 수 있었다.
• 이론과 현실의 연결: 교착 상태의 4가지 조건과 같은 이론적 모델이 실제 코드에서 어떻게 발현되고, 그 이론에 기반하여 어떻게 문제를 해결할 수 있는지 직접 증명해 보았다. 이 경험은 데이터베이스의 트랜잭션 처리, 웹 서버의 스레드 풀 관리 등 현실 세계의 복잡한 동시성 시스템을 이해하는 단단한 기반이 되어주었다.