인프런 커뮤니티 질문&답변
작성한 질문수
프로세스와 알고리즘 등 관련...
해결된 질문
작성
·
447
1
안녕하세요 강의 관련 궁금한 점들이 있습니다...
1.프로세스들의 우선순위는 어떤 방식으로 정해지는 것인가요?
2. 운영체제가 ‘준비상태의 다중큐’를 참조해 그 안에 들어있는 프로세스들 중 적당한 프로세스를 선택해 실행상태로 전환시킨다고 들었는데 적당한 프로세스를 고르는 기준은 정확히 어떻게 되는지, 우선순위가 영향을 주는지 궁금합니다.
3. CPU 스케줄러와 운영체제는 완벽한 동의어인가요?
4. FIFO 알고리즘의 단점 중, I/O 작업이 있을 경우 CPU는 I/O 작업이 끝날 때까지 쉬고 있기 때문에 CPU 사용률이 떨어지는 것이 있다고 들었습니다.
그런데 대기상태의 경우, 특정 프로세스가 입출력 요청을 하면 입출력이 완료될 때까지 CPU를 기다리게 하는 건 굉장히 비효율적이라 입출력 요청을 한 프로세스를 대기상태로 두고 다른 프로세스에게 CPU를 할당한다고 들었는데
FIFO의 경우에는 1개 프로세스의 완전 종료 전까지 다른 프로세스들이 실행될 수 없어서 그런 것인가요? 그렇다면 FIFO 알고리즘의 경우에는 대기 상태가 존재하지 않는 것인가요?
5. 대기 상태의 경우 입출력 작업이 완료되면 대기상태에 있던 프로세스에게 CPU 할당 기회를 준다고 들었는데 기회를 준다는 것은 반드시 실행상태로 즉시 전환되는 것은 아니라는 의미인가요?
답변 1
0
1.프로세스들의 우선순위는 어떤 방식으로 정해지는 것인가요?
MLFQ에서 새로 생성된 프로세스에게 보통 높은 우선순위를 부여합니다.
하지만 시간이 지남에따라 에이징(Aging)을 통해 우선순위를 점점 낮아지게 만듭니다.
또한 운영체제 사용자가 특정 프로세스의 우선순위를 올려줄 수도있습니다.
2. 운영체제가 ‘준비상태의 다중큐’를 참조해 그 안에 들어있는 프로세스들 중 적당한 프로세스를 선택해 실행상태로 전환시킨다고 들었는데 적당한 프로세스를 고르는 기준은 정확히 어떻게 되는지, 우선순위가 영향을 주는지 궁금합니다.
적당한 프로세스를 선택하는 것은 우선순위로 선택한다는 말입니다.
큐에 있는 프로세스 중 더 높은 우선순위의 프로세스가 무조건 먼저 실행됩니다.
(프로세스가 큐에서 선택되어 실행되면 우선순위가 한 단계 낮아집니다)
3. CPU 스케줄러와 운영체제는 완벽한 동의어인가요?
아닙니다.
CPU 스케줄러는 운영체제의 부분집합입니다.
운영체제의 CPU 스케줄링을 담당하는 녀석을 CPU 스케줄러라고 부릅니다.
4. FIFO 알고리즘의 단점 중, I/O 작업이 있을 경우 CPU는 I/O 작업이 끝날 때까지 쉬고 있기 때문에 CPU 사용률이 떨어지는 것이 있다고 들었습니다.
그런데 대기상태의 경우, 특정 프로세스가 입출력 요청을 하면 입출력이 완료될 때까지 CPU를 기다리게 하는 건 굉장히 비효율적이라 입출력 요청을 한 프로세스를 대기상태로 두고 다른 프로세스에게 CPU를 할당한다고 들었는데 FIFO의 경우에는 1개 프로세스의 완전 종료 전까지 다른 프로세스들이 실행될 수 없어서 그런 것인가요? 그렇다면 FIFO 알고리즘의 경우에는 대기 상태가 존재하지 않는 것인가요?
맞습니다.
현재 실행상태에 있는 프로세스를 제외하고 나머지 프로세스는 실행상태로 있던적이 없기 때문에 대기상태도 될 수 없습니다.
5. 대기 상태의 경우 입출력 작업이 완료되면 대기상태에 있던 프로세스에게 CPU 할당 기회를 준다고 들었는데 기회를 준다는 것은 반드시 실행상태로 즉시 전환되는 것은 아니라는 의미인가요?
맞습니다.
다른 프로세스들과 마찬가지로 우선순위를 가지고 준비큐에 들어갑니다.
그리고 우선순위에 따라서 실행됩니다.(우선순이가 높다면 바로 실행되고 낮다면 늦게 실행)
우선순위가 같은 프로세스는 같은 큐에 들어갑니다.
큐는 First In First Out으로 먼저 들어온 프로세스가 먼저 서비스를 받는 자료구조이므로 큐에 먼저 들어온 프로세스가 먼저 실행됩니다.
우선순위1인 1번프로세스가 실행됐다면 우선순위2가 되는게 맞습니다.
프로세스의 상태값 변경이란 말은 곧 PCB의 내용을 변경했다는 말입니다.
꼭 실행중인 프로세스뿐만 아니라 다른 모든 상태에서도 변경이 이루어집니다.
그렇다면 혹시 '다중큐' 파트 설명에서
1. '다중큐'로 준비상태나 대기상태의 프로세스들이 관리되는 것은 최신형 스케줄링 알고리즘 기준인가요?
2. 그렇다면 FIFO 알고리즘과 최신형 알고리즘의 차이는 1중큐냐 다중큐냐 차이 정도인 것인가요?
3. 대기시간과 응답시간 둘 다 요청 -> 실제 작업(응답)까지 걸리는 시간으로 생각이 되는데 이 둘의 명확한 차이점이 어떻게 되나요?
4. 다른 모든 상태에서도 프로세스 상탯값 변경(pcb 내용 변경)이 이루어진다는 뜻이 이해가 잘 가지 않습니다... 프로세스 상탯값 변경(pcb 내용 변경)은 실행 중인 프로세스가 대기/준비상태로 돌아갈 때에만 일어나고 대기/준비 상태의 프로세스가 실행상태로 돌아갈 때에는 pcb로부터 단지 해당 프로세스의 상탯값을 cpu에 설정시키는 것이 아니었나요?
5. 프로세스 상태 == 프로세스 상태값인가요? 3번째 질문에서 궁금했던 것은 프로세스의 5가지 상태가 어떻게 변경되는지였어서...
정말 감사합니다!
1. '다중큐'로 준비상태나 대기상태의 프로세스들이 관리되는 것은 최신형 스케줄링 알고리즘 기준인가요?
맞습니다. MLFQ에 대한 설명입니다.
2. 그렇다면 FIFO 알고리즘과 최신형 알고리즘의 차이는 1중큐냐 다중큐냐 차이 정도인 것인가요?
아닙니다. 동작에 따라 여러 큐가 생긴 것입니다.
RR 스케줄링은 큐가 하나이지만 시분할로 처리합니다.
비교하자면 FIFO는 비선점형 알고리즘(다른 프로세스가 중간에 CPU를 뺏지못함)으로,
RR, MLFQ는 선점형 알고리즘(다른 프로세스가 중간에 CPU를 뺏음)으로 구분할 수 있습니다.
중간에 CPU가 뺏을수 있냐 없냐의 차이로 구분하는게 더 좋을것 같습니다.
3. 대기시간과 응답시간 둘 다 요청 -> 실제 작업(응답)까지 걸리는 시간으로 생각이 되는데 이 둘의 명확한 차이점이 어떻게 되나요?
대기시간(Wait Time)과 응답시간(Response Time)는 작업시간을 포함하는지가 다릅니다.
대기시간은 프로세스가 큐에 들어온 시간 + 프로세스가 시작되는 시간이고
응답시간은 프로세스가 큐에 들어온 시간 + 프로세스의 작업이 완료된 시간입니다.
즉 응답시간은 대기시간 + 작업시간으로 볼 수 있습니다.
4. 다른 모든 상태에서도 프로세스 상탯값 변경(pcb 내용 변경)이 이루어진다는 뜻이 이해가 잘 가지 않습니다... 프로세스 상탯값 변경(pcb 내용 변경)은 실행 중인 프로세스가 대기/준비상태로 돌아갈 때에만 일어나고 대기/준비 상태의 프로세스가 실행상태로 돌아갈 때에는 pcb로부터 단지 해당 프로세스의 상탯값을 cpu에 설정시키는 것이 아니었나요?
온수옴님이 이해하고 계신게 맞습니다.
실행상태로 돌아갈 때는 PCB로부터 상태값을 CPU에 다시 설정합니다.
5. 프로세스 상태 == 프로세스 상태값인가요? 3번째 질문에서 궁금했던 것은 프로세스의 5가지 상태가 어떻게 변경되는지였어서...
제가 용어의 혼동때문에 조금 오해한 것 같습니다.
컨텍스트 스위칭을 위해서 CPU의 상태를 PCB에 저장한다고 했습니다.
PCB에는 프로세스가 실행하고 있던 상태값이 저장되죠.
여기서 프로세스의 상태값은 프로세스의 상태(Status)와 스케줄링 정보등이 저장되는데 프로세스의 상태값을 프로세스의 상태로 이해했었네요.😂
그렇다면 프로세스가 준비 -> 실행으로 갈 때나, 실행 -> 준비로 갈 때 pcb의 process status는 어떻게 변경되는 것인가요?
대기 -> 실행, 실행 -> 대기도 process status를 제외한 나머지 레지스터값 등이 바뀌지 않는다는 걸 빼고는 위의 경우와 동일하게 변경되나요?
준비 -> 실행으로 갈때는 Process Status 는 Running, 실행 -> 준비로 갈때는 Ready로 바뀝니다.
실행상태에서 다른 상태로 갈 때는 현재 CPU의 레지스터값을 저장해야하기 때문에 PCB에 해당 변경사항을 저장해줘야합니다. 따라서 실행 -> 대기는 status외에도 레지스터 정보도 저장됩니다.
그럼 실행 -> 대기일 때에는 status가 pcb의 process status가 blocked로 변경되는 것인가요?
그런데 실행 -> 대기일 때 저장되는 정보는 위쪽 답변보다는 최신 답변이 맞는 것인가요? 둘이 조금 다른 의미인 것 같습니다...
cpu 스케줄링 정보 같은 것들은 pcb에서 딱히 cpu로 설정되지 않고 가만히 있는 것인가요?;;
맞습니다. PCB의 Process Status를 바꾸는게 상태가 바뀌는 것입니다.
Status가 RUNNING으로되면 실행상태, READY면 준비상태로 바뀐것이지요.
실행에서 다른 상태로 넘어갈때는 항상 현재 Context를 저장합니다.
실행 -> 대기상태로 갈 때 현재 레지스터정보를 PCB에 저장합니다.
그리고 다른 준비상태에 있던 프로세스가 실행상태가 되므로 새로 시작되는 프로세스의 PCB정보를 바탕으로 레지스터값을 CPU에 설정합니다.
온수옴님께서는 PCB에서 어떤 내용들이 변경되는지 궁금증이 많으신데 운영체제의 소스를 직접 보는게 많은 도움이 될 것 같습니다.
커널 함수 context_switch() 함수를 보시는 걸 추천드립니다.
커널 소스를 보면서 컨텍스트 스위칭할 때 어떤 값이 업데이트 되는지, 어떤 순서로 진행되는지 알 수 있습니다.
리눅스의 core.c 내 schedule()함수와 context_switch() 함수를 살펴보시는 걸 추천드립니다.
해당 소스를 보다보면 task_struct라는 구조체가 있습니다.
이 taask_struct 구조체가 바로 PCB입니다.
task_struct가 변경되는 값을 보면 어떤 값들이 어떤 상황에서 수정되는지 정확하게 알 수 있겠죠?
그렇다면 2번에서
우선순위1 - 프로세스 1,2
우선순위2 - 프로세스 3,4
가 있다고 가정하면
동일한 최상위 우선순위에 있는 1번 프로세스와 2번 프로세스 중 cpu 스케줄러가 무엇을 먼저 실행시킬지 고르는 것은 랜덤인가요?
그리고 만약 1번 프로세스를 골라 먼저 실행시켰다면 1번 프로세스가 대기상태로 돌아갈 때
우선순위1 - 프로세스 2
우선순위2 - 프로세스 1,3,4
이렇게 된다는 말씀이신가요?
그리고 컨텍스트 스위칭으로 인해서 PCB의 내용이 변경될 때
프로세스 상태값 변경은
실행 중인 프로세스의 상태를 PCB에 저장할 때만 일어나는 것인가요?
그렇게 될 경우에는
PCB의 상태값이 (실행 -> 대기)로 바뀌고 난 뒤, 다시 해당 프로세스가 실행될 때 PCB를 참조해 CPU를 설정할 때 프로세스의 상태가 대기로 저장될 것 같아서 헷갈립니다...