데이터를 읽어와서 연산 하고 저장할 때, 누가 먼저 연산하냐에 따라 결과가 달라질 수 도 있다.
- 공유 데이터(shared data)의 동시 접근(concurrent access)은 데이터의 불일치 문제(inconsistency)를 발생시킬 수 있다.
- 일관성(consistency) 유지를 위해서는 협력 프로세스(cooperationg process) 간의 실행순서(orderly execution)을 정해주는 매커니즘 필요!
Race Condition
: 여러 프로세스나 스레드가 공유된 자원에 동시에 접근하고 수정을 시도할 때, 마치 경쟁하듯
- 데이터의 최종 연산 결과는 마지막에 그 데이터를 다룬 프로세스에 따라 달라짐
=> 동기화되지 않은 동시 접근으로 인해 예측할 수 없는 결과 발생 가능
=> race condition을 막기 위해는 concurrent process는 동기화(synchronize)되어야 한다.
Race Condition 이 발생하는 상황
- 커널 수행 중 인터럽트 발생 시
: 운영체제는 인터럽트를 처리하기 위해 현재 작업 중단하고 인터럽트 서비스 루틴(인터럽트가 발생했을 때 실행되는 코드 블록 또는 함수)으로 제어 이동
예) 인터럽트 서비스 루틴이 공유 변수를 수정하는 도중 현재 실행 중인 작업이 해당 변수를 사용하려고 할 때, 예기치 않은 동작이 발생 가능
인터럽트 핸들러는 공유 변수인 count를 감소시키지만, 이는 커널의 실행 흐름에 영향을 주지 않는다.
인터럽트가 끝난 이후 커널은 연산을 이어서 진행함. 커널은 이전 연산 과정인 load 이후부터 다시 연산을 수행, 이때 count 변수는 감소하지 않은 상태로 유지
결과적으로, count 변수는 기존 값에서 1이 증가된 수치가 됨 => 중요한 변수의 값을 건드리는 동안에는 인터럽트가 발생해도 해당 연산이 끝나고 수행되도록 인터럽트를 비활성화시키는 것이 중요한 이유
해결 방법) 인터럽트가 발생해도 연산이 끝나고 수행될 수 있게끔 disable
- 프로세스가 시스템 콜을 호출하여 커널 모드로 수행 중인 가운데 context switch가 일어나는 경우
: 예) 프로세스 A와 프로세스 B가 동시에 공유 변수를 수정하려고 하는데, context switch가 발생하여 A가 중단되고 B가 실행되는 경우 A,B 동시에 변수에 접근하면 예기치 않은 결과가 발생 가능
결과적으로 count 변수의 증가 값은 2가 되어야 할 것 같지만, count 변수가 1만 증가 ->
A 프로세스는 context switch 이전에 이미 load된 count 변수의 이전 값을 가지고 있음, B 프로세스에서 count를 증가시킨 결과는 A 프로세스에 반영되지 않은 상태. 따라서 A 프로세스는 이전 값을 가지고 있는 상태에서 count 변수를 증가시키게 되어 결과적으로 count 변수는 +1만 증가
해결방법) 커널 모드에서 수행 중일 때는 CPU 할당 시간이 끝나도 선점하지 않고, 사용자 모드로 돌아갔을 때 선점한다.
- 멀티 프로세서에서 공유 메모리 내의 커널 데이터
: 각 프로세서가 공유 메모리를 사용하여 데이터에 접근할 수 있음 -> 만약 두 개 이상의 프로세서가 공유 메모리 내의 커널 데이터를 동시에 수정하려고 할 때
예) 프로세서 A와 프로세서 B가 동시에 공유 메모리 내의 커널 데이터를 수정하려고 할 때
보통은 context switch 한다고 무조건 문제가 생기지 않음. shared memory 이거나 커널에 있는 데이터를 건드리면 문제가 생기는 것. 단순히 process 1 ⇒ 2로 간다고 해서 문제가 생기는 것은 아니다.
The Critical-Section Problem
임계 구역(critical section): 공유 데이터에 대한 접근이 필요한 코드 영역
여러 프로세스가 동시에 임계 구역에 진입하여 공유 데이터를 접근하면 문제가 발생할 수 있으므로, 상호 배제(mutual exclusion)가 필요
[이화여자대학교 반효경 교수님 운영체제 강의를 정리한 내용입니다.]
