gnuykob_sw

[수업출처] 숙명여자대학교 소프트웨어학부 김주균 교수님 운영체제 수업 & [OS? Oh Yes!] 

1. (CPU) 스케줄링

- 시분할 시스템에서 현제 프로세스로부터 다른 프로세스로 CPU를 넘겨주어야 할 때, 기다리는 프로세스들 중에 어떤 프로세스를 선택해야할 지에 대한 방식이나 기준

- 수행 단계에 따라 장기, 중기, 단기 스케줄링

- 장기

    - 어느 작업을 커널에 등록시켜 프로세스로 만들어 줄 것인가 결정

    - 작업 스케줄링

    - 일괄처리) 작업: 디스크 → 일괄처리 큐 대기 → 장기 스케줄러 → 프로세스

    - 시분할) 사용자의 접속 시도를 허용할지 말지 결정하는 단계

    - 요청된 일을 프로세스로 만들어 시스템에 알려진 일거리로 추가하느냐 결정 → 다중 프로그래밍 정도 조절

    - 수행 횟수 적음, 대부분 FIFO 방식

- 중기

    - 보류 상태의 프로세스 중에서 어느 프로세스에 메모리를 할당할 것인지 결정

    - Swap In (or Resume)

- 단기

    - 준비 상태의 프로세스 중에서 어느 프로세스에 CPU를 할당할 것인지 결정

    - 프로세스 스케줄러 (디스패처)라 불리는 것에 의해 수행

    - 입출력, 시간 종료 인터럽트, 시스템 콜 등과 같은 다양한 이유에 의해 가동

    - 자주 수행됨 → 실행 시간 줄여야 함

2. 스케줄링의 목적과 기준

1) 목적

- 사용자 관점

    - 응답시간: 프로세스 요청에 의해 시스템이 최초로 출력을 내주기 시작할 때까지 걸린 시간 → 대화형 시스템

    - 반환시간: 요청으로부터 결과를 돌려받는 데까지 걸린 시간 (일괄처리)

    - 예측가능성: 요청한 일이 얼마 후쯤에는 완료될 수 있을 것이라는 예측

- 시스템 관점

    - 처리량: 단위 시간에 완료된 프로세스의 개수 → 일괄처리 시스템

    - 활용도: 주어진 시간동안 특정 자원이 실제로 가동된 시간의 비율

- 가능한 한 CPU 시간을 공평하게 나누어 주어야 함 (공평성)

- 특정 프로세스가 장기간 CPU를 받지 못하게 되는 경우 최대한 피해야 함

- 시스템에 있는 여러 자원들은 가급적 균형있게 사용되어야 함

- 빠른 응답시간을 주기 위해 스케줄링을 자주 한다면 문맥교환이 자주 일어나게 되고, 이것은 CPU 시간의 상당 부분이 문맥교환에 사용된다는 것을 의미 → 사용자 프로세스를 실행할 시간이 줄어 전체적으로는 처리량 감소

- 주어진 기간 동안에 많은 프로세스 처리하여 처리량을 높이려고 수행 시간이 짧은 프로세스들 주로 처리 → 수행시간이 긴 프로세스는 처리가 늦어져 응답시간이 길어짐

2) 고려해야 할 기준들

- 프로세스의 성격

    - CPU를 사용하는 연산이 입출력에 비해 상대적으로 많은 것: 연산 위주 프로세스 (CPU-bound)

    - 입출력이 상대적으로 많은 것: 입출력 위주 프로세스 (I/O-bound)

    - 목적에 따라 어떤 종류의 프로세스 우대할지 생각

- 시스템이 사용될 환경

    - 응답시간을 우선으로 할지, 처리량을 우선으로 할지

    - 특정 프로세스에게 우선적으로 빠른 응답시간을 보장해야 하는 경우 → 가능케 하는 기능 필요

    - 프로세스 크고 작음에 따라 어떤 것을 우선적으로 처리할 지 기준 필요 (CPU 요구량 & 메모리 요구량)

3. 스케줄링 기법들

[스케줄링이 가동되어야 할 때]

- 실행 상태에서 대기 상태로 전환될 때 (ex 입출력)

- 실행 상태에서 준비 상태로 전환될 때 (ex 시간 종료 인터럽트)

- 대기 상태에서 준비 상태로 전환될 때 (ex 입출력 종료)

- 프로세스 수행 종료

- 비선점 스케줄링: 프로세스가 CPU를 스스로 반납할 때까지 계속 사용

- 선점 스케줄링: 실행 중인 프로세스로부터 CPU를 빼앗아 다른 프로세스에 할당 가능

- 위의 4가지 경우 중 1번과 4번의 경우에만 스케줄링을 하게 되면 비선점 방식이 되고, 

- 2번과 3번에도 적용되는 스케줄링을 선점 방식이라 함

- Average Waiting Time 평균 대기 시간: 준비 큐에 도착한 후 실행될 때까지 걸린 시간, 사용자 만족도의 기준

1) FCFS (First Come First Service = FIFO) 스케줄링 

- 준비 큐에 먼저 도착한 프로세스에게 먼저 CPU 할당

- 비선점 방식

- 프로세스가 CPU를 독점하여 사용하기 때문에 아주 긴 프로세스가 실행될 경우 평균 응답시간이 길어짐

- 대화형 시스템에 적합하지 않음

- 프로세스들의 개수와 크기를 짐작할 수 있다면 각각의 프로세스들이 언제쯤 실행될 지 예측 가능, 공평함

- 실제 시스템에서 바로 사용되기는 어렵지만, 다른 스케줄링 기법의 보조 장치로서 활용 가능

- ex

- P1, P2, P3, P4의 순서로 거의 동시에 도착했을 때

- 평균 응답시간 = (100 + 110 + 120 + 130) / 4 = 115

- 평균 대기시간 = (0 + 100 + 110 + 120) / 4 = 82.5

- P2, P3, P4, P1의 순서로 거의 동시에 도착했을 때

- 평균 응답시간 = (10 + 20 + 30 + 130) / 4 = 47.5

- 평균 대기시간 = (0 + 10 + 20 + 30) / 4 = 15

2) SPN (Shortest Process Next) 스케줄링

- 준비 큐에 있는 프로세스들 중 가장 짧은 프로세스 (CPU 요구량이 가장 적은)를 먼저 실행

- 비선점 방식

- 평균 응답시간을 최소화할 수 있지만, 실행시간이 긴 프로세스가 CPU를 할당받지 못하고 계속 대기하는 무한 대기 현상 발생

    - 긴 프로세스일수록 그 편차가 커져 예측가능성은 감소할 것

    - 무한 대기 가능성을 낮추는 방법으로는 기다린 시간만큼 우선순위를 높여 실행가능성을 높여주는 것이 있음 (Aging)

- 각 프로세스들의 크기를 실행 전에는 정확히 알 수 없음에도 그 크기를 가지고 스케줄을 해야한다는 단점

    - 해결책: 프로세스의 크기를 실행 전에 추정해보는 지수 평균 방법 (Exponential Averaging)

    - 이전에 실행되었을 때의 크기와 그때의 추정 크기로 지금 실행되어질 크기 짐작

    - 이전 단계의 실제 크기 → 다음 추정 크기

    - 추정 크기와 실제 크기의 가중치를 각각 0.5로 설정하고, 추정크기를 a, 실제크기를 b라 했을 때

    - 실제1 = 추정2 = 0.5a + 0.5b

    - 실제2 = 추정3 = 0.5(0.5a + 0.5b) + 0.5b ...

- ex)

- 평균 응답시간 = (10 + 16.5 + 11) / 3 = 12.5

- 평균 대기시간 = (0 + 11.5 + 9) / 3 = 6.84

3) SRT(Shortest Remaining Time) 스케줄링

- SPN을 선점 방식으로 운영하는 것

- 새로 도착하는 프로세스의 실행시간 크기는 완료까지 남은 시간과 같으며, CPU를 할당받아 실행된 양만큼 남은 시간은 줄어들 것

- 준비 큐에서 완료까지 남은 CPU 요구량이 가장 짧은 것을 먼저 실행시켜 주는 방식

- 실행 도중 남은 실행 시간이 더 적은 프로세스가 준비 큐에 들어올 경우 현재 실행 중인 것을 중단하고 새 프로세스에 CPU 할당

- 완료까지 남은 실행시간의 계산, 잦은 문맥교환의 부담 존재

- 반환시간을 기준으로 했을 때 SPN보다 우수

- 위의 예제에 대입해보면

- P1 (0.5s) → P2 (0.5) → P3 (2) → P2 (4.5) → P1 (9.5) 의 순서로 CPU가 할당됨

- 평균 응답시간 = (17 + 7 + 2) / 3 = 8.67

- 평균 대기시간 = (7 + 2 + 0) / 3 = 3

- 이때 실제로는 SPN보다 더 많은 문맥교환이 요구되어 평균 응답시간이 조금 더 길어질 것임을 예상할 수 있음

- 만약 가까운 미래에 도착하게 될 프로세스의 정보를 알 수 있다면, 위의 예제에서 1초 뒤에 P3가 들어올 것을 알 수 있다면 P1을 할당하는 대신 1초를 기다렸다가 SPN을 적용하여 평균 응답시간을 줄일 수 있음 

→ 반복적인 시스템에서는 사용할 수 있겠지만 사실 어려움. idea 차원의 개념. Future-knowledge 스케줄링

- 잦은 문맥교환을 줄이는 방법

- SRT 스케줄링을 위한 임계값을 정해두고 두 프로세스의 남은 시간 차이가 임계값을 넘지 않을 경우에는 다음 프로세스의 실행시간이 더 짧더라도 선점되지 않도록 함

4) HRRN (Highest Response Ratio Next) 스케줄링

- 수행시간이 긴 프로세스의 무한 대기 현상을 방지하기 위한 기법

- 준비 큐에 있는 프로세스들 중에서 응답률이 가장 높은 우선순위를 줌

- 비선점 방식

- 응답률 = (대기시간 + CPU 요구량) / CPU 요구량

- 프로세스가 기다리는 시간이 길어질수록 우선순위가 높아지므로 곧 CPU 할당받을 수 있음

5) 라운드 로빈 (Round-Robin) 스케줄링

- FCFS 스케줄링을 기반으로 하여 CPU를 할당히되, 각 프로세스는 시간 할당량이 지나면 시간 종료 인터럽트에 의해 CPU 뺏기는 방식

- 선점 방식

- CPU를 반환한 프로세스는 다시 준비 큐의 끝에 들어가게 되고, 준비 큐의 맨 앞에 있는 프로세스가 CPU 선점

- ex)

- 위 프로세스들이 거의 동시에 도착했고, 시간 할당량이 10ms 일 때

- P1 (10) → P2 (8) → P3 (10) → P4 (10) → P1 (10) → P3 (5) → P1 (10) 순서로 CPU 할당 받음

- 평균 응답시간 = (63 + 18 + 53 + 38) / 4 = 43

- 평균 대기시간 = (33 + 10 + 38 + 28) / 4 = 27.25

- 한 프로세스가 CPU를 독점하는 단점을 방지할 수 있지만, CPU 선점에 따른 문맥교환의 오버헤드 감수해야 함

- 오버헤드: 문맥교환에 필요한 시간, 메모리 등

- 오버헤드에도 불구하고 이 기법은 대화식 시스템이나 시분할 시스템에 적합한 방식으로 알려져 있음

- 시간 할당량의 크기에 따라 시스템의 성능이 크게 달라질 수 있음

- 시간 할당량이 매우 크면 FCFS 방식과 같아지게 되며, 작을수록 문맥교환이 자주 발생하므로 문맥교환의 오버헤드가 커짐

- 일반적으로 시간 할당량은 10~100ms가 적당

- 연산 위주의 프로세스가 입출력 위주의 프로세스보다 우대받고 있음

- 입출력 위주 프로세스는 대부분 시간 할당량을 남긴 채 입출력을 발생시킨 다음 입출력이 완료되면 당시 남겨진 시간 할당량을 보상받지 못한 채 큐의 맨 뒤로 들어감 

→ 입출력을 마친 프로세스가 들어가는 준비 큐를 따로 하나 두고 우선순위는 더 높게 하되, 이 큐에서 CPU를 받을 때에는 이전 입출력을 발생시켰을 때 남긴 시간 할당량만큼만 주도록 하는 방식이 있음 : 가상 라운드 로빈 방식

- 프로세스가 생성될 때 부여된 우선순위가 완료 때까지 변하지 않는 값 → 정적 우선순위

- 시스템에 있는 동안 조정되도록 → 동적 우선순위

6) 다단계 큐 (Multi-level Queue) 스케줄링

- 정적 우선순위를 사용하는 선점 방식

- 우선순위의 개수만큼 큐 필요 → 같은 우선순위를 가지는 프로세스끼리 큐에 들어감

- 큐들 간에 프로세스 이동 불가능

- 우선순위가 낮은 하위 단계 큐의 작업은 실행 중이더라도 상위 단계 큐에 프로세스가 도착하면 CPU 뺏김

7) 다단계 피드백 큐 (MFQ, Multi-level, Feedback Queue)

- 프로세스들의 CPU 요구량을 몰라도 짧은 프로세스들에게 유리하면서 입출력 프로세스를 우대할 수 있는 기법

- 입출력 프로세스 우대 → 짧은 연산 후 입출력 발생하면 CPU는 다른 프로세스에게 주어지고 입출력 작업과 병행되어 시스템 성능 향상

- 동적 우선순위를 기반으로 하는 선점 방식

- 우선순위 개수만큼 큐가 있으며 각 단계마다 서로 다른 CPU 시간 할당량을 가지도록 함

- 우선순위가 높은 단계의 큐일수록 시간 할당량 작도록 함

- 새로운 프로세스는 최상위 단계의 준비 큐에 들어간 후 FCFS의 순서로 CPU를 할당받아 실행되다가 그 큐의 시간 할당량이 끝나면 한 단계 아래의 준비 큐에 들어감으로써 우선순위가 한 단계 낮아짐

- 각 단계에서도 그 단계 큐의 시간 할당량을 다 사용할 때까지 계속 실행된다면 다음 단계의 큐로 들어감

- 마지막 단계에서는 라운드 로빈 방식으로 실행 (시간 할당량이 지나면 다음 프로세스에게 CPU 할당, 준비 큐 맨 뒤로 들어감)

- 어떤 단계에서든 시간 할당량이 끝나기 전에 입출력 등으로 CPU를 내놓게 되면 다시 준비 상태가 되었을 때 한 단계 위의 큐에 들어가도록 함으로써 우선순위를 높여줌

- 중간 단계의 맨 앞에 있는 프로세스는 상위 단계의 큐들이 비어있는 경우에만 CPU를 받을 수 있고, 시간 종료 인터럽트에 의해 선점되거나 입출력이 발생하지 않는 한 그 큐의 시간 할당량까지 쓸 수 있음

- 일단 CPU를 받은 프로세스는 실행 중 상위 단계의 프로세스에 의해 선점되지 않고 부여받은 시간 할당량까지는 보장됨

- 상대적으로 짧은 프로세스들이 하위 큐까지 내려가지 않도록함으로써 비교적 높은 우선순위를 유지할 수 있도록 함

- 입출력은 우선순위의 상향조정으로 이어져 우대받음을 알 수 있음

- Behavior Adaptive 스케줄링

- 변형)

- 각 단계에서 시간 할당량을 다 쓸 경우 그 단계의 큐에서 몇 번의 순환 후 다음 단계로 떨어뜨림

- 입출력의 완료 시 단계의 상승 폭을 더 크게 줌 

- 현재 큐에서 대기한 시간이 일정 시간을 넘기면 상위 큐로 이동시켜 줌

8) Fair-share 스케줄링

- 프로세스들의 특성이나 중요도에 따라 몇 개의 그룹으로 나누고, 각 그룹에 할애된 일정량의 CPU 시간은 그 그룹에만 영향을 미치도록 함

- ex)

- 1(A B) 2(C D) 3(E F)

- 1그룹에는 CPU 시간의 50%, 2그룹과 3그룹에는 각 25% 할당

- ACBEADBF의 순서대로 스케줄을 하거나, A에게 많은 시간을 주어야 할 경우 B를 줄이고 A를 늘리는 등 타 그룹에는 영향이 가지 않도록

4. 실시간 Realtime 스케줄링

- 실시간 시스템: 실행될 모든 프로세스들이 정해진 시간 내에 완료되어야 하는 시스템

- 경성 실시간 시스템

    - 작업이 마감시한 내에 완료되지 않으면 치명적인 결과를 초래하는 시스템 (시스템이 중지되는 등) 

    - 마감시한을 넘긴 후 완료되는 일은 아무 가치가 없음

    - 일반적으로 실시간 시스템은 경성 실시간 시스템을 말함

- 연성 실시간 시스템

    - 작업이 마감시한 내에 종료되지 않으면 데이터의 손실 등 피해가 발생하지만 시스템은 계속 운영 가능한 시스템

    - 마감시한을 넘긴 후부터는 완료의 가치가 점점 떨어짐

- 정적인 방법:  프로세스들의 특징과 개수를 알 수 있는 경우에 유용

- 동적인 방법: 프로세스의 생성 시간이나 특성을 알 수 없는 경우에 사용

- 실시간으로 운영되는 환경은 대부분 특수한 상황으로, 실행되어야 할 일들의 성격이나 개수를 사전에 알 수 있는 경우가 많음

1) RM (Rate Monotonic) 알고리즘

- 대표적인 정적 스케줄링 방식

- 크기와 개수가 알려진 프로세스들이 각자 주기적으로 발생되는 환경에서 사용

- 프로세스는 서로 독립적이고 주기적으로 수행되는 환경에서 각 프로세스의 마감시한은 각자의 주기와 같다고 가정

- 주기가 짧을수록 높은 우선순위 받음

- 낮은 우선순위의 프로세스가 더 높은 우선순위의 프로세스가 도착할 경우 CPU를 뺏기는 선점 방식

- 정적 환경에서 최적의 기법으로 알려져 있음

- n개로 구성된 프로세스 집합이 있을 때, 이 프로세스들에 의한 CPU 사용률 U는 아래와 같음

- U = U1 + U2 + ... Un = C1/P1 + C2/P2 + ... + Cn/Pn ≤ n(2^(1/n) - 1)

- 이 식이 만족되면 RM 기법으로 모든 프로세스의 마감시한을 맞출 수 있는 스케줄링이 가능하다는 것이 알려져 있음

- 1보다 작거나 같을 경우 될 수도 있고 안될 수도 있으며, 1보다 큰 경우엔 불가능함

- P는 주기, D는 마감시한, C는 크기(수행시간)

- 스케줄링 비용이 적게 드는 대신, 새로운 프로세스가 추가되는 환경에 바로 적응하지 못하고 전체 스케줄링을 다시 해야하는 단점

- ex) 

- T1의 주기가 짧으므로 먼저 시작

- T1 (2) → T2 (1) // 3 → T1 (2) → T2 (1) // 6

- T1과 T2 모두 주기 내에서 일이 완료되었기 때문에 성공

- U = 2/3 + 2/6 = 1

2) EDF (Earliest Deadline First) 알고리즘

- 프로세스 마감시한이 가까울수록 우선순위 높게 부여하는 선점 방식의 동적 스케줄링

- 동적: 새로운 프로세스가 도착할 때 바로 대응할 수 있음

- 우선순위에 의해 실행 중 CPU 뺏길 수 있음

- 한 프로세스의 실행이 완료될 경우 마감시한이 가장 가까운 것을 찾아 스케줄

- 모든 프로세스가 주기적일 필요는 없으며, 주기가 있을 경우에는 마감시한을 주기로, 그렇지 않을 경우는 마감시한이 알려져야 함

- n개의 프로세스가 있을 때 아래와 같은 조건이 성립한다면 EDF 기법으로 가능한 스케줄이 존재

- C1/P1 + C2/P2 + ... + Cn/Pn ≤ 1

- 새로운 프로세스의 동적인 수용이 허용되나, 그럴 때마다 가능한 스케줄을 찾기 위한 계산을 해야하는 부담 존재

- ex)

- P1 (4) → P2 (3) → P3 (10) → P1 (4) //21

- P1이 수행되다가 4초 후에 마감 시간이 더 짧은 P2가 들어오면 P2가 CPU를 선점

- 1초 후에 P3가 들어오지만 여전히 P2의 마감 시간이 더 짧기 때문에 P2 수행 완료

- 그 다음 P3가 20초 내에 종료되어야 하기 때문에 P3 실행

- P3 종료 후 P1 마무리 → 성공

[수업출처] 숙명여자대학교 소프트웨어학부 김주균 교수님 '운영체제' 수업 & [OS? Oh Yes!]

1. 프로세스

- 시분할 시스템에서 메모리의 한 부분을 차지하는 작업, 동시에 CPU라는 자원을 분배해 주어야 하는 대상이 되는 작업들

- CPU를 할당받는 단위이자 주어진 자원들의 소유자로서의 역할

- 수행 중인 프로그램 = 프로그램과 데이터를 기본으로 정상적인 실행을 위해 필요한 환경을 시스템으로부터 부여받은 능동적인 존재

2. 프로세스 제어 플록(PCB)

- 프로세스에 대한 모든 것을 표현하는 테이블 형태의 자료구조

- 프로세스 하나가 만들어진다는 것은 PCB 하나가 만들어진다는 말과 같음

- 운영체제가 프로세스를 관리한다는 것은 해당 PCB에 대한 행동(생성, 수정, 관련 리스트 연결, 삭제 등)

- 기본적으로 메모리에 저장

- 프로세스 번호, 프로세스 상태(준비, 실행, 대기, 보류 등), 프로세스 우선순위, 프로그램 카운터 값(PC), 메모리 포인터, 문맥 데이터, 할당받은 자원들에 대한 목록, 계정 정보, 입출력 정보 등

3. 프로세스 상태 변화

1) 생성

- 사용자가 요청한 작업이 커널에 등록되고 PCB가 만들어져 프로세스가 만들어진 다음, 준비나 보류 준비 상태로 되기 위해 잠시 거치는 상태

- 메모리 공간을 검사하여 충분한 공간이 있으면 메모리를 할당하며 준비 상태로 바꿔주고, 그렇지 못할 경우 보류 준비 상태로

2) 준비

- CPU를 할당받기 위해 기다리고 있는 상태

- CPU만 주어지면 바로 실행할 준비가 되어있는 상태

- 큐 또는 리스트가 사용됨

3) 실행

- CPU를 할당(Dispatch)받아 실행 중인 상태

- 단일 CPU 시스템에서는 한 개의 프로세스만 실행 상태에 있음

- CPU 스케줄링 정책에 의해 CPU를 뺏길 수 있으며 이 경우 준비 상태로 바뀜

- 시간 할당량이 소진되어 CPU를 뺏기는 경우를 시간 종료라고 함 → 인터럽트가 동원되어 처리

- 입출력이 필요하여 시스템 호출을 하면 대기 상태로 바뀌게 되고, 준비 상태의 프로세스 중 하나가 다음으로 실행됨

4) 대기

- 프로세스가 실행되다가 입출력 처리를 요청하거나, 바로 확보될 수 없는 자원을 요청할 때

- CPU를 양도하고 요청한 일이 완료되기를 기다리며 대기하는 상태

- 큐 또는 리스트가 사용됨

- 요청한 일이 완료되면 준비 상태로 바뀌면서 CPU를 기다림

5) 종료

- 프로세스가 종료될 때 아주 잠시 거치는 상태

- 할당되었던 모든 자원들이 회수되고 PCB만 커널에 남아있는 상태

- 운영체제가 시스템에 남아있는 프로세스의 흔적들을 최종 정리 후 PCB를 삭제하면 프로세스가 완전히 사라짐

- 준비, 실행, 대기 상태 → 활성 상태: 메모리 공간의 일정량 부여받음

- 활성 상태에 있는 프로세스 개수: Multi-programming degree

- 메모리가 부족하거나 다른 이유에 의해 메모리를 회수당한 경우 → 보류 상태

- 보류 상태) PCB는 메인 메모리에 저장, Multi-programming degree - 1

6) 보류

- 프로세스가 메모리 공간을 뺏기고 디스크로 나가는 경우

- 이 경우 스왑되어 나간다고 하고(Swapped Out), 다시 메모리로 들어오면 스왑되어 들어온다 함(Swapped In) → Swapping

- 보류 준비 상태

    - 생성된 프로세스가 바로 메모리를 받지 못할 때나,

    - 준비 또는 실행 상태에서 메모리를 잃게 될 때를 위해 필요

    - 실행 상태의 프로세스가 CPU를 반납하면서 준비 상태로 바뀔 때 메모리까지 잃어야 하는 경우(Suspended)

    → 충분한 메모리 공간의 확보를 위해 준비 상태의 프로세스를 보류시킬 수밖에 없는 경우   

    → 높은 우선순위의 보류 대기 상태 프로세스가 준비 상태가 되면서 실행 상태의 프로세스로부터 CPU를 뺏는 경우

    - 메모리의 여유가 생기거나 준비 상태의 프로세스가 전혀 없을 때 대기 상태의 프로세스를 보류 대기로 만들고, 메모리 공간이 확보되면 준비상태로 바뀌게 됨(Resume) → Swapping

- 보류 대기 상태

    - 대기 상태일 때 메모리 공간을 잃은 상태

    - 준비 상태의 프로세스가 아예 없어 대기를 보류 대기로 만드는 경우

    - 준비 상태의 프로세스가 있었다고 해도 메모리의 여유 공간을 더 확보하기 위해 

    - 특별한 경우가 아니면 입출력이나 기다리던 사건의 종료 시 보류 준비 상태가 됨

    - 메모리의 여유가 생겼을 때 대기시켰던 원인이 곧 해소될 것으로 판단되는 프로세스가 보류 대기 상태에 있는데, 보류 상태 중인 어떤 프로세스보다 우선순위가 높은 경우에는 그 프로세스에게 메모리를 주고 대기 상태로 만드는 것이 더 효과적일 것

- 보류 상태의 필요 이유

    - 일차적으로 메모리 공간의 확보를 위해

    - 실행되는 프로세스의 현재 결과가 바라던 것이 아닌 오류가 보일 때

    - 시스템에 위해를 가할 수 있는 수상한 행동을 보일 때

    - 주기적인 일이어서 다음 주기의 실행 때까지 메모리를 회수해도 문제되지 않을 때 등

4. 문맥교환

- 프로세스의 상태 변화는 인터럽트에 의해 처리됨

- 인터럽트 이전에 실행되던 프로세스가 인터럽트 처리 후에 계속 실행될 때도 있고, 다른 프로세스로 CPU가 할당될 때도 있음

- 인터럽트 처리 전후의 프로세스가 같은 경우 문맥교환을 위해 필요한 양이 적음 (PCB의 일부분만 보관)

- 다른 경우 문맥의 저장, PCB에서 관련 데이터들의 변경과 함께 PCB를 적절한 상태의 큐로 옮기기, 스케줄링, 그 프로세스의 PCB 변경과  문맥의 복원 등이 필요함

- 모드 스위칭: 인터럽트 처리 전후의 프로세스가 같은 경우 (사용자 모드 - 커널 모드의 변경만 생김)

- 프로세스 스위칭(문맥교환): 인터럽트 처리 전후 프로세스가 다른 경우

5. 스레드 Thread

- 하는 일은 서로 다르지만 관련 있는 작은 일들이 모여 프로세스를 구성한 경우, 세분된 작은 일들을 스레드라 함

- 프로세스는 부여된 자원의 소유자로서, 스레드는 스케줄링의 단위(CPU를 할당받는 단위)로서 존재

- 프로세스가 가지는 자원을 공유하면서, 각자는 자신의 실행환경(프로그램 카운터로 표현되는 현재 실행 위치, 스택, 레지스터 값)을 따로 가짐

- 다중 스레딩: 하나의 프로세스를 다수의 스레드로 만들어 실행하는 것

- 다수의 실행 단위들이 존재하여 작업의 수행에 필요한 자원들을 공유하기 때문에 자원의 생성과 관리가 중복되는 것을 줄일 수 있음

- 다중 스레딩에서 프로세스란 보호와 자원의 할당 단위

- 프로세스의 코드와 데이터를 수용하기 위한 가상주소 공간과 CPU, 다른 프로세스의 파일들, 입출력에 사용되는 자원에 대한 보호된 액세스를 보장하기 위한 단위

- 스레드 각각은 스레드의 수행 상태, 예를 들어 실행, 준비 등과 실행 상태가 아닐 경우를 위한 스레드 문맥, 각자의 실행 스택, 자신이 속한 프로세스가 가지는 메모리와 자원에 대한 접근 권한을 가짐

- 한 스레드에 의해 메모리의 데이터가 변경될 경우 다른 스레드들은 변경된 데이터를 사용하게 됨

- 열린 파일은 다른 스레드들에게도 열린 상태로 사용됨

- 단일 스레드 프로세스: PCB, 사용자 주소 공간, 사용자 스택과 커널 스택

- 다중 스레드 프로세스

    - 프로세스) PCB, 사용자 주소 공간 : 스레드들과 공유

    - 스레드) 스레드 제어 블록, 사용자 스택과 커널 스택

- 스레드의 생성, 삭제, 스위칭에 소요되는 시간과 비용이 프로세스 단위로 이루어질 때보다 빠르고 저렴

- 프로세스 간의 통신은 커널의 개입을 필요로 하지만, 한 프로세스 내 스레드 간 통신은 커널의 개입이 필요없음

- CPU 스위칭을 위한 스레드 단위의 자료는 유지되어야 하며, 프로세스 단위로 행해지는 보류, 종료 등은 전체 스레드에 동일한 영향 미침

6. 스레드 상태와 동기화 Synchronization

- 스레드 역시 실행, 준비, 대기의 상태를 가짐 (메모리 자원은 프로세스 단위로 할당되기 때문에 보류 상태는 없음)

- 대기는 레지스터 값, 프로그램 카운터(PC), 스택 포인터 등의 보관이 요구되며, 스레드의 종료는 해당 스레드의 레지스터 값들과 스택을 없앰

- 주소 공간과 자원 공유 → 특정 스레드가 변경시킨 내용이 다른 스레드에 바로 영향 미침

- 상호 간의 간섭이나 데이터 파괴 등을 방지하기 위한 스레드 실행의 동기화가 요구됨

→ 프로세스 간의 동기화에서 발생하는 문제와 해결책과 동일

7. 스레드의 종류

1) 사용자 레벨 스레드 

- 스레드 라이브러리에 의해 관리됨

- 스레드 라이브러리의 메모리에서의 위치는 사용자 공간

- 스레드와 관련된 모든 행위는 사용자 공간에서 이루어지므로 커널은 스레드의 존재를 알지 못함

- 커널은 스레드들의 행위를 프로세스의 행위로 인식함

- 스레드 라이브러리는 스레드의 생성, 소멸을 위한 코드와, 스레드 간의 메시지나 데이터의 전달, 스레드의 스케줄링, 스레드 문맥의 보관, 재 저장 등을 담당

- 스레드를 지원하지 않는 운영체제에서도 사용 가능

- 특정 스레드의 실행에서 대기는 소속된 프로세스의 대기 초래

- 당시 실행중이던 스레드는 지금 실제로 실행 중이 아니지만 스레드 라이브러리에 의해 실행으로 계속 간주되고 있다가 나중에 CPU가 다시 이 프로세스에 할당되었을 때 계속 실행해 나갈 수 있도록 해줌

- 스레드의 실행 중 프로세스의 시간 초과가 될 경우 커널은 프로세스의 스위칭 수행

- 당시 실행중이던 스레드 역시 실행 상태로 유지되다가 프로세스가 CPU 받으면 다시 실행됨

- 스레드의 스위칭 도중 프로세스 스위칭이 일어나도 CPU를 다시 받았을 때 스레드의 스위칭이 계속 진행되도록 함

- 스레드 스위칭에 커널의 개입 필요 없음 (모드 스위칭 필요 없음)

- 스레드 간의 스위칭 시 운영체제가 정한 스케줄링(프로세스 스케줄링)에 따를 필요 없고, 응용 별로 독자적인 스케줄링 사용할 수 있음

- 스위칭은 스레드 라이브러리에 있는 스위칭 프로그램에 의해 결정됨

- 특정 스레드의 대기가 프로세스 내의 모든 스레드들의 대기를 초래하며, 다중처리 환경이 주어진다해도 스레드 단위의 다중처리가 되지 못한다는 단점 (CPU는 프로세스 단위로 할당되기 때문)

2) 커널 레벨 스레드

- 모든 스레드의 관리를 커널이 하는 경우

- 스케줄링은 커널에 의해 스레드 단위로 이루어지므로 사용자 레벨 스레드의 단점을 극복할 수 있음

- 다중처리의 환경일 경우 한 프로세스 내의 다수 스레드는 각각 CPU를 할당받아 병렬 실행 가능

- 한 스레드의 대기 시 같은 프로세스에 속한 다른 스레드로 스위칭 가능

- 같은 프로세스에 속한 스레드 간의 스위칭에도 커널의 개입 필요 → 모드 스위칭 요구됨

- 커널 레벨 스레드라 해도 다중처리가 아닌 환경이라면 어차피 하나밖에 없는 CPU를 가동하기 때문에 시간적인 차이가 없을 것이라고 생각할 수 있음

- 단일 처리기 환경에서 다른 서버에 있는 프로시저 호출하고 그 다음 또 다른 서버에 있는 프로시저 호출하는, 즉 두 번의 순차적인 원격 프로시저 호출(RPC)을 수행하는 일을 할 때

- 스레드 없이 프로세스로 한 경우는 RPC 이후 서버로부터 결과를 받을 때까지 기다린 후 다음 RPC 호출을 실행함

- 스레드가 있는 경우 첫번째 호출을 한 스레드에게 맡기고 대기가 될 때 바로 다른 스레드를 실행시켜 두번째 호출을 실행함

- 두 개의 스레드가 대기 중인 시간대가 중복된 만큼 전체 일의 종료 시간이 앞당겨짐

[수업출처] 숙명여자대학교 소프트웨어학부 김주균 교수님 '운영체제' 수업 & [OS? Oh Yes!]

1. OS의 목적

- 사용자와 컴퓨터 사이의 가교 역할 → 사용자가 컴퓨터를 보다 편리하게 사용할 수 있도록 함

- 컴퓨터 시스템의 자원들을 효율적으로 사용될 수 있게 해야 함

- 사용자의 입장에서는 사용하기 쉽고 편리하며, 배우기 쉽고 신뢰할 수 있으며 빨라야 함

- 만드는 사람의 입장에서는 설계, 유지, 보수가 쉽고 적응성이 좋으며 오류없이 효율적이어야 함

- 경우에 따라 모두 가질 수 없는 경우가 많기 때문에 사용되는 환경에 맞춰 순위에 따라 합의해야 함

2. 부팅

- 전원이 꺼져있는 시스템에서 운영체제 전부는 디스크에 저장되어 있음

- 전원이 켜지면 운영체제의 일부인 '커널'이 메모리에 올라와 실행됨

→ 장치 준비, 각종 레지스터 값 초기화, 사용자의 입력 받을 준비 완료 → '부팅되었다'

- 이때 동원되는 것이 부트 프로그램(부츠트랩 로더), 대개 ROM에 저장되어 있음 → 전원이 켜지면 무조건 제일 먼저 실행됨

→ 커널을 찾아 메모리에 올린 후 실행시키는 역할

3. 레지스터

- CPU에 내장되어 있는 메모리보다 빠른 기억장치

- 시스템과 사용 목적에 따라 8비트, 16비트, 32비트 등의 크기 가짐

- 일반적으로 데이터, 주소, 조건 코드 레지스터 등이 있음

    - 데이터 레지스터: 연산 (메모리보다 빠름)

    - 주소 레지스터: 데이터나 명령어의 메모리 주소 저장하거나 계산

        - 인덱스 레지스터: 주소 지정

        - 세그먼트 포인터, 스택 포인터: 해당 포인터 값 저장

- CPU 연산 제어하기 위한 레지스터

    - MBR, MAR, IR, PC 등

- 모든 CPU는 현재 상태 정보를 저장하기 위해 프로그램 상태 워드(PSW)라는 레지스터 가짐

    - 여러가지 조건(condition)코드와 함께 인터럽트 가능, 불가능을 표시하는 비트, 현재 실행 모드를 나타내는 비트 등 포함

4. 명령어 처리

- 명령어 반입: 레지스터를 이용하여 메모리에 있는 명령어를 읽어 처리기에 있는 레지스터로 갖고 옴

- 연산 종류 파악, 실행 → 하나의 명령어 처리

- 반입에서 다음에 실행해야 할 메모리에 있는 명령어의 주소는 PC 레지스터가 갖고 있음

5. 인터럽트

1) 폴링(Polling)

- 컴퓨터 시스템의 각 자원들의 현 상황을 파악할 수 있는 방법 중 하나

- CPU가 일정한 시간 간격을 두고 각 자원들의 상태를 주기적으로 확인하는 방식

- 자원들은 폴링 신호를 받은 후 자신의 상태나 원하는 바를 CPU에게 알려줌

- 폴링의 간격을 정해야 하며, 각 자원들은 직전 폴링 이후 변화된 상태를 다음번 폴링 때까지는 알릴 수 없다는 단점

- 아무 일이 없을 때에도 CPU는 폴링에 일정량의 시간을 들여야 한다는 부담

2) 인터럽트

- 각 자원들이 능동적으로 자신의 상태변화를 CPU에게 알리는 방식

- CPU는 따로 시간을 들이지 않아도 되고, 자원들은 상황을 즉시 알려 처리받을 수 있음

- 오늘날 거의 대부분의 시스템에서 채택하고 있음

- 하드웨어 인터럽트: 장치 또는 주변장치들로부터의 인터럽트

- 소프트웨어 인터럽트: CPU 스스로 자신에게 인터럽트(=trap) (명령어 때문), 입출력할 때 시스템 콜

3) 인터럽트 처리 과정

- 장치가 CPU에 인터럽트 신호 전송 → 명령어 실행중이라면 명령어 실행을 우선 완료시키고 인터럽트 신호 확인 → 인터럽트 처리 루틴 실행 전, 실행중이던 프로그램의 현 상태 정보(PSW, PC 레지스터 값 등)를 시스템 스택에 저장 → 인터럽트 처리 루틴의 시작 주소를 PC에 넣어 실행 → 인터럽트 처리 루틴 실행

- 인터럽트 처리 루틴: CPU에 있는 레지스터들의 값 저장 → 필요한 인터럽트 처리

- 인터럽트 처리가 끝나면 이전에 저장했던 레지스터 값들 다시 재저장, PSW와 PC 값 원래 자리에 넣어주고 실행 → PC에 들어가있는 값이 인터럽트 이전에 실행 중이던 프로그램에서 다음에 실행할 명령어 위치 → 프로그램 실행 이어나감

4) 중첩된 인터럽트의 처리

- 순차적 처리: 인터럽트를 처리하는 동안 발생하는 인터럽트는 현재 처리가 끝난 뒤 차례대로 하나씩 처리해줌

- 중첩 처리: 현재 처리 중인 인터럽트를 잠시 접어두고 또 다른 인터럽트로 실행을 옮길 수 있음

- 인터럽트의 중요도에 따라 우선순위가 더 높은 경우에는 중첩을, 그렇지 않은 경우는 순차적으로 구현하는 방법

6. 기억 장치의 계층적 구조

[자기테이프 - 광디스크 - 자기디스크 - 전자디스크 - 주기억장치 - 캐시 - 레지스터]

- 보통 속도와 가격은 비례하기 때문에 용도에 맞게 적절히 저장장치를 계층적으로 구성하는 타협 필요

- 상위계층에 있을수록 속도와 가격이 올라감

- CPU에 의해 처리되어질 명령어나 데이터가 상위에 있을수록 시스템의 성능은 좋아짐

- 프로그램 또는 데이터는 평소에는 하위계층에 저장되다가 실행시에 적당량이 상위계층과 하위계층으로 번갈아 교체되어지면서, CPU는 최대한 상위계층으로 접근하도록 만들어 처리 속도를 높임

- 프로그램이 실행되기 위해서는 반드시 주기억장치(메모리)에 있어야 함

- 메모리에 있는 프로그램의 일부분이 다시 캐시로, 그 중 실행되어질 명령어는 처리기 레지스터에 적재되어 실행됨

- 메모리 관리를 어떻게 하느냐에 따라 시스템의 성능 좌우 → 운영체제의 역할 중요

7. I/O 방식 (입출력 방식)

- 하나의 입출력 장치에는 컨트롤러가 있고, 여기에는 CPU와 입출력 데이터를 저장하는 버퍼 존재

[CPU의 개입 정도에 따라]

1) 프로그램에 의한 입출력

- CPU는 입력을 지시한 후 워드가 컨트롤러의 버퍼에 입력되었는지 계속 확인

- 인터럽트가 필요없는 대신 CPU가 지속적으로 완료 여부 확인해야 함 

→ 전체 입출력 완료될 때까지 CPU 낭비됨

2) 인터럽트에 의한 입출력 

- 입력을 지시한 후 입력이 이루어지는 사이에 CPU는 다른 작업에 활용됨

- 입력 완료 시 인터럽트를 통해 CPU에 알림

- 프로그램에 의한 입출력 때의 CPU 낭비 없앨 수 있음

- 버퍼의 크기에 비해 입출력할 데이터가 클수록 잦은 인터럽트 처리가 요구됨

3) 메모리에 직접 접근하는 입출력(DMA)

- 인터럽트에 의한 입출력에서 인터럽트가 호출되는 횟수를 줄이고자 한 방식

- 입출력 작업을 CPU 대신 해줄 수 있는 '채널'이라는 위성 프로세서 필요

- CPU는 입출력할 데이터의 시작주소와 크기 등을 채널에게 알려주고 다른 작업에 동원됨

- 이때부터 입출력은 채널의 주도하에 이루어짐

- 일반적으로 한 번의 입출력 단위를 블록이라고 부르며, 채널은 블록 단위로 CPU에게 인터럽트를 보내 알림

- CPU와 채널이 동시에 메모리에 접근할 때, 메모리는 한 번에 하나의 접근만 허용하기 때문에 둘 중 하나를 결정해야 함

- Cycle Stealing: 일반적으로 속도가 빠른 CPU가 평소 메모리 접근 기회를 더 많이 가지기 때문에, 이때는 채널에게 기회를 주는 것이 공평하다고 보고 설계함

[하드웨어의 구성에 따라]

1) 독립적인 입출력

- 입출력 장치들이 입출력 버스(I/O Bus)를 통해 CPU와 연결되어 있는 경우

- 메모리는 따로 메모리 버스를 통해 연결되어 있음

- 입출력은 입출력을 담당하는 명령어를 통해 실행되는데, 입출력 버스를 통해 해당 장치의 지정, 데이터, 입출력을 구분해주는 제어값이 전달됨

- 입출력 명령어가 명령어 집합에 추가되므로 제어 로직이 복잡해지고, 입출력 버스를 장착하는데 추가 비용이 드는 단점

2) 메모리 주소지정 입출력

- 입출력 장치들이 메모리와 함께 메모리 버스에 연결되어 있음

- 입출력을 위한 명령어를 따로 두지 않고, 메모리에 대한 명령어(MOVE, LOAD 등)를 사용하여 실제 입출력 실행

- 입출력 장치들은 각각 메모리의 한 번지를 할당받아, 메모리에 대한 명령어로 그 번지에 해당하는 장치로의 입출력이 되도록 하는 것

- ex) 입출력 장치 2개, 주소의 크기가 3비트(0~7번지)라면 메모리는 0번지부터 5번지를 가는 크기이고, 6, 7번지는 입출력 장치를 나타내도록 하는 것인데 주소 공간만큼의 메모리를 활용할 수 없다는 단점이 있음

출처) 숙명여자대학교 소프트웨어학부 김주균 교수님 '운영체제' 수업 & [OS? Oh Yes!] , 220303

1. 운영체제

- 컴퓨터의 여러 응용 프로그램을 설치되게 해주고, 여러가지 장치를 효율적으로 작동하도록 하며, 사용자가 컴퓨터를 손쉽게 이용할 수       있도록 해주는 프로그램의 집단

- 하드웨어의 여러 부분을 건드리는 경우가 많기 때문에 하드웨어에 의존적인 경우가 많고, 따라서 이전에는 하드웨어 회사마다 자신만의 OS를 갖고 있었음

- 크게 사용자 인터페이스(User Interface)와 자원 관리(Resource Management)를 위한 프로그램의 집합으로 설명할 수 있음

2. 운영체제 변천사

    2-1. 수동식 계산기

    - 기원전 3000년 경 중국에서 발명된 주판이 발판이 됨

    - 존 네피어 봉, 파스칼의 톱니바퀴 계산기, 라이프니츠의 계산기 등

    - 이 당시에 운영체제는 존재하지 않았음

    2-2. 자동식 계산기

    - 배비지의 증기기관으로 작동되는 해석장치를 시작으로 홀러리스의 천공기 등이 있으며

    - 에이컨의 MARK Ⅰ은 23자리 숫자의 가감을 매초 3회, 곱셈은 3초에 1회씩 계산이 가능했음

    - 이 때에도 운영체제는 없었으며 소수의 기술자에 의해 수동으로 조작되었음

    2-2-1. 1세대 운영체제 (1940-1950)

    - 진공관 컴퓨터 시기

    - ABC(45개의 진공관) → ENIAC(최초의 컴퓨터) → EDSAC(폰 노이만 2진 부호 체계) → UNIVAC-Ⅰ → IBM 701 → IBM 305(자기 디스크 장치 채택) 등 

    - IBM 701에 와서 비로소 운영체제의 효시라 할 수 있는 기능 장착됨 → "일괄처리 시스템"

일괄처리 시스템 (Single-stream Batch Processing Systems)
- 다수 개의 프로그램을 읽어 저장해놓되, 한 번에 한 개씩의 프로그램을 실행시키는 방식
- 다음 작업을 처리할 때의 시간 절약

Batch
- 초창기: 작업이 차례대로 한 개씩 처리된다는 뜻. 한 개의 작업이 시작되면 그 작업이 끝날 때까지 다른 작업은 기다려야 함
- 이후: 일괄처리를 하되 다중 프로그래밍을 하는 Batch로 발전함
- 작업이 끝날 때까지 사용자의 중간 개입이 허용되지 않음

    2-2-2. 2세대 운영체제 (1960년대 전반기)

    - 트랜지스터 컴퓨터 + 자기코어 기억장치(주기억장치로 사용), 자기 디스크 팩(보조기억장치로 사용)

    - UNIVAC-Ⅱ → IBM 1400시리즈(크기 축소, 속도 증가)

    - 어셈블리언어, FORTRAN, COBOL 등 등장

    - 운영체제는 컴퓨터에 장착된 다양한 주변기기들을 효율적으로 관리하는 데 관심

    - Multiprogramming System & MultiProcessing System

    - Timesharing System & Interactive System

    - Realtime System

폰 노이만의 "내장 프로그램" 개념
- 어떠한 작업도 실행되기 위해서는 주기억장치에 있어야 한다.

다중 프로그램 시스템 (Multiprogramming System)
- 다수 개의 작업을 CPU에 넣어놓는 방식

다중 처리 시스템 (Multiprocessing System)
- 여러 개의 처리장치(CPU)를 장착하여 동시에 여러 작업을 병렬로 실행하는 방식
- CPU가 2개 이상

다중 처리 시스템은 여러 작업이 동시에 진행된다고 하였지만, 실행이 될 때 주기억장치에 있어야하기 때문에
다중 처리를 위해서는 다중 프로그래밍이 필요하다.

시분할 시스템 (Timesharing System)
CPU가 처리할 수 있는 시간을 작업 수에 맞춰 분할하여 각자에게 일정량만큼씩 분배하여 번갈아가며 처리하는 방식
시분할 시스템을 위해서는 다중 프로그래밍이 필요하다.

대화식 시스템 (Interactive System)
시분할 시스템으로 사용자에게 바로바로 응답할 수 있게 되었다.
→ 모니터, 키보드, 마우스 등을 이용해 시스템과 사용자가 대화하듯이 일을 처리해가는 방식

다중 프로그램 시스템으로 인해 시분할 시스템이 가능하게 되었고, 시분할 시스템을 위해 대화식 시스템이 필요하다.

2.2.3. 3세대 운영체제 (1960년대 후반기 - 1970년대)

- 집적회로(IC)의 개발 -> CPU에 적용

- 범용 컴퓨터 시스템 -> 컴퓨터 다양한 용도로 사용됨

- IBM 360계열: batch 시스템 기본적으로 탑재

- DEC: interactive 시스템 탑재

- 다중모드 시분할 시스템(Multi-inmode)

    - 일괄처리(batch), 시분할(time-sharing), 실시간 작업(real-time) 모두 지원

    - 기본적으로 시분할, 필요한 경우 batch, 실시간 등 지원함

- TCP/IP 표준과 함께 근거리 통신망(LAN) 등장

- UNIX 운영체제 출현

    - UNIX 이전에는 각 하드웨어마다 운영체제 존재, 소스코드 비공개

    - 소스코드 공개로 자연스럽게 널리 퍼져서 다양한 버전이 탄생함

2.2.4. 4세대 운영체제 (1970년대 후반기 - 현재)

- 고밀도 집적회로 

- 마이크로프로세서

    - 최소의 비용으로 최대의 효과

    - 분산 및 병렬 처리 시스템 등장

    - 데이터베이스, 인공지능, 운영체제의 표준안에 관한 연구도 활발히 진행

    - 모든 pc에 적용됨

3. OS 기능

- UNIX 구성 요소

    - 사용자 인터페이스(쉘)

        - 장치 관리

        - 파일 관리

        - 메모리 관리

        - 처리기 관리

- 쉘 (사용자 인터페이스)

    - GUI가 현재보다 발달하기 전:

        - command창에서 명령어 입력

        - command interpreter가 명령어 번역 후 명령어 실행파일 실행

        - 끝나면 다음 명령어 입력 대기

        - command interpreter == 사용자 인터페이스(쉘)

        - 모든 os에 command interpreter가 존재함. unix에서는 쉘이라는 이름으로 존재하는것

        - unix에서 /bin 디렉터리에 있는 실행파일들이 command 실행파일들임

        - 시스템에서 쓸 수 있는 모든 command들만으로 만들어진 프로그램: command procedure

        - 프로그램 설치할 때 기본 환경 확인, 설치, path 설정, 설정완료 등 모든 과정이 command로 이루어짐

        - 이 설치 프로그램: command precedure

        - 쉘이 command procedure까지 합쳐서 의미하는 경우도 있음

4. OS의 위치

- 운영체제는 크게 커널과 유틸리티 프로그램으로 나눔

- 커널

    - 운영체제의 기능들 중 빈번하게 사용되는 부분

    - 부팅될 때 주기억장치에 적재되어 종료될 때까지 상주

    - 유틸리티를 따로 둔 이유는 주기억장치의 용량 부족

    - 사용자 인터페이스의 대부분이 유틸리티에 속함

    - IO.SYS, MSDOS.SYS, COMMAND.SYS 등이 커널에 속함

    - 커널 중에서도 더 빠른 실행이나 높은 수준의 보호가 요구되는 프로그램들은 펌웨어 형태인 ROM이나 PLA로 만들어 놓음

- 듀얼모드

    - 유저모드 + 커널모드

    - 일반 사용자가 운영체제나 시스템 등을 임의로 수정하는 것을 막기 위해 그러한 일들은 운영체제가 담당하도록 커널 모드에서 실행

    - 사용자 프로그램이나 응용 프로그램은 유저모드에서 실행

    - 프로그램이 실행될 때 유저모드와 커널모드가 번갈아가면서 실행됨

    - ex)

total = 0

for i in range(1, 50):
    total += i
print(total)

    이건 소스코드이긴 하지만,

    컴파일이 될 때 print문은 모니터, 프린터 등 다른 HW를 건드려야하기 때문에 system call로 바뀐다.

    그리고 실행시키면 유저모드에서 실행되다가, system call을 만나면 커널모드로 바뀐다.

    I/O 담당 운영체제가 실행되어 print 대상 device를 확인하고, device가 실행중인지 확인 후 입출력을 실행한다.

    입출력이기 때문에 time sharing system 방식으로 cpu가 작동한다.

    end를 만나면 프로그램이 끝나며 다시 유저모드로 돌아간다.

    이처럼 간단한 프로그램에서도 유저모드와 커널모드가 번갈아가며 작동한다.