[TIL 프로젝트] 5일차 - 멀티쓰레드에서 생기는 문제, 경쟁 조건(Race Condition)

1. 경쟁조건이란?

두 개 이상의 쓰레드가 공유 자원(예: 변수, 리스트 등)에 동시에 접근하려 할 때, 실행 순서에 따라 결과가 달라지는 문제

예시

int counter = 0;

Thread t1 = new Thread(()=> {
	for(int i=0; i<1000; i++) counter++;
});

Thread t2 = new Thread(()=> {
	for(int i=0; i<1000; i++) counter++;
});

t1.Start();
t2.Start();

기대값은 2000이지만, 실제로는 1500 ~ 2000 사이의 값이 나올 수도 있음
원자적(atomic) 연산이 아니기 때문

원자적(atomic) 연산이란?

하나의 연산이 “더 이상 쪼갤 수 없는 단위”로 수행되는 것
- 실행 중 다른 쓰레드가 끼어들 수 없고,
- 반드시 전부 성공하거나, 전부 실패함. 중간 상태가 없음
즉, “한 번에 딱 처리된다” 라고 생각하면 됨

왜 counter++는 원자적이지 않은가?

counter++는 3단계로 나뉘는 연산임
1. counter 값을 읽음 (read)
2. 값에 1을 더함 (add)
3. 결과를 다시 저장함 (write)
-> 이 중간에 다른 쓰레드가 counter 값을 바꿔버릴 수 있음
-> 그래서 멀티쓰레드 환경에선 의도한 값이 나오지 않을 수 있음

2. 크리티컬 섹션(Critical Section)

정의
경쟁 조건이 발생할 수 있는 코드 블럭
-> 반드시 하나의 쓰레드만 실행해야 안전함

3. 동기화 기법들

3-1. Mutex (Mutual Exclusion)

- 프로세스 간 또는 쓰레드 간 락을 걸기 위한 방식
- 한 번에 하나의 쓰레드만 뮤텍스를 소유 가능

3-2. Monitor / lock (C#에서 가장 흔함)

- 내부적으로는 Monitor.Enter/Exit 기반
- lock은 쓰기 편하고 스코프 기반 해제가 보장돼서 안전함

class Counter
{
    private int _count = 0;
    private readonly object _lock = new object();

    public void Increment()
    {
        lock (_lock)
        {
            _count++;
        }
    }

    public int GetValue()
    {
        lock (_lock)
        {
            return _count;
        }
    }
}

3-3. Semaphore

- 뮤텍스는 한 번에 1개 쓰레드만 들어올 수 있지만,
- 세마포어는 동시 허용 수 제한이 있음 (예: 동시에 3개까지 진입 허용)

3-4. SpinLock

- Lock을 걸 때, 스레드가 대기 상태로 멈추는 대신 계속 루프를 돌면서 확인하는 방식
- CPU 낭비가 있지만, 짧은 락 구간에서 빠른 반응성이 있음

4. 데드락(Deadlock)이란?

두 개 이상의 쓰레드가 서로 상대방의 락을 기다리는 상태에서 빠져나오지 못하는 문제

예시
- Thread A가 Lock1을 잡고 Lock2를 기다리고,
- Thread B가 Lock2를 잡고 Lock1을 기다리는 경우 -> 둘 다 멈춤

예방 방법:
- 항상 락을 고정된 순서로 획득
- 타임아웃 설정으로 탈출 가능하게 설계

5. Unity에서는?

Unity는 메인 스레드 중심 구조이지만,
- Job System + Burst를 쓰거나
- Task, ThreadPool, BackgroundWorker 등을 사용할 때는 경쟁 조건 주의 필요
Unity의 NativeArray는 스레드 안정하지 않음 -> NativeQueue 같은 구졸를 사용하거나 Job System 내에서만 접근해야 함