헷갈리는 개념 - Mode Switch부터 Interrupt까지

← 08. 비용과 성능 - 왜 너무 자주 바꾸면 느릴까 · 학습 지도 · 다음 → 10. 한 장 요약 - 이야기와 면접 답변

---

1. 가장 먼저 세 개를 분리하자

세 사건은 함께 일어날 수도 있고 일부만 일어날 수도 있다.

---

2. User Mode와 Kernel Mode

User Mode

일반 Application 코드가 제한된 권한으로 실행된다.

• Hardware를 마음대로 제어할 수 없음
• 다른 Process 메모리에 마음대로 접근할 수 없음
• 중요한 CPU 설정을 직접 바꿀 수 없음

Kernel Mode

운영체제 Kernel이 높은 권한으로 실행된다.

• Memory와 Process 관리
• Device 제어
• Scheduling
• System Call 처리

Mode는 “누구의 Process인가?”가 아니라 “어떤 권한 수준으로 실행 중인가?”에 관한 개념이다.

Process A를 위해 Kernel이 System Call을 처리할 때도 CPU는 Kernel Mode이지만, 논리적으로 A의 요청을 처리하는 실행 흐름일 수 있다.

---

3. System Call

일반 Process가 Kernel 기능을 요청하는 통제된 입구다.

예:

• File 읽기와 쓰기
• Process 생성
• Network 통신
• Memory 요청

Process A User Code
       ↓ System Call
Kernel이 A의 요청 처리
       ↓ 결과 반환
Process A User Code 계속

System Call이 즉시 처리되면 A로 그대로 돌아올 수 있다.

Mode Switch: 있음
A → B Context Switch: 없음

반대로 A가 아직 준비되지 않은 File을 읽으려 하면 A는 Waiting이 되고 B가 실행될 수 있다.

Mode Switch: 있음
A → B Context Switch: 있음

---

4. Interrupt

보통 Hardware가 CPU에 비동기적으로 알리는 사건을 말한다.

예:

• Timer 시간 만료
• Disk I/O 완료
• Network Packet 도착
• 키보드 입력

“비동기적”이라는 말은 현재 실행 중인 명령이 그 사건을 직접 요청한 바로 그 순간이 아닐 수 있다는 뜻이다. A가 계산 중인데 Network 장치가 이전 요청의 완료를 알릴 수 있다.

Interrupt가 발생하면 Kernel Handler가 실행되지만, 처리 후 A로 돌아갈 수도 있고 B로 바뀔 수도 있다.

---

5. Exception, Fault, Trap

용어 구분은 CPU와 교재에 따라 세부적으로 다를 수 있지만, 큰 흐름에서는 현재 명령 실행과 동기적으로 생긴 사건으로 이해하면 된다.

예:

• 0으로 나누기
• 허용되지 않은 명령
• Page Fault
• System Call을 위한 특별 명령

Page Fault도 결과가 하나로 고정되지 않는다.

• Memory에 이미 있는 Page의 연결만 고치고 A로 바로 복귀할 수 있다.
• Disk에서 Page를 읽어야 하면 A가 Waiting이 되고 다른 Process가 실행될 수 있다.
• 잘못된 주소 접근이면 A가 종료될 수 있다.

즉 “Page Fault = 항상 Process Context Switch”도 틀린 말이다.

---

6. 여섯 가지 상황 비교

---

7. Interrupt와 Context Switch의 관계

flowchart TD
    A["Interrupt 또는 System Call로<br/>Kernel 진입"] --> B{"다른 실행 대상을<br/>선택해야 하는가?"}
    B -->|아니오| C["현재 A의 Context로 복귀"]
    B -->|예| D["A의 상태와 Context 보존"]
    D --> E["Scheduler가 B 선택"]
    E --> F["B의 Context 복원 후 실행"]

Kernel 진입은 Context Switch의 기회 또는 원인이 될 수 있지만, 그 자체가 항상 Context Switch는 아니다.

---

8. Scheduler와 Dispatcher

Scheduler

Ready 후보 중 다음 실행 대상을 선택한다.

Dispatcher

선택된 실행 대상이 실제로 CPU를 쓰게 전환한다.

Scheduler: “다음은 B”
Dispatcher: A 저장 → B 환경과 Context 복원 → B 실행

실제 문서와 구현에서는 경계를 넓게 부르기도 하지만, 정책과 실행을 구분하는 사고가 중요하다.

---

9. Context와 PCB

Context

실행을 이어 가는 데 필요한 현재 상태. 좁게는 CPU Register 상태를 중심으로 말하고, 넓게는 Memory와 Kernel 실행 환경까지 포함할 수 있다.

PCB

Process를 생애 동안 관리하는 운영체제 기록. Context 저장과 연결되지만 PID, 상태, Scheduling, File, 권한처럼 더 넓은 관리 정보도 포함한다.

PCB 전체 = Context만 있는 것이 아님
Context = 실제 구현에서 PCB 한 상자에만 있는 것도 아님

---

10. Ready와 Waiting

둘 다 CPU에서 실행 중이 아니지만 이유가 다르다.

I/O가 완료된 B는 보통 Waiting에서 Ready가 된다. 곧바로 Running이 된다고 단정하지 않는다.

---

11. Preemption과 Blocking

Preemption

A는 계속 실행할 수 있지만 운영체제가 CPU를 회수한다.

Running → Ready

Blocking

A가 어떤 사건 없이는 진행할 수 없어 기다린다.

Running → Waiting

둘 다 A가 CPU에서 내려오지만 다음 상태가 다르다.

---

12. Concurrency와 Parallelism

Concurrency, 동시성

여러 작업이 겹치는 기간 동안 진행된다. 한 Core가 빠르게 번갈아 실행해도 가능하다.

Parallelism, 병렬성

여러 작업이 같은 물리적 순간에 실제로 실행된다. 보통 여러 Core가 필요하다.

한 Core:  A A B B A A B B    ← Concurrency
두 Core:  A A A A A A A A
          B B B B B B B B    ← Parallelism 가능

멀티코어에서도 실행 대상이 Core 수보다 많으면 각 Core에서 Context Switching이 일어난다.

---

틀린 문장 고치기

1. “Interrupt가 발생하면 무조건 Context Switch가 일어난다.”

수정:

Interrupt 처리 뒤 같은 실행 주체로 복귀할 수 있다. 다른 실행 주체를 선택하고 Context를 교체할 때 Context Switch가 일어난다.

2. “System Call은 Context Switch다.”

수정:

System Call은 User Process가 Kernel 기능을 요청하는 통제된 진입이다. 요청이 Block되거나 Scheduler가 다른 대상을 선택할 때 Context Switch로 이어질 수 있지만 항상 그런 것은 아니다.

3. “Waiting Process는 CPU 차례를 기다린다.”

수정:

Ready Process가 CPU 차례를 기다린다. Waiting Process는 I/O 완료 같은 사건을 기다린다.

4. “PCB는 Process의 전체 Memory 복사본이다.”

수정:

PCB는 Kernel의 Process 관리 기록이다. Process 주소 공간 전체를 매 Switch마다 복사해 둔 것이 아니다.

5. “Thread Switch는 주소 공간을 항상 바꾼다.”

수정:

같은 Process의 Thread들은 주소 공간을 공유하므로 보통 주소 공간을 바꾸지 않는다. 서로 다른 Process에 속한 Thread 사이에서는 주소 공간 전환이 필요할 수 있다.

다음 문서: 10. 한 장 요약 - 이야기와 면접 답변