[문과 코린이의 IT 기록장] 운영체제(OS)
- CPU 스케줄링 (CPU and I/O Bursts in Program Excution, CPU Scheduler & Dispatcher, Scheduling Criteria (성능 척도), Scheduling Algorithms, Multilevel Queue & Multilevel feedback queue, 특수한 Scheduling 방법, Algorithm Evaluation (알고리즘 평가))
운영체제
운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각
www.kocw.net
[문과 코린이의 IT 기록장] 운영체제(OS) - Process Management (프로세스 생성 (Process Creation), 프로세스
[문과 코린이의 IT 기록장] 운영체제(OS) - Process Management (프로세스 생성 (Process Creation), 프로세스 종료 (Process Termination), fork() 시스템 콜, exec() 시스템 콜, wait(..
vansoft1215.tistory.com
1. CPU and I/O Bursts in Program Excution
- 프로그램이 실행되면, 어떤 프로그램이던간에 이와같이 진행됨.
* CPU Burst : CPU만 연속적으로 쓰면서 명령어를 실행하는 단계
* I/O Burst : I/O만 실행하는 단계
- 어떤 프로그램이 실행된다는 것은 cpu burst와 io burst가 반복적으로 수행되는 것이라고 이야기할 수 있음
- 프로그램의 종류에 따라 이 빈도나 길이는 다름
** 사람이 많이 개입되는 경우, cpu burst가 짧아지고 io burst가 많아지면서, interactive하게 됨.
[ CPU - burst Time의 분포 ]
- CPU 스케줄링이 필요한 이유
: I/O bound job이 발생시키는 문제(사용자와 interactive 해야함.) 때문에, CPU bound job들이 계속 cpu를 잡고 있으면 사람들이 느끼기에 컴퓨터가 답답하다고 생각할 수 있다.
: 따라서 CPU 할당을 사람들과 상호작용하는 부분(I/O)에 먼저 할당해주는 것이 중요할 것이며, 이는 공평성보다 효율성이 중요시되도록 만드는 cpu 스케줄링의 방법 중 하나이다.
- CPU 스케줄링의 중요한 이슈들
1. 누구에게 먼저 줄 것인가
2. 얼마나 시간을 줄 것인가 (언제 뺏을 것인가?)
[ 프로세스의 특성 분류 ]
- 프로세스는 그 특성에 따라 다음 두 가지로 나뉜다.
1) I/O-bound Process
- CPU를 잡고 계산하는 시간보다 I/O에 많은 시간이 필요한 job
* 매우 짧은 CPU bursts 발생
2) CPU-bound Process
- 계산 위주의 job
* 적지만 긴 CPU bursts발생
2. CPU Scheduler & Dispatcher
1) CPU Scheduler
- Ready상태의 프로세스들 중에서, 이번에 CPU를 줄 프로세스를 고른다.
* 이는 운영체제 안에 있는 cpu schduling하는 코드들을 모아서 말하는 것
2) Dispatcher
- CPU의 제어권을 CPU scheduler에 의해 선택된 프로세스에게 넘긴다.
- 이 과정을 context switch(문맥 교환)이라고 한다.
* 운영체제의 커널 코드
# CPU 스케줄링이 필요한 경우는 프로세스에게 다음과 같은 상태 변화가 있는 경우이다.
a. Runnning -> Blocked
ex. I/O 요청하는 시스템 콜 : I/O가 작업시간이 오래걸려서 자진해서 cpu를 내어놓는 경우
b. Running -> Ready
ex. 할당시간만료로 Timer interrupt
c. Blocked -> Ready
ex. I/O 완료 후 인터럽트 : I/O작업이 완료되었다고 바로 cpu를 얻을 수 있는게 아님. 우선순위에 따라 받음
d. Terminate
ex. 어떤 프로세스가 종료되엇 더 이상 할일이 없을 때, 새로운 프로세스에게 cpu를 넘겨줘야 하는 경우
* a,d의 스케줄링은 nonpreemptive : 강제로 빼앗지 않고 자진 반납
* b,c의 스케줄링은 preemptive : 강제로 빼앗음
3. Scheduling Criteria (성능 척도)
* 어떤 스케줄링 알고리즘이 좋은지를 평가하는 척도가 필요함. 이를 성능척도라고 함.
1) 시스템 입장에서의 성능 척도
* CPU에게 일을 많이 시키는 알고리즘이 더 좋은 Scheduling Algorithm임.
a. CPU utilization (이용률)
- 전체 시간 중, CPU가 일한 시간의 비율을 나타낸다.
* CPU는 굉장히 비싸고 중요한 자원이기 때문에, 가장 바쁘게 일을 시켜야 한다. 즉, 전체 시간 중 일한시간의 비율인 이용률을 높이는 것이 컴퓨터 입장에서 CPU를 잘 활용하는 방법이다.
b. Throughput (처리량, 산출량)
- 주어진 시간동안에, 몇 가지의 작업을 완료했는가를 나타낸다.
* 주어진 CPU를 가지고, 정해진 시간 안에 더 많이 처리하는 것이 CPU를 잘 활용하는 것이다.
2) 프로그램 입장에서의 성능 척도 ( = 고객 입장에서의 성능척도)
* 시간과 관련된 성능 척도. 고객이 빨리 CPU를 얻고 처리되면 좋은 것.
a. Trunaround time (소요시간, 반환시간)
- CPU를 쓰러 들어온 후, 다 쓰고 나갈때까지 걸린 시간을 의미한다.
- 즉, CPU를 얻고 running하고 빠져나갈대까지의 모든 시간을 의미한다.
- 이는 프로세스가 종료되는 시간이 아니며, I/O하러 나간다면 그 때까지의 시간을 의미한다.
b. Wating time (대기 시간)
- CPU를 쓰기 위해 기다린 시간을 의미한다.
c. Response time (응답 시간)
- Ready Queue에 들어와서, 처음으로 CPU를 얻게 될 때까지 걸린 시간을 의미한다.
# 응답시간이라는 것은 Time Sharing환경에서, 사용자 응답과 관련해 굉장히 중요한 개념이다. 처음에 CPU를 얻게 되는 시간이 interactive측면에서는 중요하기 때문이다.
| [ Wating time vs Response time ] - 선점형 스케줄링의 경우 a. Wating time : cpu를 쓰다 인터럽트에 의해 뺐기고, 다시 cpu를 쓰는 과정이 반복된다. 이 기다린 시간을 총 합친 시간이 wating time이 된다. b. Response time : queue에 들어와서 최초의 CPU를 얻기 까지 기다린 그 시간만을 의미한다. |
4. Scheduling Algorithms
1) FCFS (First-Come First-Served)
- 먼저 온 프로그램에게 먼저 CPU를 주는 스케줄링 방법.
- 비선점형 스케줄링 방법(nonpreemptive)이라고 이야기할 수 있다.
- 문제점 : 굉장히 CPU를 오래 쓰는 프로그램이 먼저 도착해서 CPU를 잡아버리면, CPU를 짧게 쓰는 interactive한 작업들이 도착하더라도, 먼저 온 프로세스가 CPU를 놓을 때까지 기다려야 한다.
| Process | Burst Time |
| P1 | 24 |
| P2 | 3 |
| P3 | 3 |
ex 1 )
- 프로그램의 도착 순서 : P1, P2, P3
- 스케줄링 순서를 Gantt Chart로 나타내가기.
- Waiting tiem : P1 = 0, P2 = 24, P3 = 27
- Average Waiting Time : (0+24+27)/3 = 17
# 이와 같이 긴 프로세스가 하나 도착해서, 짧은 프로세스들이 지나치가 오래 기다려야 하는 현상을, Convoy effect라고 한다.
ex 2 )
- 프로그램의 도착 순서 : P2, P3, P1
- Waiting Time : P1=6, P2=0, P3=3
- Average Waiting Time : (6+0+3)/3 = 3
# 이와 같이 FCFS(First-Come First-Served)는 앞에 어떤 프로세스가 있느냐에 따라서, 기다리는 시간이 상당히 달라진다.
2) SJF (Shortest-Job-First)
- CPU burst time이 가장 짧은 프로세스에게 가장 먼저 CPU를 주는 스케줄링 방법이다.
[ 장점 ]
: 이를 통해 큐가 전체적으로 짧아지는 효과를 볼 수 있다.
: 즉 average waiting time이 가장 작아지게 만들어주는 알고리즘이라는 것이다.
[ SJF 알고리즘의 두 가지 방식 ]
a. nonpreemptive 방식
- 일단 CPU를 한번 잡으면 이번 CPU burst가 완료될 때까지 CPU를 선점(preemption)당하지 않는다.
- 즉, 더 짧은 CPU 사용시간을 지닌 프로세스가 도착해도 CPU를 빼앗기지 않는다.
b. preemptive 방식 (=SRTF)
- 현재 수행중인 프로세스의 남은 burst time보다, 더 짧은 CPU burst time을 가지는 새로운 프로세스가 도착해면 CPU를 빼앗긴다.
- 즉, 더 짧은 CPU 사용시간을 지닌 프로세스가 도착하면 CPU가 빼앗긴다는 것이다.
- 이 방법을 Shortest-Remaining-Time-First(SRTF)라고 부른다.
* average waiting time을 최소화하는 방식은, Preemptive 방식이다.
| Process | Arrival Time | Burst Time |
| P1 | 0.0 | 7 |
| P2 | 2.0 | 4 |
| P3 | 4.0 | 1 |
| P4 | 5.0 | 4 |
ex 1 ) non-preemptive 방식
- Average Waiting Time : (0+6+3+7)/4 = 4
ex 2 ) SJF (Preemptive 방식)
- Average waiting Time = (9+1+0+2)/4 = 3
# 어떤 예제를 써도 3초보다 더 짧은 average waiting time을 얻을 수는 없다.
[ SJF 방식의 단점 ]
a. Starvation (기아현상)
- 이 SJF는 CPU 사용시간이 짧은 것을 선호하기 때문에, CPU 사용시간이 긴 프로세스는 상당히 오랜시간동안 서비스를 진행하지 못할 수 있다.
ex. 사용시간 100초 프로세스가 다음에 실행 예정이었어도, 사용시간 1초 100개 프로세스가 도착하면, 100초 프로세스가 밀려나게 된다.
b. CPU 사용시간을 미리 알 수 없다.
- 프로세스가 얼마나 CPU를 사용하고 나갈 수 있을지에 대해 파악할 수 없다.
- 그러나 이는 예측이 가능하다.
[ 다음 CPU burst time을 예측하는 방법 ]
3) Priority Scheduling
- 우선순위가 가장 높은 프로세스에게 CPU를 주겠다는 개념
* 우선순위의 정의방법은 다양함 (일반적으로 작은 정수형 숫자로 표현)
[ Priority Scheduling의 두 가지 방식 ]
a. Preemptive
- 현재 우선순위가 가장 높은 프로세스가 CPU를 지니고 있더라도, 더 높은 우선순위의 프로세스가 도착하면 CPU를 뺐긴다.
b. non-Preemptive
- 현재 우선순위가 가장 높은 프로세스가 CPU를 지니면, 완료 될 때까지 CPU를 뺐기지 않는다.
[ Priority Scheduling의 단점 ]
a. Starvation (기아 현상)
- 우선순위가 더 높은 것들이 지속적으로 들어와서, 후순위의 프로세스들은 영원히 CPU를 얻지 못할 수 있다.
* 컴퓨터 시스템에서 효율성을 추구하는 것이 상당히 중요하지만, 특정 프로세스가 지나치게 차별을 받는 것은 막을 필요가 있다.
# 이를 막기 위해 aging이라는 기법을 도입하게 된다.
- 아무리 우선순위가 낮은 프로세스더라도, 오래 기다리게 되면 우선순위를 조금씩 높여주는 것
4) Round Robin (RR)
- 현대적인 컴퓨터 시스템에서 사용하는 CPU 스케줄링은 이에 기반하고 있다.
* CPU에 time interrupt를 넣어서 전달해주는 것 등이 모두 round robbin scheduling에 기반함.
* 이는 선점형 스케줄링(Preemtive)임.
- 각 프로세스는 동일한 크기의 할당 시간 (time quantum)을 지니며, 할당 시간이 끝나면 프로세스는 선점(Preempted)당하고 ready queue의 제일 뒤에 가서 줄을 다시 선다.
* 할당 시간이 지나치게 길어지면 : FCFS와 같은 스케줄링 알고리즘이 됨.
* 할당 시간이 지나치게 짧아지면 : context switch가 반복되어 오버헤드가 발생하며, 오히려 시스템 성능이 나빠짐.
** 따라서 적당한 정도의 할당시간을 주는 것이 중요
[ Round Robbin의 장점 ]
- 이 스케줄링의 가장 좋은 장점은 응답시간이 빨라진다는 것이다.
- n개의 프로세스가 ready queue에 있고, 할당 시간이 q time unit인 경우 각 프로세스는 최대 q time unit단위로 CPU 시간의 1/n을 얻는다. 즉, 어떤 프로세스도 (n-1)q time unit 이상 기다리지 않는다는 것이다.
- 따라서, 아주 짧은 시간만 기다리면, 어떤 프로세스든 CPU를 한 번은 얻을 수 있는 기회를 가지게 된다.
- 어떤 프로세스가 어느정도의 CPU를 사용할 수 있을지 모르는 상황에서, 이와 같은 방식을 사용하게 되면 CPU를 짧게 쓰는 프로세스는 빠르게 사용하고 나갈 수 있으며, 긴 프로세스도 후순위로 밀려나지 않고 어느정도 CPU를 쓸 수 있다.
* 즉, Round Robbinn은 cpu를 기다리는 시간이 cpu를 사용하려는 시간에 어느 정도 비례하는 공정한 스케줄링이라는 것이다.
ex )
Time quantum = 20
| Process | Burst Time |
| P1 | 53 |
| P2 | 17 |
| P3 | 68 |
| P4 | 24 |
- 일반적으로 Round Robbin은 SJF보다 turnaround time이나 waiting time은 길어질 수 있지만, 최초로 CPU를 얻는데 걸리는 response time은 더 짧다.
| 참고 ) Round Robbin Scheduling은 CPU 사용시간이 프로세스들이 얼마나 쓸지를 알 수 없는 상황에서 마구잡이로 섞여있을 때 쓰기 좋은 스케줄링이며, 반대로 CPU 사용시간이 모두 동일하다고 판단되는 경우에는 프로세스들이 하나씩 빨리 CPU를 쓰고 나갈 수 있도록 FCFS와 같은 스케줄링을 진행하는 것이 좋다. (즉 time quantum을 크게 해주는 것이 좋다.) # 일반적으로 컴퓨터에서는 여러가지 프로세스들이 섞여 있기 때문에, Round Robbin이 효과를 발휘하는 것이다. |
- 이 Round Robbin은 프로세스의 context를 저장하고, 다시 시작할 때 그 지점부터 시작할 수 있도록 하는 매커니즘이 제공되기 때문에 사용 가능한 방법이다.
5. Multilevel Queue & Multilevel feedback queue
- 현재까지는 Ready queue가 한 줄이라고 가정하고 이야기했었다.
- 그러나, Multilevel queue나, Multilevel feedback queue와 같이 여러 큐가 존재하는 것 또한 있다.
1) Multilevel Queue
- Multilevel Queue는 Ready queue를 여러개로 분할하는 것이다.
ex. 큐를 두 개로 분할 할 경우
a. foreground queue
: interactive한 작업들을 넣는 큐
: 스케줄링 방식 - Round Robbin
* 사람과 interaction하는 프로세스이기 때문에, 응답시간을 짧게 만들 수 있도록 Round Robbin을 사용하는 것이 좋음
b. background queue
: batch형 작업들을 넣는 큐 (중간에 사람과의 interaction 없이, cpu만 오래 쓰는 작업들)
: 스케줄링 방식 - FCFS
* 응답시간이 빠를 필요가 없으므로, context switch로부터 발생하는 오버헤드를 줄이기 위해 FCFS를 활용하는 것이 효과적임.
- 이와 같이 줄의 특성에 맞는 큐별 스케줄링 방식을 채택해야 한다.
[ CPU를 주는 방법 ]
: 또한 어떤 큐에게, 그리고 그 큐 내부에 누구에게 cpu를 줄 것인지 결정해야 할 필요가 있다.
a. Fixed priority scheduling
- 우선순위를 상당히 중요시 여기는 방식에서는, 우선순위의 높은 줄이 비어있을 때만 낮은 줄에 있는 프로세스가 cpu를 얻을 수 있도록 한다.
- 그러나 이 방식은 우선순위가 낮은 프로세스들이 영원히 cpu를 얻지 못하는 starvation 현상이 발생할 수 있다.
b. Time slice
- 위의 starvation문제를 해결하기 위해 제시된 방법으로, 각 큐에 CPU time을 적절한 비율로 할당하는 방식이다.
ex. 전체 cpu시간의 80%는 우선순위가 높은 줄(RR)에 주고, 나머지 20%는 우선순위가 낮은 줄(FCFS)에 주는 방법
* 위로 갈 수록 우선순위가 높은 큐임
- 이와 같이 줄이 이미 정해져 있고, 프로세스가 본인의 운명대로 해당 줄에 가서 줄을 서며, cpu는 가장 우선순위가 높은 프로세스에게 먼저 넘겨지는 스케줄링 방법을 따름
2) Multilevel Feedback Queue
- 프로세스가 다른 큐로 이동이 가능하다.
* 즉, 낮은 우선순위여도 올라가기도 하고, 높은 우선순위를 지닌 프로세스더라도 낮아지기도 하는 스케줄링 방법임
- aging을 이와 같은 방식으로 구현할 수 있다.
- Multilevel-feedback queue 스케줄러를 정의하는 파라미터들 (문제요소들)
a. Queue를 몇 개 둘 것인가?
b. 각 Queue에서는 어떤 스케줄링 알고리즘을 사용할 것인가?
c. 우선순위가 높은 큐에서 낮은 큐로 떨어지는 기준은 무엇으로 할 것인가?
d. 우선순위가 낮은 큐에서 높은 큐로 승격되는 기준은 무엇으로 할 것인가?
e. 처음 프로세스가 CPU 서비스를 받으려 들어갈 때, 어떤 큐로 들어갈 것인가?
ex. 일반적인 Multilevel-feedback queue 스케줄링 방법
- 처음 들어오는 프로세스는 우선순위가 가장 높은 큐에 들어간다.
- 해당 큐의 할당시간 내에 처리가 되지 않은 프로세스들은, 아래의 큐로 처리될 때까지 점점 내려가게 된다.
- 우선순위가 가장 높은 큐는 Round Robbin알고리즘을 사용하며, time quntum을 아주 짧게 준다.
- 아래의 큐로 내려갈수록 Round Robbin의 할당시간은 증가하며, 가장 아래의 큐는 FCFS 알고리즘을 활용한다.
* 따라서 cpu burst가 아주 짧은 프로세스들은, 도착하자마자 빠르게 cpu를 사용하고 나갈 수 있다.
* 즉 이 방법은 cpu 사용시간이 짧은 프로세스들에게 우선순위를 많이 주는 방식이며, cpu 사용시간이 긴지 짧은지에 대한 예측을 할 필요가 없는 방법이다.
6. 특수한 Scheduling 방법
1) Multi-Processor Scheduling (cpu가 여러개 있을 경우의 스케줄링)
- cpu가 여러개인 경우, 스케줄링은 더욱 복잡해진다.
(1) 공동 큐를 사용하는 방법, 별개의 큐를 사용하는 방법
* Homogeneous Processor의 경우
- 일반적으로 queue에 한 줄로 세워서 각 프로세스가 알아서 꺼내가게 함.
- 경우에 따라서, 반드시 특정 프로세스에서 수행되어야 하는 프로세스가 있는 경우에는 문제가 더 복잡해진다.
ex. 특정 job이 해당 cpu에서만 실행해야 하는 경우가 있음. (그 경우에는 cpu마다 별도의 줄을 설 수 있도록 함)
# Load Sharing
- cpu가 여러개 있는 경우, load sharing이 잘 되어야 한다. 즉 특정 cpu만 활동하고 나머지 cpu는 일을 하지 않는 방식으로 이루어지면 안된다는 것이다.
- 일부 프로세서에 job이 몰리지 않도록, 부하를 적절히 공유하는 메커니즘을 load sharing이라고 한다.
(2) Symmetric Multiprocessing (SMP) 방식
- 각 프로세스가 각자 알아서 스케줄링 결정
(3) Asymmetric Multiprocessing
- 하나의 프로세서가 시스템 데이터의 접근과 공유를 책임(전체적인 컨트롤을 담당)지고 나머지 프로세서는 거기에 따름
2) Real-Time scheduling
- real-time job은 정해진 deadline이 있는 작업을 의미한다. 따라서, cpu 스케줄링을 할 때에도 반드시 이 deadline을 보장해주어야 할 것이다.
- 이와 같은 이유로, real-time scheduling은, SJF처럼 그때그때 스케줄링을 하는 방식이 아닌, real-time job이 미리 주어져 스케줄링을 해 놓고 deadline이 지켜지도록 적재적소에 배치하는 방식을 활용하고 있다.
* 즉 time-sharing 시스템보다는, 작업들이 기한 내에 처리되는 것을 더욱 중요시 여기고 있다는 것이다.
ex. 10초에 한번씩은 1초씩 A 프로세스가 cpu를 사용할 수 있도록 하는 방식 지정
(1) Hard real-time systems
- Hard real-time task는 정해진 시간 안에 반드시 끝내도록 스케줄링 해야함.
(2) Soft real-time computing
- Soft real-time task는 일반 프로세스에 비해 높은 priority를 갖도록 해야함.
ex. 영화를 보는 것 - 영화와 같은 것은 deadline이 있지만 조금 기한을 어겨도 되는 시스템들임. 이러한 것들은 다른 프로세스들에 비해 우선순위를 높여주어 cpu를 잘 할당받을 수 있도록 보장해줌
3) Thread Scheduling
(1) Local Scheduling
- User level thread의 경우 사용자 수준의 thread libary에 의해 어떤 thread를 스케줄할지 결정
- 즉, User level thread의 경우 운영체제는 thread의 존재를 모르기 때문에, 그 프로세스에게 cpu를 줄지 안줄지만 결정한다. 따라서 프로세스 내부에서 어떤 thread에게 cpu를 줄지는 프로세스가 결정하게 된다는 것이다.
(2) Global Scheduling
- Kernel level thread의 경우 일반 프로세스와 마찬가지로 커널의 단기 스케줄러가 어떤 thread를 스케줄할지 결정
- 즉, 운영체제가 thread의 존재를 알기 때문에, 프로세스를 스케줄링하듯이 운영체제 알고리즘에 근거하여 어떤 thread에게 cpu를 줄지 결정하게 된다.
7. Algorithm Evaluation (알고리즘 평가)
- 어떤 알고리즘이 좋은지를 평가할 수 있는 방법
1) Queueing models
- 가장 이론적인 방법
- 확률 분포로 주어지는 arrival rate와 service rate 등을 통해 각종 performance index값을 계산
- 과거에는 많이 사용한 방식이지만, 현재는 실제 시스템을 활용해 돌려보는 방식을 더욱 중요하게 여겨서 잘 활용하지 않음. (그러나 이론적으로는 여전히 중요)
2) Implementation(구현) & Measurement(성능 측정)
- 실제 시스템에 알고리즘을 구현하여 실제 작업(workload)에 대해서 성능을 측정 비교
- 이 방법은 시간도 오래 걸리고 돈도 많이 들어, 어려운 방식이다.
ex. 내가 새로 만든 cpu 스케줄링 알고리즘을 평가해보기 위해서
- Linux의 원래 cpu 스케줄러에, 나의 알고리즘 Linux 커널 소스코드로 수정해 새로운 알고리즘을 구현한 다음에, 컴파일을 해본다.
- 원래 Linux를 설치했던 컴퓨터와, 내 cpu 스케줄러를 넣어 만든 Linux 커널을 설치한 컴퓨터 두 대를 비교한다.
- 더 빨리 프로그램을 끝내는 컴퓨터의 스케줄러가 더 좋은 스케줄러라는 것을 비교할 수 있다.
3) Simulation(모의 실험)
- 위의 Implemnetation & Measurement 방식을 좀 더 쉽게 활용하기 위해 만들어진 방법
- 알고리즘을 모의 프로그램으로 작성 후 trace를 입력으로 하여 결과 비교
* trace : 시뮬레이션 프로그램에 input으로 들어갈 데이터.
** trace는 임의로 만들수도 있고, 실제 프로그램을 통해 추출할 수도 있음.
# 어떤 알고리즘이 좋고 나쁨을 이야기하는데 있어, 단지 예제 하나를 두고 주장하는 것은 적절하지 않다.
# 따라서, 실제 시스템에서 각 프로세스의 cpu 사용패턴을 여러가지 뽑아서, 실제 프로그램의 cpu burst 패턴에 근거해 시뮬레이션을 하며 더 신빙성을 높일 필요가 있을 것이다.
| * 유의사항 - 아직 공부하고 있는 문과생 코린이가, 정리해서 남겨놓은 정리 및 필기노트입니다. - 정확하지 않거나, 틀린 점이 있을 수 있으니, 유의해서 봐주시면 감사하겠습니다. - 혹시 잘못된 점을 발견하셨다면, 댓글로 친절하게 남겨주시면 감사하겠습니다 :) |
