Mutual Exclusion

Mutual Exclusion

**상호 배제 (Mutual Exclusion)**는 병행 및 병렬 환경에서 여러 실행 흐름이 **임계 구역 (Critical Section)**을 동시에 접근하지 못하도록 제어하여 데이터 무결성과 시스템 안정성을 보장하는 핵심 동기화 메커니즘이다. 고전적 알고리즘 (Dekker, Peterson, Lamport) 부터 하드웨어 명령어 (Test-and-Set, CAS), 운영체제 도구 (Mutex, Semaphore, Monitor), 분산 시스템의 락 (Redis, etcd, ZooKeeper) 까지 폭넓게 활용된다. 데드락, 기아 상태, 우선순위 역전 같은 문제를 해결하며, 웹 서버, DB, 실시간 처리, 분산 트랜잭션 등 다양한 시스템에서 필수적인 개념이다.

등장 배경 및 발전 과정

• 초기 컴퓨터는 단일 프로세스 환경이었으나, 컴퓨터 성능이 향상되며 멀티프로그래밍・멀티프로세싱 등장.
• 여러 프로세스가 자원에 동시 접근하며 예상치 못한 오류와 데이터 훼손 발생.
• 소프트웨어적 해결책으로 고전적 알고리즘 (1950~70 년대) 들이 제안됨.
• 현대에는 하드웨어 지원 (Atomic Operation, CPU 명령어) 에 기반한 동기화 기법도 발전.

등장 배경

단일 프로세스 → 병행 프로세스의 전환

→ 병행 시스템에서 자원의 일관성과 안정성을 보장할 동기화 메커니즘의 필요성이 제기됨

발전과정

고전 소프트웨어 기반 알고리즘의 등장 (1960~1980 년대)

• 하드웨어 지원 없이 공유 메모리와 순수 알고리즘만으로 구현

하드웨어 기반 기법의 도입 (1980 년대 중반 이후)

→ 하드웨어 명령어를 통해 효율성, 원자성, 병렬성 보장
→ Lock-Free, Wait-Free 알고리즘 설계 기반 마련

운영체제 수준의 동기화 객체 등장

→ 프로그래밍 언어 및 OS 차원에서 추상화된 상호 배제 기법 보편화됨

분산 시스템 기반 상호 배제 알고리즘의 발전

→ 공유 메모리 없이도 네트워크 메시지를 통해 상호 배제 보장 가능
→ 분산 환경, 클러스터 기반 시스템에서 필수적

현대의 실무 기반 기법

→ 성능 최적화, 고가용성, 분산 처리를 위한 현대적 요구사항 대응
→ 실시간, 고성능 시스템, 클라우드 아키텍처에서 실무 활용도 높음

목적 및 필요성

데이터 보호 및 무결성 보장

• 공유 자원 (write 또는 read-modify-write) 에 대해 항상 하나의 주체만 접근하도록 강제하여 논리적 오류 및 불일치 제거

시스템 안정성과 신뢰성 확보

• 동시성 환경에서 프로세스 간의 충돌, 정지, 무한 대기 등 예측 불가능한 상태를 제거하여 운영의 신뢰성과 품질 확보

공정성 및 효율성 확보

• 여러 스레드 간 자원 접근을 공정하게 분배하고, 시스템 자원 사용의 효율성과 성능을 극대화

핵심 개념

이론적 핵심 개념 정리

상호 배제 알고리즘의 요구 조건 (정형화된 조건)

※ 대부분의 알고리즘은 위 조건 중 일부 또는 전부를 만족하며, 어떤 조건을 희생하느냐가 알고리즘 선택 기준이 됨

실무 적용과의 연관성

주요 기능 및 역할

기능 간 의존성과 흐름

1
2

[접근 제어] → [자원 보호] → [동기화] → [순서 제어/우선순위 제어] → [시스템 안정성 확보]
                        ↘︎ [상태 추적] ↗︎

• 접근 제어는 가장 기본이자 모든 기능의 전제 조건
• 자원 보호와 동기화는 실질적인 동작 보장을 위한 쌍
• 상태 추적, 교착 상태 회피, 우선순위 제어는 보완 기능이며, 시스템의 공정성과 신뢰성을 높이는 역할

기능 ↔ 역할 매핑 도식

graph TD
    A1[접근 제어] --> R1[상호 배제 보장]
    A2[자원 보호] --> R2[데이터 일관성 유지]
    A3[프로세스 동기화] --> R3[실행 충돌 방지]
    A4[실행 순서 제어] --> R4[공정성 및 Starvation 방지]
    A5[상태 추적] --> R5[시스템 안정성 확보]
    A6[교착 상태 회피] --> R6[진행 가능성 보장]
    A7[우선순위 제어] --> R7[우선순위 역전 방지]

    subgraph 기능
        A1
        A2
        A3
        A4
        A5
        A6
        A7
    end

    subgraph 역할
        R1
        R2
        R3
        R4
        R5
        R6
        R7
    end

• 각 기능 (Function) 이 수행하는 역할 (Role) 을 1:1 또는 1:N 매핑으로 시각화한 것으로, 구현 설계 시 책임 분리를 명확히 할 수 있다.

기능 흐름 및 책임 분리 기반

• 진입 단계: 접근 제어 와 실행 순서 제어 는 임계 구역 진입 전 조건 판단 및 순서 공정성 보장을 담당
• 실행 단계: 프로세스 동기화 와 자원 보호 는 실제 임계 구역 내에서의 자원 무결성과 충돌 방지를 책임
• 후속 제어: 상태 추적, 교착 상태 회피, 우선순위 제어 는 시스템이 오류 없이 안정적으로 운영되도록 뒷단에서 지속 관리

flowchart TD
    subgraph 진입 단계
        AC[접근 제어]
        SQ[실행 순서 제어]
    end

    subgraph 실행 단계
        RP[자원 보호]
        SY[프로세스 동기화]
    end

    subgraph 후속 제어
        ST[상태 추적]
        DL[교착 상태 회피]
        PR[우선순위 제어]
    end

    AC --> SQ
    SQ --> SY
    SY --> RP
    RP --> ST
    ST --> DL
    DL --> PR

    style AC fill:#e1f5fe,stroke:#0288d1
    style SQ fill:#e1f5fe,stroke:#0288d1
    style RP fill:#ffe0b2,stroke:#f57c00
    style SY fill:#ffe0b2,stroke:#f57c00
    style ST fill:#f3e5f5,stroke:#8e24aa
    style DL fill:#f3e5f5,stroke:#8e24aa
    style PR fill:#f3e5f5,stroke:#8e24aa

실무 시스템 기반 상호 배제 기능 매핑

graph TD
    subgraph Application Layer
        A1[Business Logic]
        A2[Concurrent Requests]
    end

    subgraph Synchronization Layer
        M1[Mutex / Lock]
        S1[Semaphore]
        R1[Distributed Lock Service]
    end

    subgraph Resource Layer
        DB[(Database)]
        CACHE[(Cache Store)]
        FILE[(File / Session)]

    end

    A1 -->|임계 구역 요청| M1
    A2 -->|동시 요청| S1
    M1 -->|락 획득| DB
    S1 -->|제한 접근| CACHE
    A1 --> R1
    R1 -->|분산 락| DB
    R1 -->|분산 락| FILE

• 로컬 환경에서는 Mutex, Semaphore 를 활용하여 동시 접근 제어
• 분산 환경에서는 Redis, Zookeeper, etcd 등으로 Distributed Lock 구성
• DB 트랜잭션 락, Cache 업데이트, 세션 파일 접근 등 공유 자원에 대한 보호 수행

기능별 장애 시나리오 및 복구 흐름도

flowchart TD
    start[시작: 임계 구역 요청]
    check[락 획득 시도]
    success[락 획득 성공]
    fail[락 획득 실패]
    retry[재시도 또는 대기]
    timeout[타임아웃 발생]
    escalate[우선순위 변경 / 에러 처리]
    critical[임계 구역 진입]
    release[자원 해제]
    complete[정상 종료]

    start --> check
    check -->|가능| success
    check -->|불가능| fail
    fail --> retry
    retry -->|재시도| check
    retry -->|시간 초과| timeout
    timeout --> escalate
    success --> critical
    critical --> release
    release --> complete

• 락 획득 실패: 경쟁 상태나 선점으로 실패 → retry / backoff / 대기
• 타임아웃: 영원한 대기 방지 → 우선순위 상승, 장애 로깅, 대체 흐름 이동
• 락 해제 실패: 다음 프로세스 교착 가능 → 락 모니터링 시스템 필수

🛠 실시간 서비스에서는 타임아웃 + fallback + 우선순위 정책 이 중요

이벤트 기반 시스템 내 상호 배제 구조

sequenceDiagram
    participant Producer
    participant EventQueue(Kafka/SQS)
    participant Consumer
    participant LockService(Redis/Zookeeper)
    participant Resource(DB/Cache)

    Producer->>EventQueue: 이벤트 발행 (OrderCreated)
    Consumer->>EventQueue: 이벤트 수신
    Consumer->>LockService: 락 획득 요청
    alt 락 획득 성공
        LockService-->>Consumer: OK
        Consumer->>Resource: DB/Cache 업데이트
        Consumer->>LockService: 락 해제
    else 락 획득 실패
        Consumer->>Consumer: 재시도 / 백오프
    end

• Producer: 도메인 이벤트 발행 (ex. 주문 생성)
• Consumer: 메시지를 소비하고 공유 자원 접근 전 분산 락 획득
• Lock Service: Redis 의 SET NX/EX, Redlock 또는 Zookeeper ephemeral node
• Resource: 동시성 제어가 필요한 DB, 세션, 전역 상태 등

특징

핵심 속성

🔍 이 다섯 가지는 Mutual Exclusion 알고리즘의 이론적 핵심 조건으로, 대부분의 교과서나 OS 논문에서 공통적으로 제시됨 (예: Peterson, Bakery 등은 이 기준을 충족하는지 분석됨)

시스템 관점의 특징

🔍 이 부분은 실무적 운영 설계 시 반드시 고려해야 하며, 특히 고성능 시스템에서는 락 최소화 / lock-free 설계가 중요하게 고려됨

구현 관점의 특징

🔍 특히 분산 환경에서는 토큰 기반, 허가 기반, 쿼럼 기반 등 메시지 전달을 중심으로 하여 정합성, 메시지 수, 병목성 등의 문제가 발생할 수 있음

Mutual Exclusion 의 주요 트레이드오프

성능 (Performance) Vs 안전성 (Safety)

📌 요점: 고성능이 필요한 환경에서는 락 - 프리나 스핀락이 유리하지만, 데이터 안정성 보장이 어려워짐. 시스템 안정성이 더 중요한 경우 Mutex 등의 블로킹 기법이 적절함.

공정성 (Fairness) Vs 복잡성 (Complexity)

📌 요점: 공정성을 보장하려면 큐, 시계, 우선순위 등 메커니즘을 추가해야 하며, 이는 코드 복잡성과 유지보수 비용 상승으로 이어짐.

확장성 (Scalability) Vs 자원 소모 (Resource Overhead)

📌 요점: 대규모 분산 환경에서는 확장성 높은 구조가 필요하지만, 정합성 보장 비용과 장애 대응 로직의 복잡도가 증가함.

응답 시간 (Response Time) Vs 결정성 (Determinism)

📌 요점: 실시간 시스템에서는 결정성보다 우선순위 기반 반응성이 중요하지만, 반대로 일반 시스템에서는 예측 가능한 순서가 더 바람직할 수 있음.

단순성 (Simplicity) Vs 장애 대응력 (Fault Tolerance)

📌 요점: 시스템 신뢰성 확보를 위해서는 복잡성을 감수하고 장애 상황에 대한 대응 로직을 설계해야 함.

핵심 원칙

상호 배제 (Mutual Exclusion)

진행성 (Progress)

유한 대기 (Bounded Waiting)

공정성 (Fairness)

속도 독립성 (Speed Independence) / 독립성

결정성 (Determinism)

주요 원리 및 작동 원리

핵심 원리

기본 구조 및 단계별 작동 방식

1

[Entry Section] → [Critical Section] → [Exit Section] → [Remainder Section]

• Entry Section: 진입 조건 검사 및 자원 획득 시도
• Critical Section: 공유 자원 접근 (락 획득 상태)
• Exit Section: 자원 해제 및 다음 프로세스에게 기회 제공
• Remainder Section: 일반 코드 실행

→ 이 구조는 소프트웨어/하드웨어/운영체제/분산 방식 모두에 적용됨

Mutual Exclusion 작동 흐름

flowchart TD
    A[프로세스 Pn → 진입 요청] --> B{임계구역 사용 가능?}
    B -- Yes --> C[임계구역 진입]
    B -- No --> D[대기 큐 등록 또는 대기 상태 유지]
    C --> E[공유 자원 접근 및 작업 수행]
    E --> F[임계구역 해제]
    F --> G{대기 중 프로세스 있음?}
    G -- Yes --> H[다음 프로세스에게 권한 부여]
    G -- No --> I[임계구역 유휴 상태]
    D --> J{진입 조건 충족?}
    J -- Yes --> C
    J -- No --> D

→ 이 흐름은 소프트웨어 기반 (Peterson, Bakery), 하드웨어 기반 (TAS, CAS), 운영체제 기반 (Mutex, Monitor), 분산 기반 (Ricart-Agrawala, Token Ring) 등 어디에도 적용 가능한 일반적인 작동 모델.

작동 방식별 구현 전략 (구현 방식별 원리 비교)

각 방식은 진입 조건 확인, 자원 점유 판단, 해제 방식에서 약간씩 차이를 가짐

작동 원리의 주요 고려사항

구조 및 아키텍처

flowchart TD
    subgraph 프로세스 영역
        P1[프로세스 1]
        P2[프로세스 2]
        Pn[프로세스 n]
    end

    subgraph 상호 배제 시스템
        subgraph 진입 처리
            EP[Entry Protocol]
            AT[원자적 연산 / 시스템 콜]
            SYNC["동기화 객체 (Mutex / Semaphore / Monitor)"]
        end

        subgraph 대기 및 보조 제어
            WQ[Waiting Queue]
            PM[Priority Manager]
            TM[Timeout Mechanism]
            DL[Deadlock Detection]
        end

        subgraph 임계 영역
            CS[Critical Section]
            SR[공유 자원]
        end

        subgraph 종료 처리
            XP[Exit Protocol]
        end
    end

    %% 프로세스 흐름
    P1 --> EP
    P2 --> EP
    Pn --> EP

    %% 진입 → 임계구역
    EP --> AT --> SYNC
    SYNC -->|성공| CS
    SYNC -->|실패| WQ

    %% 보조 흐름
    WQ -->|우선순위| PM
    WQ -->|타임아웃| TM
    WQ --> DL
    DL -->|재시도| EP

    %% 임계구역 종료
    CS --> SR --> XP --> SYNC

    style CS fill:#ffcccc
    style SYNC fill:#ccffcc
    style WQ fill:#ccccff
    style TM fill:#fff2cc
    style DL fill:#e0e0e0
    style PM fill:#fff0f5
    style XP fill:#d5f5e3

필수 구성 요소

Mutual Exclusion 의 핵심은 세 가지 영역 (진입 → 임계 → 해제) 을 명확히 구분하고, 동기화 객체를 통해 진입 권한을 제어하는 것이다. 모든 구현은 이 구조를 바탕으로 작동하며, Entry/Exit Protocol은 원자적 실행 보장과 상태 동기화를 반드시 수반해야 한다. 특히 Critical Section은 최소 시간 점유 및 병목 최소화가 중요하다.

선택 구성 요소

선택 요소들은 시스템 확장성, 공정성, 안정성 확보에 필수적이다. Waiting Queue는 스케줄링 기반 공정 접근 보장을, Priority Manager는 실시간 시스템과 우선순위 제어에 활용된다. Timeout Mechanism과 Deadlock Detection은 시스템 안정성 확보를 위한 보호 장치로 필수이며, Monitor는 동기화를 추상화하고 코드 품질을 향상시키는 고수준 도구로서 유용하다. 또한, Distributed Lock은 MSA 나 클러스터 기반 아키텍처에서 다중 노드 간 상호 배제를 실현하는 데 핵심이 된다.

구현 기법 및 방법

1. 소프트웨어 기반:
   플래그와 순서를 활용한 논리적 동기화 구조로, 하드웨어 지원 없이 구현 가능하나 busy-waiting이 필요하며, 일반적으로 두 개 또는 N 개 프로세스까지 제한적 적용됨. 공정성과 bounded waiting 보장에 유리하지만 실제 운영 환경보단 교육/연구용에 적합함.

2. 하드웨어 기반:
   CPU 가 제공하는 원자적 연산을 이용하여 빠르고 간단하게 상호 배제를 구현. 다만 busy-wait 을 유발할 수 있고, 락 프리 구조나 성능 최적화에 적합. CAS, Test-and-Set, Fetch-and-Add 등의 원자 연산이 대표적이며, 커널 수준에서 활용됨.

3. 운영체제 기반:
   OS 가 제공하는 고수준 동기화 도구로, 세마포어/뮤텍스/모니터가 주를 이룸. context switch 를 수반하며 공정하고 안정적이나, 비교적 무거운 비용이 수반됨. 실제 시스템 설계 시 가장 일반적으로 사용되는 기법들임.

4. 분산 시스템 기반:
   물리적으로 떨어진 노드 간 동기화가 필요한 경우 사용되며, 메시지 기반 접근이 일반적. Permission-based, Token-based, Quorum-based 방식으로 나뉘며, 메시지 복잡도/공정성/장애 허용성 등을 기준으로 선택함. 현실에선 Zookeeper/etcd 와 같은 외부 락 서비스가 보편적으로 사용됨.

5. 기타 현대 기법:
   락 - 프리 자료구조, 스핀락, 외부 락 서비스 등은 고성능 요구 또는 분산 환경 최적화에 적합한 방식으로, 컨텍스트 스위칭을 줄이거나 네트워크 기반 분산 락을 활용해 동기화 오버헤드를 줄임.

소프트웨어 기반 알고리즘

Dekker’s Algorithm (두 프로세스 간 상호 배제)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

flag = [False, False]
turn = 0

def dekker_critical_section(id):
    global turn
    other = 1 - id
    flag[id] = True
    while flag[other]:
        if turn != id:
            flag[id] = False
            while turn != id:
                pass
            flag[id] = True
    # 🚩 Critical Section
    print(f"Process {id} in critical section")
    # 🚩 Exit Section
    turn = other
    flag[id] = False

Peterson’s Algorithm (2 개 프로세스용)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

flag = [False, False]
turn = 0

def peterson(id):
    other = 1 - id
    flag[id] = True
    turn = other
    while flag[other] and turn == other:
        pass
    print(f"Process {id} in critical section")
    flag[id] = False

Lamport’s Bakery Algorithm (N 개 프로세스용)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

N = 5
choosing = [False] * N
number = [0] * N

def bakery(i):
    choosing[i] = True
    number[i] = 1 + max(number)
    choosing[i] = False

    for j in range(N):
        while choosing[j]:
            pass
        while number[j] != 0 and (number[j], j) < (number[i], i):
            pass

    print(f"Process {i} in critical section")
    number[i] = 0

하드웨어 기반 원자 연산

Test-and-Set (TAS)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

lock = False

def test_and_set():
    global lock
    prev = lock
    lock = True
    return prev

def critical_section():
    while test_and_set():
        pass
    print("In critical section")
    lock = False

Compare-and-Swap (CAS)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

class AtomicVariable:
    def __init__(self, value):
        self.value = value

    def compare_and_swap(self, expected, new_val):
        if self.value == expected:
            self.value = new_val
            return True
        return False

atomic_lock = AtomicVariable(0)

def cas_lock():
    while not atomic_lock.compare_and_swap(0, 1):
        pass
    print("In critical section")
    atomic_lock.value = 0

Fetch-and-Add (FAA)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

from threading import Lock
ticket = 0
serving = 0
lock = Lock()

def fetch_and_add():
    global ticket
    with lock:
        val = ticket
        ticket += 1
        return val

def faa_lock():
    global serving
    my_ticket = fetch_and_add()
    while serving != my_ticket:
        pass
    print("In critical section")
    serving += 1

운영체제 기반

Semaphore

1
2
3
4
5
6
7
8

import threading

sem = threading.Semaphore(1)

def semaphore_section():
    sem.acquire()
    print("In critical section")
    sem.release()

Mutex

1
2
3
4
5

mutex = threading.Lock()

def mutex_section():
    with mutex:
        print("In critical section")

Monitor

1
2
3
4
5

monitor = threading.Condition()

def monitor_section():
    with monitor:
        print("In critical section")

분산 시스템 기반

Ricart-Agrawala Algorithm

🔽 실제 네트워크 시뮬레이션은 복잡하여 아래는 구조 개요 수준

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 단순 구조 시뮬레이션
class Process:
    def __init__(self, id, clock):
        self.id = id
        self.clock = clock
        self.request_queue = []

    def request(self):
        self.clock += 1
        print(f"Process {self.id} requests at {self.clock}")
        # send request to other nodes

    def receive_reply(self):
        # all replies received
        print(f"Process {self.id} enters critical section")

Suzuki-Kasami Token Algorithm

현대 기법

Spinlock

1
2
3
4
5
6
7
8
9

import threading

lock = threading.Lock()

def spinlock_section():
    while not lock.acquire(blocking=False):
        continue
    print("In critical section")
    lock.release()

Lock-Free Data Structure (Queue 예)

실제 구현은 concurrent.futures 또는 queue 라이브러리 기반

Distributed Lock Service (예: Redis, Zookeeper)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Redis 분산 락 예시 (Redis-py 필요)
import redis
import uuid

r = redis.Redis()
lock_key = "resource_lock"
lock_id = str(uuid.uuid4())

if r.set(lock_key, lock_id, nx=True, ex=5):
    print("Got distributed lock")
    r.delete(lock_key)

장점

1. 데이터 무결성과 일관성
   상호 배제의 가장 기본적이고 핵심적인 장점은 공유 자원의 동시 접근을 제어함으로써 데이터 무결성과 일관성을 확보하는 것이다. race condition 이나 inconsistent state 와 같은 오류가 방지되어 전체 시스템의 안정성이 확보된다.

2. 시스템 안전성 및 신뢰성
   상호 배제는 무한 대기, 데드락, 라이브락 등 복잡한 동시성 오류의 근본 원인을 차단하고, 시스템 전반의 결함 허용성과 신뢰성을 향상시킨다. 특히 임계 구역 진입이 잘 관리되면 전체 실행 흐름의 예측 가능성이 높아진다.

3. 성능 및 효율성
   구조에 따라 공정성 (Fairness) 을 보장하고, 메시지 수를 줄이며, 하드웨어 지원을 통해 동기화 속도를 높이는 것이 가능하다. 특히 락 경합이 심한 환경에서는 token 기반, CAS 기반 구조가 성능 면에서 유리하다.

4. 구조적 유연성
   상호 배제는 이론적으로나 실무적으로 매우 유연하게 설계할 수 있다. 운영체제 수준의 락부터, 하드웨어 기반 atomic 연산, 또는 분산 환경에서의 quorum/lease 기반까지 다양한 방식이 존재하며, 플랫폼과 언어에 무관하게 이식성이 높다.

단점과 문제점 그리고 해결방안

단점과 해결 방안

Mutual Exclusion 은 시스템의 동기화를 보장하지만 성능과 유지보수성 측면에서 다음과 같은 단점이 존재한다. Busy-wait 로 인한 CPU 낭비, 임계구역 범위 설정의 비효율성, 락으로 인한 병목 및 확장성 저하가 주된 문제다. 분산 환경에서는 메시지 지연, 네트워크 실패 시 처리 지연도 고려해야 한다. 이를 해결하기 위해선 락 최소화, 락 프리 구조, 고수준 추상화, 분산 락 프레임워크 등의 전략이 필요하다.

Busy Waiting

CPU 를 낭비하며 루프에서 락을 기다리는 방식으로, 리소스 효율이 낮고 시스템 전체 처리량 저하 발생.

코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

import threading

lock = threading.Lock()

def busy_wait_lock():
    while not lock.acquire(False):  # Non-blocking
        pass  # Busy spin (비효율적)
    try:
        print("Acquired lock")
    finally:
        lock.release()

시각화 흐름도:

sequenceDiagram
    participant Thread
    participant Lock

    loop 반복
        Thread->>Lock: Try Acquire (non-blocking)
        Lock-->>Thread: Denied
    end
    Note over Thread: Busy waiting 반복

장애 시나리오 기반 복구 설계:

• 일정 횟수 이상 busy loop 시 sleep 삽입
• spinlock → blocking lock 전환

복구 구현 예시:

1
2
3
4

import time

while not lock.acquire(False):
    time.sleep(0.001)  # Yield CPU

테스트 케이스:

로그 예시:

1
2

[Thread-A] Spinning on lock for 53ms
[LockOptimizer] Recommend switching to blocking lock

장애 감지 모듈:

1
2

if spin_duration > 50:  # ms
    logger.warn("Busy waiting too long")

성능 오버헤드

락 획득/해제 자체의 비용 (context switching, syscall 등) 으로 TPS 감소.

코드 예시:

1
2
3
4

def heavy_lock_work():
    for _ in range(100000):
        with lock:
            shared_counter[0] += 1

시각화 흐름도:

flowchart TD
    A[Thread] -->|Acquire Lock| L[Lock]
    L -->|Critical Section| C[Computation]
    C -->|Release Lock| L

복구 설계:

• 임계 구역 분리, 락 최소화
• CAS 또는 atomic 변수 사용

구현 예시:

1
2
3
4

from multiprocessing import Value

with counter.get_lock():  # 내부적으로 atomic
    counter.value += 1

테스트 케이스:

로그 예시:

1
2

[PerfMonitor] Lock-acquire overhead: 5.8µs avg
[PerfAlert] Lock contention increasing (QPS degradation 30%)

감지 모듈:

1
2

if avg_lock_time > THRESHOLD:
    alert("락 오버헤드 감지")

복잡성 증가

락이 많아질수록 코드 가독성 저하, 순환 락 구조 발생 가능성 증가.

코드 예시:

1
2
3
4
5

def update_state():
    with lock1:
        do_work()
        with lock2:
            do_other_work()

시각화 흐름도:

graph TD
    A[Function A] --> B[Lock1]
    B --> C[Function B]
    C --> D[Lock2]

복구 설계:

• 고수준 동기화 객체 도입 (예: queue, pool)
• 디자인 패턴 적용 (ex. Command, State)

구현 예시:

1
2

from queue import Queue
# Queue로 상태 전환을 비동기 처리

테스트 케이스:

로그 예시:

1
2

[LockGraph] Nested locks: 3 levels
[ComplexityWarning] Potential circular dependency

감지 모듈:

1
2
3

def detect_lock_nesting():
    if depth > MAX_ALLOWED:
        alert("락 중첩 과도함")

확장성 제한

단일 락 또는 전역 상태 공유로 인해 멀티 스레드 환경의 스케일링 저하.

코드 예시:

1
2
3
4
5
6
7

shared_count = 0

def increment():
    global shared_count
    for _ in range(10000):
        with lock:
            shared_count += 1

시각화 흐름도:

graph LR
    Thread1 --> L
    Thread2 --> L
    Thread3 --> L
    L --> CriticalSection

복구 설계:

• 락 세분화 또는 샤딩
• 쓰기/읽기 분리 (RWLock 등)

구현 예시:

1

from threading import RLock  # 또는 read/write lock 구현체

테스트 케이스:

로그 예시:

1
2

[ScalabilityAlert] Lock contention: 92%
[Recommendation] Apply lock partitioning strategy

감지 모듈:

1
2

if thread_waits / total_threads > 0.8:
    logger.warn("스레드 경합 과다")

네트워크 지연 (분산 락)

Redis, ZooKeeper 등 외부 락 관리자와의 통신 지연으로 전체 응답 지연 발생.

코드 예시:

1
2

# Redis 락 요청이 늦어지는 경우
lock_acquired = redis.set("lock", value, nx=True, ex=5)

시각화 흐름도:

sequenceDiagram
    participant App
    participant Redis

    App->>Redis: SETNX
    Redis-->>App: Delay…
    App-->>User: Request timeout

복구 설계:

• 타임아웃, 재시도, fallback
• local-fallback 또는 async 처리 도입

구현 예시:

1
2

if not redis.set(...):
    fallback_local_queue.put(task)

테스트 케이스:

로그 예시:

1
2

[LockTimeout] Redis lock request exceeded 200ms
[Failover] fallback to local queue

감지 모듈:

1
2

if redis_latency > 150:
    logger.warn("분산 락 응답 지연")

문제점과 해결 방안

Mutual Exclusion 은 잘못된 사용 또는 설계 시 여러 실행 상의 문제를 유발한다. 대표적으로는 Deadlock, Starvation, Livelock, Priority Inversion, Race Condition 등이 있으며, 이는 시스템 정지, 데이터 불일치, 성능 저하 등의 심각한 결과를 초래할 수 있다. 이러한 문제를 방지하려면 사전 예방 구조 설계, 락 순서 정의, 타임아웃 및 우선순위 정책 적용, 정기적인 락 상태 진단 도구 사용이 필요하며, 장애 복구를 위한 Recoverable Lock 설계와 백오프 전략도 함께 병행되어야 한다.
좋아. 아래는 Mutual Exclusion 에서 자주 발생하는 대표적인 문제점 5 가지에 대해 다음 요소들을 포함해 심화 정리한 자료야:

Deadlock (교착 상태)

두 개 이상의 스레드가 서로가 소유한 락을 기다리며 무한 대기 상태에 빠짐.

코드 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import threading

lock1 = threading.Lock()
lock2 = threading.Lock()

def thread_a():
    with lock1:
        print("Thread A acquired lock1")
        threading.Event().wait(0.1)
        with lock2:
            print("Thread A acquired lock2")

def thread_b():
    with lock2:
        print("Thread B acquired lock2")
        threading.Event().wait(0.1)
        with lock1:
            print("Thread B acquired lock1")

a = threading.Thread(target=thread_a)
b = threading.Thread(target=thread_b)
a.start()
b.start()

시각화 흐름도

sequenceDiagram
    participant A as Thread A
    participant B as Thread B
    participant L1 as Lock1
    participant L2 as Lock2

    A->>L1: Acquire Lock1
    B->>L2: Acquire Lock2
    A->>L2: Wait Lock2 (held by B)
    B->>L1: Wait Lock1 (held by A)
    Note over A,B: Deadlock 발생

장애 시나리오 기반 복구 설계:

• Deadlock 감지 로직 주기적 실행
• timeout 설정 후 강제 unlock 또는 watchdog thread 이용
• 락 획득 순서 정형화

복구 설계 구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

try:
    acquired1 = lock1.acquire(timeout=1)
    acquired2 = lock2.acquire(timeout=1)
    if acquired1 and acquired2:
        print("Work done.")
finally:
    if acquired1:
        lock1.release()
    if acquired2:
        lock2.release()

테스트 케이스 설계:

로그 패턴 예시:

1
2
3
4
5

[Thread-A] Acquired lock1
[Thread-B] Acquired lock2
[Thread-A] Waiting for lock2…
[Thread-B] Waiting for lock1…
[DeadlockDetector] Potential deadlock detected between Thread-A <-> Thread-B

장애 감지 모듈 설계:

• 주기적으로 락 대기 그래프 (Wait-for Graph) 를 수집
• 특정 임계 시간 이상 대기 상태인 스레드 탐지
• 대기 순환 (사이클) 탐지 시 경고 또는 recovery trigger

1
2
3

class DeadlockDetector:
    def detect(self, wait_graph):
        return self.has_cycle(wait_graph)

Starvation (기아 상태)

우선순위 높은 작업 또는 반복된 경합으로 인해 특정 스레드가 계속 락을 획득하지 못함.

코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

import threading
import time

lock = threading.Lock()

def high_priority():
    while True:
        with lock:
            print("High priority task running")
            time.sleep(0.1)

def low_priority():
    while True:
        if lock.acquire(timeout=0.01):
            print("Low priority task got chance!")
            lock.release()
        else:
            print("Low priority starving…")

threading.Thread(target=high_priority).start()
threading.Thread(target=low_priority).start()

시각화 흐름도

sequenceDiagram
    participant H as High Priority
    participant L as Low Priority
    participant Lock

    loop 반복 요청
        H->>Lock: Acquire
        Lock-->>H: Granted
        L->>Lock: Try Acquire
        Lock-->>L: Denied
    end
    Note over L: Low priority task starving

장애 시나리오 기반 복구 설계:

• Bounded waiting 보장 알고리즘 적용
• Lock queue 또는 FIFO 구조 도입

복구 설계 구현 예시:

• 공정한 락 큐

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

from threading import Lock
from queue import Queue

class FairLock:
    def __init__(self):
        self.queue = Queue()
        self.internal_lock = Lock()

    def acquire(self):
        entry = Lock()
        entry.acquire()
        self.queue.put(entry)
        if self.queue.qsize() == 1:
            entry.release()
        entry.acquire()

    def release(self):
        self.queue.get()
        if not self.queue.empty():
            self.queue.queue[0].release()

테스트 케이스 설계:

로그 패턴 예시:

1
2
3

[LowPriorityTask] Lock attempt failed (retry #17)
[LowPriorityTask] Lock attempt failed (retry #18)
[StarvationDetector] Task has not progressed in 2.5s, possible starvation

장애 감지 모듈 설계:

• 특정 태스크/스레드의 처리 latency, retry 횟수, queue backlog 분석
• 일정 임계값 초과 시 alert 발생

1
2

if retry_count > THRESHOLD and latency > MAX_WAIT:
    logger.warn(f"Starvation suspected on thread {thread_id}")

Livelock (라이브락)

서로 양보하려는 로직이 진전을 만들지 못하고 계속 상태 전이만 반복함.

코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import threading

flag1 = False
flag2 = False

def thread1():
    global flag1, flag2
    while True:
        if not flag2:
            flag1 = True
            print("Thread1 working")
            break

def thread2():
    global flag1, flag2
    while True:
        if not flag1:
            flag2 = True
            print("Thread2 working")
            break

t1 = threading.Thread(target=thread1)
t2 = threading.Thread(target=thread2)
t1.start()
t2.start()

시각화 흐름도:

sequenceDiagram
    participant T1 as Thread 1
    participant T2 as Thread 2

    loop 양보 반복
        T1->>T2: Are you done?
        T2->>T1: Not yet, you go
        T1->>T2: No you go
    end
    Note over T1,T2: 계속 반복됨 (Livelock)

장애 시나리오 기반 복구 설계:

• 백오프 전략 (Random delay)
• Retry 횟수 제한 후 fallback 처리

복구 설계 구현 예시:

1
2
3
4
5
6
7
8
9

import random, time

def retry_with_backoff(task, max_attempts=5):
    for i in range(max_attempts):
        success = task()
        if success:
            return True
        time.sleep(random.uniform(0.01, 0.1 * (i+1)))
    return False

테스트 케이스 설계:

로그 패턴 예시:

1
2
3
4
5

[Thread1] Waiting for Thread2 to release
[Thread2] Waiting for Thread1 to release
[Thread1] Retrying…
[Thread2] Retrying…
[LivelockDetector] Live cycle detected, thread pair T1 <-> T2 not making progress

장애 감지 모듈 설계:

• 상태 전이 없음, 반복 동작만 지속되는 패턴 탐지
• 백오프 카운터 증가 패턴 추적

1
2

if state_change == 0 and retry_count > LIMIT:
    logger.warn("Possible livelock detected")

Priority Inversion (우선순위 역전)

낮은 우선순위 스레드가 락을 보유하고, 높은 우선순위 스레드가 기다리는 상황 발생.

코드 예시: (개념적 시뮬레이션)

1
2
3
4

# 실제 우선순위 조절은 Python에서는 불가하지만 개념 표현 가능
print("Low Priority Task acquired lock")
print("High Priority Task waiting on lock…")
print("Medium Priority Task keeps CPU busy (no I/O)")

시각화 흐름도:

sequenceDiagram
    participant L as Low Priority
    participant H as High Priority
    participant M as Medium Priority

    L->>Lock: Acquire
    H->>Lock: Wait (Blocked)
    M->>CPU: Occupy (CPU-bound)
    Note over H: 응답 지연 (Inversion 발생)

장애 시나리오 기반 복구 설계:

• Priority Inheritance 또는 Ceiling Protocol 사용

테스트 케이스 설계:

로그 패턴 예시:

1
2
3
4

[HighPriorityTask] Waiting for lock (held by LowPriorityTask)
[LowPriorityTask] Executing…
[MediumPriorityTask] Executing…
[PriorityInversionDetector] Inversion detected: HighPriority blocked by LowPriority

장애 감지 모듈 설계:

• 태스크 우선순위/상태 추적
• 높은 우선순위 태스크가 비정상적으로 대기하는 경우 알림

1
2

if high_priority_task.state == "waiting" and low_priority_task.holding_lock:
    logger.warn("Priority Inversion Detected")

Crash During Lock

락을 소유한 프로세스가 임계 구역 도중 다운되어 락이 풀리지 않음.

코드 예시: Redis 기반

1
2
3

client.set("lock", "uuid", nx=True, ex=10)
# 작업 도중 crash
# 락이 풀리지 않으면 후속 작업 차단

시각화 흐름도:

sequenceDiagram
    participant C1 as Client 1
    participant Redis
    participant C2 as Client 2

    C1->>Redis: SETNX lock_key
    Redis-->>C1: OK
    C1->>Redis: 작업 중 (Crash 발생)
    C2->>Redis: SETNX lock_key
    Redis-->>C2: Denied (Lock not expired)

장애 시나리오 기반 복구 설계:

• TTL 설정 (ex 옵션)
• 락 소유자 검증 후 release (fencing token 활용)

복구 설계 구현 예시: Redis + fencing

1
2

if redis.get("lock") == my_token:
    redis.delete("lock")

테스트 케이스 설계:

로그 패턴 예시:

1
2
3
4

[ClientA] Acquired lock (token=uuid123)
[ClientA] Process crashed
[ClientB] Lock acquisition failed - lock already held
[LockMonitor] Lock held beyond TTL - suspect owner failure

장애 감지 모듈 설계:

• TTL 기반 분산 락을 사용하고, 만료 시 강제 해제
• fencing token 과 락 소유자 검증 포함

1
2
3

if current_time - lock_acquired_time > TTL:
    logger.warn("Lock timeout detected, assuming crash")
    redis.delete(lock_key)

도전 과제

1. 동기화 안정성
   기본적인 동기화 오류 (데드락, 기아 상태, 우선순위 역전, 라이브락) 는 프로그래밍 오류가 아니라 구조적 설계 실패에서 비롯되며, 공정성 (Fairness), 자원 획득 순서 고정, 우선순위 상속 등 구조 기반 해결 전략이 필수다.

2. 성능 및 확장성
   락 경합, 메모리 일관성, NUMA 이슈 등은 멀티코어/멀티스레드 환경에서 동시성의 병목 지점이다. 이를 해결하기 위해선 락을 최소화하는 동시에, CPU 캐시 및 메모리 모델까지 고려한 저수준 최적화 기법이 필요하다.

3. 분산 시스템 대응
   단일 머신에서는 문제가 없던 상호배제가 분산 시스템에서는 네트워크 분리, 장애 복구, 일관성 보장 문제로 복잡성이 급증한다. fencing token, quorum 구성, failover 로직, 장애 감지 프로토콜이 핵심이다.

4. 동시성 보장 기술
   Lock-Free / Wait-Free 기법은 경합 최소화, throughput 극대화에 필수적이며 특히 실시간 처리나 고성능 시스템에서 점점 필수로 여겨진다. 비동기 환경에서도 Fairness 를 보장하기 위한 논블로킹 알고리즘의 안정성 확보가 연구되고 있다.

Crash-Recovery 환경 대응

Crash-Recovery 대응 Redlock 구조

sequenceDiagram
    participant App
    participant Redis1
    participant Redis2
    participant Redis3

    App->>Redis1: SET resource_key <token> NX PX 3000
    App->>Redis2: SET resource_key <token> NX PX 3000
    App->>Redis3: SET resource_key <token> NX PX 3000

    Note right of App: majority 성공 시 lock 획득

    App-->>Redis1: periodic lock renewal
    App-->>Redis2: periodic lock renewal
    App-->>Redis3: periodic lock renewal

    App->>Redis1: DEL if token matches
    App->>Redis2: DEL if token matches
    App->>Redis3: DEL if token matches

    Note over App: 장애 시 fencing token으로 중복 방지

• 핵심 요소:
  • NX PX: 존재하지 않으면 설정 + TTL
  • token: 고유 식별자 (fencing token 역할)
  • majority: 락 획득 조건
  • renew: TTL 갱신
  • DEL: 종료 후 자원 해제

성능 비교표: Crash-Recovery 고려 시 동기화 기법 비교

코드 예시

• Python: Redis 기반 Fencing Token 분산락 (Crash-Recovery 대응)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

import redis
import uuid
import time

class RedisLockWithToken:
    def __init__(self, redis_client, key, ttl=3000):
        self.redis = redis_client
        self.key = key
        self.ttl = ttl
        self.token = str(uuid.uuid4())  # fencing token
        self.fence_counter_key = f"{key}:fence"

    def acquire(self):
        result = self.redis.set(self.key, self.token, nx=True, px=self.ttl)
        if result:
            # fence 번호 증가
            self.redis.incr(self.fence_counter_key)
            self.fence_id = self.redis.get(self.fence_counter_key)
            return True
        return False

    def release(self):
        script = """
        if redis.call("get", KEYS[1]) == ARGV[1] then
            return redis.call("del", KEYS[1])
        else
            return 0
        end
        """
        return self.redis.eval(script, 1, self.key, self.token)

# 사용 예시
r = redis.Redis(host='localhost', port=6379)
lock = RedisLockWithToken(r, "job:process", ttl=3000)

if lock.acquire():
    try:
        print(f"Lock acquired with fence ID: {lock.fence_id}")
        time.sleep(2)  # 작업 처리
    finally:
        lock.release()
else:
    print("Lock acquisition failed")

• 특징:
  • uuid 기반 token → fencing token 역할
  • TTL 설정 → 장애 시 자동 만료
  • eval → 안전한 락 해제
  • fence_id → 중복 방지 및 순서 보장

실무 적용 시나리오: Crash-Recovery 대응 락 사용 예

분류 기준에 따른 종류 및 유형

1. 구현 방식
   상호 배제는 크게 소프트웨어 알고리즘, 하드웨어 명령어, 운영체제/언어 지원 동기화 객체로 나뉜다. 소프트웨어 기반은 학습용에 적합하고, 하드웨어 기반은 성능 최적화에 활용되며, 운영체제 기반은 실무 시스템의 안정성과 범용성을 책임진다.

2. 프로세스 수 기준
   Peterson 은 2- 프로세스 전용이고, Bakery 알고리즘은 N- 프로세스를 지원한다. 이진/다중 구조에 따라 알고리즘 선택이 달라진다.

3. 메모리 및 메시지 모델
   로컬 시스템은 shared-memory 기반 알고리즘이 적합하며, 분산 시스템은 메시지 기반 동기화 모델이 요구된다. 특히, 메시지 방식은 Permission-based, Token-based, Quorum-based 로 나뉜다.

4. 적용 환경
   단일 머신은 일반적인 Mutex, Monitor, Semaphore 로 충분하지만, 분산 환경에서는 장애 허용성과 일관성 유지를 위한 더 복잡한 동기화 구조 (Redlock, ZooKeeper) 가 필요하다.

5. 특별 구조 및 상황별 설계
   Recoverable Mutex 는 장애 이후에도 복구 가능한 환경에 적합하고, K-Mutual Exclusion 은 다수의 동시 진입을 허용해야 할 때 고려한다.

6. 운영 수준과 진입 정책
   동기화 객체는 사용자 공간에서 구현하거나, 커널 공간에서 운영체제 API 를 호출하여 사용할 수 있다. 또한, 선점/비선점 스케줄링 여부에 따라 응답성과 공정성이 좌우된다.

7. 고급 구조
   락프리/논블로킹 구조는 성능과 확장성 요구가 큰 환경에서 주로 사용된다. CAS, STM, FAA 기반 구조는 병목과 컨텍스트 스위칭 비용을 줄이기 위한 효과적인 대안이다.

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

• 설계 측면
  락의 최소화, 재진입성 확보, 자원 식별의 명확화가 중요하다. 임계 영역을 불필요하게 넓게 설정하거나 명확하지 않은 자원 보호는 시스템 병목이나 동기화 오류의 주된 원인이 되므로, 세밀한 락 제어 및 책임 분리가 필요하다.

성능 측면
락 경합 최소화, 불필요한 동기화 제거, 하드웨어 메모리 모델 이해가 핵심이다. 멀티스레드/멀티코어 환경에서는 락 경합이 심한 코드 패스에 대한 리팩토링과 병렬성 확보가 요구되며, 필요에 따라 락 프리 알고리즘 또는 원자 연산으로의 전환도 고려되어야 한다.

안정성 측면
데드락·기아 방지, 예외 상황 대응, 우선순위 역전 처리가 핵심이다. 특히 복합 락 구조에서는 획득 순서 보장 및 타임아웃 전략을 반드시 적용해야 하며, 예외 발생 시 자원 회수 로직도 필수이다.

분산 환경
메시지 기반 통신 지연·실패에 대비한 복구 메커니즘 및 분산 락 관리자 도입이 필요하다. 장애 상황에서도 상태 일관성을 유지할 수 있도록 Recoverable Lock 및 Fencing Token 설계가 중요하다.

테스트 및 분석 관점
Race Detector, Stress 테스트 도구 활용이 반드시 필요하며, 실시간 운영 시스템에서는 락 관련 로그와 병목 추적 도구를 통한 지속적 진단 체계도 함께 구성해야 한다.

좋아. Mutual Exclusion 을 실무에서 효과적으로 적용하기 위한 고려사항 중 대표적인 항목에 대해 Python과 Java를 기준으로 실용적인 코드 예시를 아래에 구성할게. 각 항목별로 간단한 시나리오와 함께 문제 상황 + 해결 방식을 보여줄 거야.

락 범위 최소화

나쁜 예:

• 락을 너무 넓게 사용

1
2
3
4
5
6
7
8
9

import threading

lock = threading.Lock()

def update_shared_data():
    with lock:
        # 불필요한 작업까지 락을 보유
        do_io_heavy_task()
        shared_resource['count'] += 1

좋은 예:

• 임계구역 최소화

1
2
3
4
5
6
7
8
9

import threading

lock = threading.Lock()
shared_resource = {'count': 0}

def update_shared_data():
    do_io_heavy_task()  # 락 없이 처리 가능
    with lock:
        shared_resource['count'] += 1  # 최소한의 영역만 보호

Deadlock 방지

• 락 순서 고정

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

import threading

lock_a = threading.Lock()
lock_b = threading.Lock()

def thread1():
    with lock_a:
        with lock_b:  # 항상 A → B 순서
            print("Thread 1 finished")

def thread2():
    with lock_a:
        with lock_b:  # 동일 순서로 락 획득
            print("Thread 2 finished")

• 두 스레드 모두 A → B 순서로 락을 획득하므로 데드락 발생을 방지할 수 있다.

ReentrantLock 사용

• Java

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

import java.util.concurrent.locks.ReentrantLock;

public class Counter {
    private final ReentrantLock lock = new ReentrantLock();
    private int count = 0;

    public void increment() {
        lock.lock();
        try {
            count++;
            // 재진입 가능한 코드
            logCount();
        } finally {
            lock.unlock();
        }
    }

    private void logCount() {
        lock.lock();
        try {
            System.out.println("Count = " + count);
        } finally {
            lock.unlock();
        }
    }
}

• 동일한 스레드가 동일 락을 다시 획득할 수 있는 구조를 ReentrantLock 이 보장.

락 Timeout 설정

• Python

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

import threading

lock = threading.Lock()

def try_acquire_with_timeout():
    got_lock = lock.acquire(timeout=2)
    if got_lock:
        try:
            print("Lock acquired")
        finally:
            lock.release()
    else:
        print("Failed to acquire lock in time")

락 오버헤드 제거

• CAS 기반 원자 연산
• Python 의 multiprocessing.Value

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

from multiprocessing import Value
from multiprocessing import Process

counter = Value('i', 0)

def increment(counter):
    for _ in range(100000):
        with counter.get_lock():  # 내부적으로 atomic
            counter.value += 1

if __name__ == '__main__':
    p1 = Process(target=increment, args=(counter,))
    p2 = Process(target=increment, args=(counter,))
    p1.start()
    p2.start()
    p1.join()
    p2.join()
    print("Final count:", counter.value)

분산 락 예시

• Redis Redlock (Python + Redis)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

import redis
import time
import uuid

client = redis.Redis()
lock_key = "my-distributed-lock"
lock_value = str(uuid.uuid4())

# 락 획득 (5초 동안 유효)
is_locked = client.set(lock_key, lock_value, nx=True, ex=5)

if is_locked:
    try:
        print("Lock acquired - doing critical work")
        time.sleep(2)
    finally:
        if client.get(lock_key).decode() == lock_value:
            client.delete(lock_key)
else:
    print("Lock already held by another process")

• Redlock 알고리즘 기반으로 확장 가능하며, 멀티 Redis 인스턴스에서의 분산 락 보장.

Race Condition 감지 테스트

• Python threading

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

import threading

count = 0

def race_increment():
    global count
    for _ in range(100000):
        count += 1  # 경쟁 조건 발생 가능

threads = [threading.Thread(target=race_increment) for _ in range(4)]
for t in threads:
    t.start()
for t in threads:
    t.join()

print("Expected 400000, Actual:", count)

• 이 코드는 race condition 이 발생할 수 있고, 도구 없이도 재현 실험 가능함.

테스트 시 락 병목 분석

• Linux perf lock 활용

1
2

sudo perf lock record ./your_program
sudo perf lock report

• 실시간으로 락 대기 시간과 경합 통계를 보여주는 도구. 락 병목 식별에 유용.

실무 환경/아키텍처 기반 Mutual Exclusion 적용 전략

실시간 시스템에서의 상호 배제

실시간 (Real-Time) 시스템에서 과도한 대기나 블로킹은 치명적일 수 있으므로, 타임아웃, 우선순위 반전 (Priority Inversion) 해결 기법 등 별도 정책 적용이 필수다.

분산 환경에서의 상호 배제 구조

flowchart LR
    subgraph Cluster1
        A1[App1]
        A2[App2]
    end
    subgraph Cluster2
        B1[App3]
        B2[App4]
    end
    Redis[Redis/Etcd/Zookeeper분산 락 서비스]
    DB[공유 DB/파일시스템]
    A1 --락 요청/해제--> Redis
    A2 --락 요청/해제--> Redis
    B1 --락 요청/해제--> Redis
    B2 --락 요청/해제--> Redis
    Redis --락 허용/거부--> A1
    Redis --락 허용/거부--> B2
    A1 --임계구역 작업--> DB
    B2 --임계구역 작업--> DB

여러 애플리케이션 인스턴스가 동일 분산 락 서비스를 통해 락의 소유권을 조정하며, 락 획득 시에만 공유 자원 (DB) 에 접근합니다. 네트워크 장애 등 극한 상황 대비가 중요하다.

컨테이너 기반 환경 (Kubernetes, Docker 등)

보완 포인트:

• Sidecar 또는 Init Container 를 통해 락 획득/해제 책임을 분리하는 구조도 효과적
• Redlock(Redis 기반 분산 락 알고리즘) 또는 ZAB(ZooKeeper Atomic Broadcast) 와 같은 다중 인스턴스 락 보장 알고리즘 사용 필요

MSA (Microservices Architecture) 기반 시스템

보완 포인트:

• 분산 트랜잭션 (DB 락) 이 아닌 Application Level 락 또는 Outbox 패턴 + 락 으로 접근
• Kafka 등 사용 시 Partition 기반 순서 보장을 함께 고려하여 상호 배제 간섭 최소화

Serverless & Event-driven Architecture

보완 포인트:

• Step Functions, Durable Functions 등 stateful workflow 시스템 내에서 자동 상호 배제 제어 가능
• 락보다는 큐와 상태머신 조합 + TTL 기반 처리가 확장성과 비용 측면에서 효과적일 수 있음

코드 레벨 구현 패턴

보완 포인트:

• 락 분할 (Split Lock), 읽기/쓰기 락 (Read/Write Lock) 등 락 범위를 논리적으로 최소화하는 리팩토링 패턴 적용
• 실시간 처리 필요 시, 락 대기 없는 optimistic lock 구조도 고려해야 함

참고할 수 있는 실전 코드 패턴 (Python 기반)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

import redis
import uuid
import time

r = redis.StrictRedis(host='localhost', port=6379, db=0)

def acquire_distributed_lock(lock_name, ttl=10):
    token = str(uuid.uuid4()) # 고유 토큰
    while True:
        # setnx + expire = set(key, value, nx, ex)
        if r.set(lock_name, token, nx=True, ex=ttl):
            return token
        time.sleep(0.05) # 짧은 대기 후 재시도

def release_distributed_lock(lock_name, token):
    # Lua script로 원자적으로만 해제!
    script = """
    if redis.call('get', KEYS[1]) == ARGV[1]
    then
        return redis.call('del', KEYS[1])
    else
        return 0
    end
    """
    r.eval(script, 1, lock_name, token)

lock = acquire_distributed_lock("mykey", ttl=5)
try:
    # 임계구역(critical section)
    print("임계구역 실행 중")
finally:
    release_distributed_lock("mykey", lock)

락 소유권 검증, TTL, 네트워크 메시지의 원자성 보장을 위해 Lua 스크립트를 활용.

최적화 위한 고려사항 및 주의사항