Race Condition

둘 이상의 스레드 또는 프로세스가 동시에 공유자원에 접근하면서 실행 순서에 따라 결과가 달라지는 상황입니다.
→ 누가 먼저 실행되느냐에 따라 프로그램의 결과가 달라지고, 때로는 비정상적이나 예기치 못한 오류가 발생할 수 있습니다.

왜 생기나요?

• 공유 자원을 여러 스레드가 동기화 없이 동시에 접근할 때 발생합니다.
  (특히 읽기-쓰기, 쓰기-쓰기 접근에서 위험합니다.)

예제로 분석하기

int balance = 0;

void deposit() {
  balance += 100;
}

void withdraw() {
  balance -= 100;
}

두 스레드가 동시에 deposit() 과 withdraw() 를 실행한다면, balance 를 load 하고 값을 바꾸고 다시 store 하는 과정이 겹치면서 실행 시점에 따라 balance 값이 엉뚱하게 될 수 있습니다.

순서	동작	balance 값
A1	deposit: balance = 0 (load)	0
B1	withdraw: balance = 0 (load)	0
A2	deposit: balance = 0 + 100 → store	100
B2	withdraw: balance = 0 - 100 → store	-100 ❌

→ 원래는 +100과 -100 이 동시에 일어나서 0이 돼야 정상이지만, 순서에 따라 결과가 -100이 될 수 있습니다.

해결 방법 (동기화)

임계 구역을 보호하므로써 Race condition을 방지할 수 있습니다. 그러한 동기화 도구에는 전에 배운 방식들이 있습니다.

동기화 도구: 세마포어, Mutex, Moniter

PintOS에서

Project 1에서 thread.c의 ready_list 같은 공유 자료구조에 동기화 없이 접근하면 Race Condition이 발생합니다.

// 두 개의 스레드가 동시에 ready_list에 thread를 삽입한다면?
list_push_back(&ready_list, &t->elem);  // 보호하지 않으면 Race 발생 가능

→ 해당 코드는 반드시 thread_set_priority, thread_unblock 등과 같이 Lock으로 감싸야 안전합니다.

요약

항목	설명
정의	실행 순서에 따라 결과가 달라지는 비결정적인 상태
원인	동기화 없이 공유 자원에 여러 스레드가 동시에 접근
결과	버그, 잘못된 데이터, 예외, 프로그램 충돌 등
해결책	락, 세마포어, 조건 변수로 임계 구역 보호
Pintos 관련	ready_list, load_avg, recent_cpu 등은 항상 동기화 필요