컴퓨터 시스템 내에서의 데이터 접근 패턴
- 데이터가 저장된 위치(Storage Box)에서 데이터를 읽어옴
- 읽어온 데이터를 이용하여 연산 (Execution Box에서 진행)
- 연산결과를 다시 원래 위치에 저장
ex) CPU - Memory의 관계; 컴퓨터 내부 - 디스크의 관계; 프로세스 - 프로세스가 관리하는 메모리 주소공간의 관계 등
Process Synchronization Problem
- 여럿이서 동시에 접근하려고 해서 시간적으로 잘 맞아떨어지지 않을 때 생기는 문제
- 공유데이터에 동시에 접근하려고 하는 상황에서 발생할 수 있는 데이터 불일치 문제(inconsistency)
- 일관성 유지를 위해서는 협력 프로세스(=공유데이터에 접근하는 프로세스) 간의 실행 순서를 정해주는 메커니즘 필요
Race Condition
: 여러 주체가 하나의 데이터를 동시에 접근하려고 하는 상황
- 하나의 storage box를 여러 execution box가 공유한다고 할 때, 누가 먼저 읽어갔느냐에 따라 결과가 달라질 수 있음 → synchronization problem
- 하나의 주체가 데이터를 읽어간 동안에 다른 주체가 또 데이터를 읽어가면, 원치 않은 결과가 발생할 수 있음 ⇒ 조율 필요
- ex) CPU가 여러 개 있는 Multiprocessor system에서는 메모리 공유하는 경우; 프로세스들이 공유 메모리를 사용하는 경우; system call 시 OS 커널의 데이터에 접근하게 되는데, 접근 중에 CPU를 뺏겨서 다른 프로세스에 CPU가 넘어갔는데, 해당 프로세스가 다시 커널의 데이터에 접근하는 경우; 커널의 코드가 실행 중일 때 인터럽트가 들어올 경우
- 즉, 유저 레벨에서는 큰 문제가 생기지 않던 것이 커널 레벨로 들어갈 경우, 이것이 공유데이터이므로 문제가 발생하게 됨
- race condition을 막기 위해서는concurrent process는 syncronization되어야 함
- 단순히 context switch가 일어난다고 해서 발생하는 문제는 아니며, 대부분의 경우 정상 작동함
- 프로세스들이 shared memory를 쓰고 있고, 먼저 실행되던 프로세스의 kernel mode 실행 중 context switch가 일어나고, 새로 실행되는 프로세스가 하필 그 데이터에 접근하는 등..의 경우에 문제 발생
OS에서 Rase condition이 발생하는 경우
1. kernel 수행 중 인터럽트 발생 시
- 커널이 CPU에서 실행 중에 count++ 명령 실행
- 이를 위해 3개의 instruction 실행
- load (메모리에 있는 변수값을 CPU register로 읽어들인다)
- Inc (register의 값을 1 증가시킨다)
- Store (register의 값을 메모리의 변수 위치에 쓴다)
- [문제상황] 변수를 CPU로 읽어들인 상태에서(=load가 끝난 이후에) interrupt가 들어왔을 경우, count++ 작업을 잠시 멈추고 interrupt 처리 루틴으로 넘어감
- interrupt handler도 kernel의 코드임
- interrupt handler 처리 중 kernel의 변수에서 count—를 할 수 있음
- 해당 작업이 완료되면 kernel 실행 상태로 돌아옴
- inc, store를 실행할 것
- 정상 실행되었다면 count는 원래 값과 동일해야 하는데, 문제상황에서는 count가 원래 값보다 1 큼
- [원인] kernel mode도, interrupt handler도 모두 kernel 코드이므로 kernel address space를 공유함
- [해결] 중요한 변수값을 건드리는 동안에는, interrupt가 들어와도 interrupt 처리 루틴으로 넘기지 않고 해당 작업이 끝날 때까지 interrupt 처리를 미룸
2. Process가 system call을 하여 kernel mode로 수행 중인데 context switch가 일어나는 경우
- [문제상황] Program A가 CPU를 사용하다가, 할당 시간이 끝나서 Program B로 넘어가고, 다시 할당 시간이 끝나서 Program A가 CPU를 받게 되는 상황
- 할당 시간이 끝난 시점이 user mode일 때면 상관이 없는데, 문제상황의 경우 A가 system call을 해서 kernel mode로 프로그램이 실행중이었음
- B가 다시 system call에서 count 변수를 건드리면 문제 발생
- 정상적인 상황이었다면 count는 2가 증가해야 하는데, 문제 상황에서는 count가 1 증가함
- [원인]
- 동일
- [해결]
- 프로세스가 kernel mode에 있을 때는 할당 시간이 끝나도 CPU를 뺏기지 않도록 설정
- kernel mode가 끝나고 user mode에 진입할 때 CPU를 빼앗는 방식
- 정확한 시간이 지켜지지는 않음
- time-sharing system은 real time system이 아니기 때문에 조금 시간이 더 갔다고 해서 큰 문제가 발생하지는 않음
3. Multiprocessor에서 shared memory 내의 kernel data
- CPU가 여러 개 있는 환경에서는 위 2개의 방식으로 해결되지 않음
- [원인] 근본적으로 작업 주체가 여러 개임
- [해결1] 데이터에 접근할 때 데이터에 lock을 거는 방식
- 한 CPU가 데이터를 들고 갈 때, 해당 데이터에 대해 lock을 걸고 데이터를 변경, 변경이 완료되면 unlock하는 방식
- [해결2] 한번에 하나의 CPU만 커널에 들어갈 수 있게 하는 방법
- =커널 전체를 하나의 lock으로 막고, 커널을 빠져나올 때 lock을 풀어주는 방식
- 이 방식의 경우 CPU가 여러 개 있더라도, 매 순간 커널에 접근할 수 있는 CPU는 하나 뿐 ⇒ 비효율적
참고 링크
개발 취준생