저번 포스팅에서 시스템 자원에 여러 프로세스/스레드가 동시에 접근해서 사용하면 발생할 수 있는 동기화 문제에 대해 알아봤는데, 이러한 동기화 문제를 해결하기 위한 기법인 뮤텍스(Mutex), 세마포어(Semaphore), 모니터(Monitor)에 대해 알아보고 비교하고자 한다.

뮤텍스(Mutex)

뮤텍스(Mutex, Mutual Exclusion)는 상호 배제를 의미하며, 한 번에 하나의 프로세스 또는 스레드만이 공유 자원에 접근할 수 있도록 보장하는 동기화 메커니즘이다. 이를 통해 임계 영역(Critical Section)을 보호하고 경쟁 상태(Race Condition)를 방지할 수 있다.

뮤텍스의 구현 요소

뮤텍스는 다음과 같은 요소로 구성된다:

• acquire(): 뮤텍스를 획득하는 함수.
• release(): 뮤텍스를 해제하는 함수.
• available: 뮤텍스의 가용 여부를 나타내는 불리언 변수.

❗️ acquire() 와 release() 는 반드시 원자적(Atomic)으로 수행되어야 한다.

원자적 연산을 보장하기 위해 Compare-And-Swap(CAS) 연산과 같은 하드웨어 명령어를 활용할 수 있다. 만약에 컴퓨터가 단일 코어라면, 그냥 인터럽트를 Disable 시키면 간단하다.

뮤텍스의 동작 방식

#include <stdio.h>
#include <pthread.h>

#define ITERATIONS 10000  // 반복 횟수 정의

int sum = 0;              // 공유 변수
pthread_mutex_t mutex;    // 뮤텍스 선언

// 스레드 함수: sum을 증가시키는 역할
void *counter(void *param) {
    for (int k = 0; k < ITERATIONS; k++) {
        // Entry section: 뮤텍스 잠금
        pthread_mutex_lock(&mutex);

        // Critical section: 공유 변수 sum 증가
        sum++;

        // Exit section: 뮤텍스 잠금 해제
        pthread_mutex_unlock(&mutex);
    }
    pthread_exit(0);
}

int main() {
    pthread_t tid1, tid2;

    // 뮤텍스 초기화
    pthread_mutex_init(&mutex, NULL);

    // 두 개의 스레드 생성
    pthread_create(&tid1, NULL, counter, NULL);
    pthread_create(&tid2, NULL, counter, NULL);

    // 스레드가 종료될 때까지 대기
    pthread_join(tid1, NULL);
    pthread_join(tid2, NULL);

    printf("sum = %d\n", sum);

    // 뮤텍스 제거
    pthread_mutex_destroy(&mutex);
    return 0;
}

1. 프로세스(또는 스레드)는 임계 영역에 들어가기 전에 뮤텍스를 획득(Acquire) 해야 한다.
2. 해당 프로세스(또는 스레드)가 임계 영역을 실행한다.
3. 임계 영역이 끝나면 뮤텍스를 해제(Release) 한다.
4. 다른 프로세스(또는 스레드)가 뮤텍스를 획득할 수 있도록 허용한다.

하지만 뮤텍스를 획득하지 못한 프로세스가 acquire() 함수에서 무한 루프를 돌며 기다리는 바쁜 대기(Busy Waiting) 문제가 발생할 수 있다. 그러나 이 방식은 장점이 될 수 있다. 이 장점을 살린 방식이 스핀락(Spinlock)이다.

스핀락(Spinlock)

뮤텍스의 한 형태로 스핀락(Spinlock)이 존재한다. 스핀락은 뮤텍스 잠금을 획득할 때까지 계속해서 CPU를 점유하면서 루프를 돌며 대기하는 방식인, 즉 Busy Waiting을 하는 뮤텍스이다.

스핀락은 바쁜 대기를 사용하지만 특정 상황에서는 효율적일 수 있다. 문맥 교환(Context Switch) 없이 동작하므로, 짧은 시간 내에 뮤텍스를 획득할 가능성이 높을 때 유리하다. 멀티코어 시스템에서는 하나의 코어에서 스레드가 뮤텍스를 해제하는 동안 다른 코어에서 대기하는 스레드가 바로 실행될 수 있어 스핀락이 오히려 더 좋은 선택일 수 있다.

그러나 스핀락은 단일 코어 시스템에서는 비효율적이므로, 일반적인 멀티스레드 환경에서는 바쁜 대기를 피하기 위해 세마포어(Semaphore)나 조건 변수(Condition Variable)와 같은 동기화 기법을 추가로 활용할 수 있다.

세마포어(Semaphore)

세마포어는 Edsger Dijkstra가 제안한 동기화 도구로, 뮤텍스와 달리 공유 자원에 동시에 접근할 수 있는 프로세스나 스레드의 수를 제어할 수 있다. 출입 가능한 자동차 수를 관리하는 주차장이라고 생각하면 된다.

세마포어(Semaphore) S는 정수형 변수이며, 초기화 이후에는 두 가지 원자적 연산인 wait()과 signal() (혹은 P()와 V())을 통해서만 접근할 수 있다. 이때 P()와 V() 연산은 각각 네덜란드어인 Proberen(시험하다)과 Verhogen(증가하다)에서 유래되었는데, 이는 Edsger Dijkstra가 네덜란드의 컴퓨터 과학자라 그렇다.

세마포어의 종류

1. 이진 세마포어(Binary Semaphore)
   • 값이 0과 1 사이에서만 변하며, 1인 경우 뮤텍스와 유사하다.
2. 카운팅 세마포어(Counting Semaphore)
   • 값이 0 이상을 가질 수 있으며, 특정 개수의 공유 자원 관리에 사용된다.

세마포어의 동작 방식(Busy - Wait 방식)

카운팅 세마포어를 이용하여 다중 스레드 환경에서 공유 변수 sum 에 접근하는 예시이다.
만약 sem_init 에서 5 대신 1을 넣는다면 Binary Semaphore가 된다.

#include <stdio.h>
#include <pthread.h>
#include <semaphore.h>

int sum = 0; // 공유 변수
sem_t sem;

void *counter(void *param) {
    for (int k = 0; k < 10000; k++) {
        sem_wait(&sem); // 세마포어 감소 (진입 허용 대기)
        sum++;
        sem_post(&sem); // 세마포어 증가 (자원 반환)
    }
    pthread_exit(0);
}

int main() {
    pthread_t tid[5]; int i;
		sem_init(&sem, 0, 5);
		
		for (i = 0; i < 5; i++)
			pthread_create(&tid[i], NULL, counter, NULL);
			
		for (i = 0; i < 5; i++)
			pthread_join(tid[i], NULL);
			
		printf("sum = %d\n", sum);
    return 0;
}

1. 세마포어를 사용 가능한 자원의 개수로 초기화한다.
2. 프로세스가 자원을 사용하려면 wait()을 호출하여 세마포어 값을 감소시킨다.
3. 프로세스가 자원을 반납할 때 signal()을 호출하여 세마포어 값을 증가시킨다.
4. 세마포어 값이 0이 되면, 추가적인 프로세스는 자원이 반환될 때까지 대기한다.

기본적인 세마포어는 뮤텍스처럼 바쁜 대기(Busy Waiting) 문제를 가질 수 있다. 이를 해결하기 위해, Block - Wakeup 방식이 존재한다.
wait() 연산을 수행한 후 자원이 없으면 Busy Waiting을 하지 않고(While문 돌지 않고) 프로세스를 대기 상태로 변경한 후 대기 큐(Waiting Queue)에 삽입한다. 이후 다른 프로세스가 signal() 연산을 호출하면 대기 중인 프로세스를 다시 실행 가능 상태(Ready Queue)로 이동시킨다. 이러한 방식으로 바쁜 대기(Busy Waiting) 문제를 해결할 수 있다.

Busy-Wait VS Block-Wakeup

임계 구역(Critical Section)의 길이가 긴 경우는 Block-Wakeup 방식이 유리하다. 하지만 임계 구역이 짧다면 잦은 문맥 교환으로 인해 오버헤드가 증가하게 되므로 Busy-Wait 방식이 유리하다.

뮤텍스 vs 세마포어

이진 세마포어(Binary Semaphore)는 0과 1만 가지는 세마포어로, 단 하나의 스레드만 임계 구역(공유 자원)에 접근할 수 있도록 제한하는 역할을 한다. 즉, 뮤텍스와 같은 기능을 수행할 수 있다.

하지만 뮤텍스는 세마포어처럼 여러 개의 스레드가 동시에 접근하도록 허용할 수 없다. 그렇다면, 왜 굳이 뮤텍스를 사용할까?

뮤텍스를 사용하는 이유

1. 소유 개념이 존재하기 때문에 보다 안전한 동기화가 가능하다.

   세마포어는 한 스레드가 wait()을 호출하여 자원을 획득한 후, 다른 스레드가 signal()을 호출하여 이를 해제할 수도 있다. 이 경우, 프로그래머의 실수로 인해 의도치 않게 자원이 해제되는 문제가 발생할 수 있다. 반면, 뮤텍스는 이를 획득한 스레드만이 해제할 수 있기 때문에 이러한 실수를 방지할 수 있다.

2. 데드락(Deadlock) 위험을 줄일 수 있다.

   세마포어는 직접 카운트를 관리해야 하므로, wait()을 여러 번 호출하고 signal()을 적절히 호출하지 않으면 데드락 상태에 빠질 수 있다. 그러나 뮤텍스는 단순히 "획득 ➡️ 해제"의 형태로 동작하므로 프로그래머가 실수할 가능성이 줄어든다.

3. 명확한 상호 배제(Mutual Exclusion)를 보장한다.

   뮤텍스는 원래 목적이 "하나의 스레드만 공유 자원에 접근하도록 제한하는 것"이므로, 공유 자원의 보호에 최적화되어 있다. 반면, 세마포어는 여러 스레드가 접근할 수 있도록 허용하는 용도로 설계된 만큼, 뮤텍스를 사용해야 하는 상황에서도 잘못 적용하면 동기화 문제가 발생할 수 있다.

그렇다면 세마포어는 왜 사용할까?

뮤텍스가 보다 안전하고 직관적인 동기화 방식을 제공한다면, 세마포어는 왜 존재할까? 그 이유는 세마포어가 동시 접근을 제한하는 데 유용하기 때문이다.

예를 들어, 데이터베이스 연결 풀(DB Connection Pool)과 같은 경우를 생각해보자. 만약 데이터베이스가 최대 5개의 동시 연결만 허용한다고 가정하면, 뮤텍스로는 하나의 스레드만 접근할 수 있어 효율이 떨어진다. 그러나 세마포어를 이용하면 5개의 스레드가 동시에 접근하도록 제한할 수 있어 자원을 보다 효율적으로 활용할 수 있다.

또한, IPC에서도 세마포어는 유용하다. 뮤텍스는 일반적으로 하나의 프로세스 내에서 동작하지만, 세마포어는 여러 개의 프로세스 간 자원 접근을 조정할 수 있기 때문이다.

IPC가 궁금하다면? 여기를 클릭하면 자세히 알 수 있다. 🤗

즉, 뮤텍스는 단순하고 안전한 동기화를 보장하지만, 여러 스레드가 접근해야 하는 상황에서는 비효율적일 수 있다. 반면, 세마포어는 더 유연한 동기화 방법을 제공하지만, 직접 카운트를 관리해야 하므로 실수할 가능성이 크다. 물론 두 기법 모두 완벽히 데이터 무결성을 보장할 수 없고 데드락이 발생할 수 있다는 점을 기억하자.

세마포어의 단점

세마포어는 유연한 동기화 도구이지만, 실행 순서가 깨지는 등의 타이밍 오류가 발생할 수 있다. 예를 들어,

1. wait(mutex)와 signal(mutex)의 순서를 바꾸면 동기화가 깨질 수 있다.
   • Ex) 임계영역에 동시에 두개의 프로세스가 들어갈 수 있다.
2. signal()대신 wait()로 잘못 사용하면 데드락이 발생할 수 있다.
3. wait() 또는 signal()을 생략하면 경쟁 상태(race condition)가 발생할 수 있다.

이러한 문제들은 모두 개발자가 세마포어를 어떻게 사용하느냐에 따라 발생한다. 즉, 프로그래머의 실수로 인해 동기화 문제를 일으킬 수 있다는 것이다.

따라서 세마포어는 커널 레벨에서 운영체제(OS)의 동기화 메커니즘으로 여전히 사용되지만, 우리가 접하는 애플리케이션 개발 수준에서는 직접적인 세마포어보다는 모니터(Monitor) 기반의 동기화 도구가 더 일반적으로 사용된다.

모니터(Monitor)

모니터(Monitor)는 뮤텍스(Mutex)나 세마포어(Semaphore)와 같은 저수준 동기화 메커니즘을 추상화하여 더 높은 수준의 동기화 기능을 제공하는 개념이다. 이는 공유 자원을 임계 구역으로 감추고, 자원에 접근할 수 있는 인터페이스만을 제공함으로써 동기화를 보장한다. 즉, 프로세스가 직접 동기화 기법을 다루지 않고도 안전하게 공유 자원에 접근할 수 있도록 한다.

모니터는 프로그래머가 정의한 연산 집합을 포함하는 추상 자료형으로, 내부에서 사용할 수 있는 특정 함수나 메서드가 정의되어 있다. 이러한 연산들은 상호 배제(Mutual Exclusion)가 보장되므로, 한 번에 하나의 프로세스만 모니터 내부의 연산을 실행할 수 있다. 따라서, 개발자는 명시적으로 락을 관리할 필요 없이 보다 쉽게 임계 영역을 보호할 수 있다.

조건 변수 (Conditional Variables)

그러나 모니터만으로 모든 동기화 문제를 해결할 수 있는 것은 아니다. 특정 조건이 충족될 때까지 프로세스를 대기 상태로 만들기 위해 조건 변수(Condition Variable)가 필요하다. 조건 변수는 wait()와 signal() 연산을 통해 관리된다.

condition x, y;
x.wait(); // 현재 프로세스를 대기 상태로 전환
x.signal(); // 대기 중인 프로세스를 깨움

• wait() : 현재 실행 중인 프로세스를 대기 상태로 전환한다. 이는 세마포어의 P() 연산과 유사하게, 임계 구역에 진입하려는 프로세스가 선행 조건을 만족하지 못할 경우 대기하도록 한다.
• signal() : 대기 중인 프로세스를 깨워 실행을 재개하도록 한다. 이는 세마포어의 V() 연산과 유사하게 동작하며, 임계 구역이 비어 새로운 프로세스가 실행될 수 있도록 한다.

공유 자원인 은행 계좌 잔액(balance)을 보호하기 위해 모니터를 사용하는 코드를 예시로 들어보자.

(출처 : https://velog.io/@chappi/OS는-할껀데-핵심만-합니다.-8편-Critical-section-임계-구역2-mutex-semaphore-monitor-condition-variable)

monitor shared_balance {
    private:
        int balance = 10;
        boolean busy = false;
        condition mon;

    public:
        increase(int amount) {
            if (busy == true) mon.wait(); // 임계 구역이 사용 중이면 대기
            busy = true; // 임계 구역 진입
            balance = balance + amount; // 공유 자원 수정
            mon.signal(); // 다음 대기 중인 프로세스 깨움
        }
}

이 코드에서 increase() 함수는 busy 플래그를 확인하여 임계 구역이 사용 중인지 체크한다. 만약 이미 다른 프로세스가 임계 구역을 사용하고 있다면, 현재 프로세스는 mon.wait()을 호출하여 대기 상태로 전환된다. 반대로, 임계 구역이 비어 있다면 busy를 true로 설정하고 balance를 갱신한 뒤, mon.signal()을 호출하여 대기 중인 다른 프로세스를 깨운다.

예를 들어, 프로세스 P1과 P2가 increase() 함수를 호출한다고 가정해보자. P1이 먼저 실행되고, balance = balance + amount 수행 도중 타임 슬롯이 끝나게 된다면, P2가 increase()를 실행하려고 시도할 것이다. 그러나 busy가 true이므로 P2는 mon.wait()을 호출하고 대기 상태로 들어간다. 이후 P1이 작업을 마치고 mon.signal()을 호출하면, P2가 대기 큐에서 깨어나 실행을 이어갈 수 있게 된다.

모니터는 이러한 방식으로 동기화를 자동으로 관리하면서 불필요한 정보를 숨기고, 공유 자원에 대한 명확한 인터페이스만을 제공한다. 이는 객체 지향 프로그래밍에서의 정보 은닉(Information Hiding) 개념과도 유사하다.

뮤텍스 vs 모니터

먼저, 뮤텍스는 여러 프로세스나 스레드 간 동기화를 위해 사용된다. 즉, 운영체제 커널이 제공하는 락(Lock) 메커니즘으로, 서로 다른 프로세스에서도 공유 자원을 안전하게 보호할 수 있다. 하지만 운영체제 차원의 동기화 기능이기 때문에 무겁고 성능이 다소 느리다는 단점이 있다.

반면, 모니터는 하나의 프로세스 내에서 스레드 간 동기화를 위해 제공된다. 운영체제 수준이 아니라 프로그래밍 언어나 프레임워크에서 제공하는 동기화 기능이며, 내부적으로 뮤텍스를 활용하지만 더 높은 수준의 추상화된 개념이다. 대표적인 예로 Java에서 synchronized, wait(), notify() 등을 이용한 동기화 방식이 있다.

즉, 모니터는 뮤텍스의 상위 개념으로 볼 수 있으며, 프로그래머가 직접 락을 관리할 필요 없이 더 쉽게 동기화할 수 있도록 도와준다. 따라서 뮤텍스는 커널 단에서 동작하는 무겁지만 강력한 동기화 방식이고, 모니터는 언어 차원에서 제공되는 더 가볍고 편리한 동기화 도구라고 볼 수 있다.

세마포어 vs 모니터

세마포어는 카운터 기반 동기화 기법으로, 개발자가 직접 값을 설정해야 한다. 하지만 프로그래머가 직접 wait()과 signal()을 사용해 카운트 값을 조작해야 하므로 관리가 번거로울 수 있다.

반면, 모니터는 내부적으로 동기화 메커니즘을 캡슐화하여 개발자가 직접 락을 관리할 필요가 없다. Java에서는 모든 객체가 기본적으로 모니터를 제공하며, synchronized 키워드를 사용하면 자동으로 락을 획득하고 해제하는 기능을 수행한다. 또한, wait(), notify(), notifyAll() 같은 메서드를 활용하면 스레드 간의 협력적인 동기화가 가능하다.

또한, 모니터는 하나의 프로세스 내에서만 동작하는 반면, 세마포어는 다중 프로세스 환경에서도 사용될 수 있다는 차이점이 있다. 즉, 모니터는 기본적으로 단일 프로세스의 스레드 동기화에 초점을 맞추고 있으며, 세마포어는 운영체제 차원에서 프로세스 간 동기화(IPC)까지 지원할 수 있다.

+) Java의 모니터 기능

• synchronized 키워드
  • 특정 코드 블록(임계영역)에 대해 모니터 락을 적용
  • synchronized (object) { // 임계영역 }
  • 메서드 전체에 적용 가능 → public synchronized void method() {}
• wait()와 notify() 메서드
  • wait(): 현재 스레드 대기 상태로 만듦
  • notify(): 대기 중인 스레드 중 하나를 깨움
  • notifyAll(): 대기 중인 모든 스레드를 깨움

+) 라이브니스(Liveness)

라이브니스(Liveness)는 프로세스가 언젠가는 반드시 진행될 수 있음을 보장하는 성질을 의미한다. 즉, 시스템이 교착 상태(Deadlock)나 무한 대기(Starvation) 없이 정상적으로 실행되도록 하는 개념이다.

+) 세마포어나 모니터는 데드락과 기아 현상을 해결해주지 못한다.

데드락(Deadlock)

• 두 개 이상의 프로세스가 서로의 자원을 기다리면서 영원히 멈추는 상태

우선순위 역전(Priority Inversion)

• 낮은 우선순위 프로세스가 자원을 점유하면서 높은 우선순위 프로세스가 대기

참고 자료

[지금 무료]운영체제 공룡책 강의 강의 | 주니온 - 인프런

[OS] 동기화 문제

OS는 할껀데 핵심만 합니다. 9편 Critical section (임계 구역2) , mutex, semaphore, monitor, condition variable

[운영체제] 세마포어(semaphore) 뮤텍스(mutex) 모니터(Monitor)

[OS] 4. 프로세스 동기화 (Process Synchronization)