작업을 바꿨는데 어디서 이어 갈까? 문맥 전환과 스케줄링

Об этом предложении

동영상을 보면서 편집기를 사용하는 상황을 생각해보겠습니다. CPU가 실행할 작업을 바꿨다가 돌아왔을 때, 편집기는 처음부터 시작하지 않습니다. 멈춘 위치와 실행 상태를 보관하고 복원하기 때문 입니다. 선택하는 일과 바꾸는 일 스케줄링은 다음에 실행할 작업을 선택하는 일입니다. 문맥 전환은 현재 실행 상태를 저장하고 다른 작업의 상태를 복원하는 일입니다. 두 용어를 같은 뜻으로 외우면 “누구를 선택했나”와 “어떻게 이어 갔나”가 섞입니다. 스레드의 문맥에는 실행 위치와 레지스터 상태 등이 포함됩니다. 같은 프로세스의 스레드 사이에서는 주소 공간을 공유하지만 실행 상태는 각각 관리합니다. OSTEP의 스레드 문맥 설명 그림은 핵심 절차를 줄인 모델입니다. 실제 커널 함수 호출 순서나 모든 저장 항목을 나타내지는 않습니다. 시간 조각을 나눠 주는 예시 라운드 로빈은 실행 가능한 작업을 시간 조각 단위로 번갈아 실행하는 대표적인 설명 모델입니다. OSTEP의 스케줄링 장 A와 B가 각각 계산 3단위가 필요하고, 시간 조각을 1단위라고 가정하겠습니다. 도착 시각은 같고, 입출력 대기와 전환 비용은 이번 계산에서 제외합니다. const remaining = { A: 3, B: 3 }; const trace = []; while (remaining.A + remaining.B > 0) { for (const job of ["A", "B"]) { if (remaining[job] > 0) { remaining[job] -= 1; trace.push(job); } } } console.log(trace.join(" ")); 검증한 출력은 A B A B A B 입니다. 이것은 JavaScript로 작성한 스케줄링 모형 이며, 운영체제의 실제 스케줄러를 실행하거나 측정한 결과는 아닙니다. 조각을 작게 만들면 무조건 좋을까? 작은 시간 조각은 다른 작업이 첫 실행 기회를 받기까지의 시간을 줄일 수 있습니다. 하지만 전환이 잦아지면 상태 저장·복원과 캐시 등에 영향을 주는 비용도 고려해야 합니다. 응답성과 총 처리량은 같은 목표가 아닙니다. OSTEP의 시간 조각과 전환 비용 설명 모든 인터럽트가 작업 교체로 이어지는 것도 아닙니다. 이벤트가 발생했다는 사실과 실제로 다른 실행 흐름으로 전환했는지는 구분해서 봐야 합니다. 확인 문제 다음 작업을 고르는 것은 스케줄링일까요, 상태 복원일까요? B가 이미 끝났다면 위 모형은 B를 계속 실행할까요? 전환 비용을 무시한 시간표로 실제 처리량을 단정해도 될까요? 답과 해설 스케줄링입니다. 선택한 작업으로 상태를 바꾸는 과정과 구분합니다. 아닙니다. 남은 계산이 0이면 실행하지 않습니다. 안 됩니다. 실제 작업과 전환 비용, 캐시, 입출력 등을 측정해야 합니다. 복습 오늘은 “선택 → 저장·복원 → 실행”을 말로 설명해보겠습니다. 내일은 A가 4단위, B가 2단위인 시간표를 그리고, 일주일 뒤에는 응답 시간과 완료 시간을 구분해보면 좋겠습니다. 다음에는 여러 작업이 서로 자원을 기다리는 문제를 살펴봅니다. 자료 확인 기준: OSTEP 스레드·스케줄링 장, 2026-10-04. 예제의 시간 단위는 설명용이며 실제 성능 수치가 아닙니다. 예제 검증 환경: Node.js v24.13.1.

Детали предложения

Провайдер

velog

Источник

velog-rss

Балл

54.39

Уверенность

49%