운영체제 프로세스·스레드 핵심정리

도착 시각이 다른 프로세스의 라운드 로빈 추적

시간 할당량은 2입니다. 할당량이 끝나는 순간 도착한 프로세스를 먼저 준비 큐에 넣고, 실행을 마치지 못한 프로세스는 그 뒤에 넣습니다.

넓은 표는 좌우로 밀어 나머지 열을 볼 수 있습니다.

풀이 순서

1. A가 첫 할당량을 쓴 동안 B와 C가 도착하므로 다음 순서는 B, C, A입니다. 이후에는 매 구간의 잔여 실행시간을 빼면서 큐 맨 뒤로 보냅니다.
2. 평균 대기시간은 (4 + 4 + 2) / 3 = 약 3.33, 평균 반환시간은 (9 + 7 + 3) / 3 = 약 6.33입니다.
3. 같은 입력의 FCFS는 A 0–5, B 5–8, C 8–9입니다. 평균 대기시간은 똑같이 약 3.33이지만 C의 응답시간은 6으로 늘어납니다. 하나의 평균만으로 스케줄러의 모든 특성을 비교할 수 없습니다.

틀리기 쉬운 지점: 대기시간과 응답시간은 다릅니다. 선점되어 여러 번 기다린 시간은 대기시간에 누적되지만 응답시간은 첫 실행까지만 셉니다.

자원이 남아 있는데도 은행원 알고리즘이 요청을 보류하는 이유

동일한 자원 6개가 있고 P1·P2·P3의 현재 할당은 [1, 2, 1], 최대 동시 요구량은 [4, 4, 3]입니다. 남은 자원은 2개이며, 프로세스는 필요한 자원을 받으면 유한 시간 안에 종료하여 할당받은 자원을 모두 반환한다고 가정합니다. 현재 상태가 안전한지 확인하고 P1의 1개 추가 요청을 허용할지 판단하세요. Max는 매번 반드시 요구할 수량이 아니라 미리 선언한 상한입니다.

Python 3

def safe_sequence(allocation, maximum, available):
    work = available
    finished = [False] * len(allocation)
    sequence = []
    while len(sequence) < len(allocation):
        for index in range(len(allocation)):
            need = maximum[index] - allocation[index]
            if not finished[index] and need <= work:
                work += allocation[index]
                finished[index] = True
                sequence.append(f'P{index + 1}')
                break  # 한 개를 선택하면 P1부터 다시 검사합니다.
        else:
            return None
    return sequence


allocation = [1, 2, 1]
maximum = [4, 4, 3]
available = 2
cases = [
    ('before', allocation, available),
    ('P1+1', [2, 2, 1], available - 1),
    ('P2+1', [1, 3, 1], available - 1),
]
for label, tentative, remaining in cases:
    sequence = safe_sequence(tentative, maximum, remaining)
    result = 'UNSAFE' if sequence is None else ' -> '.join(sequence)
    print(label, result)

넓은 표는 좌우로 밀어 나머지 열을 볼 수 있습니다.

풀이 순서

1. 처음에는 P1의 Need 3을 채우지 못하지만 P2의 Need 2는 Work 2로 충족할 수 있습니다. P2가 종료했다고 가정하면 Work는 4가 되어 P1, P3도 순서대로 완료할 수 있습니다. 코드는 선택할 때마다 P1부터 다시 검사하므로 P2 → P1 → P3을 출력하며, 안전 순서가 이것 하나뿐이라는 뜻은 아닙니다.
2. Work에는 Need를 더하지 않습니다. 남은 요구량을 잠시 지급했다가 완료 시 돌려받으므로 순변화는 원래 할당량만큼입니다. P2의 경우 2 − 2 + (2 + 2) = 4로, Work + Allocation과 같습니다. 이 검사는 실제 프로세스를 종료하는 실행이 아니라 완료 가능성의 모의 계산입니다.
3. P1의 요청 1은 Need 3 이하이고 Available 2 이하입니다. 그러나 잠정 할당 뒤 Work는 1, 모든 Need는 2이므로 첫 번째로 완료시킬 프로세스를 찾을 수 없습니다. 두 수량 검사만으로 허용하지 않고 안전성 검사에서 보류합니다. 실제 상태는 요청 전 상태로 유지해야 합니다.
4. 불안전하다는 결과만으로 지금 교착상태라고 단정할 수 없습니다. 현재 대기 요청은 제시되지 않았고 프로세스가 선언한 최대량을 다 쓰지 않고 끝날 수도 있습니다. 불안전은 최대 요구까지 고려했을 때 모두의 완료를 보장할 순서가 없다는 뜻입니다.
5. 다시 풀기: 같은 처음 상태에서 P2만 1개 더 요청하면 남은 Need는 [3, 1, 2], Work는 1입니다. P2가 먼저 완료하면 Work는 1 + 3 = 4가 되어 P1과 P3도 끝납니다. 같은 1개 요청이라도 요청한 프로세스에 따라 허용 여부가 달라집니다.

확인 결과

before P2 -> P1 -> P3
P1+1 UNSAFE
P2+1 P2 -> P1 -> P3

틀리기 쉬운 지점: 안전성 알고리즘은 유효한 할당·최대량·여유량을 입력받는 부분입니다. 실제 요청 처리에서는 Request ≤ Need, Request ≤ Available을 먼저 확인하고, 복사한 잠정 상태의 안전성까지 확인해야 합니다. 안전 순서는 CPU 스케줄링 순서나 실제 종료 시각의 예측이 아닙니다.

검증 방법과 참고 문서

명시한 큐 처리 규칙으로 시뮬레이션한 시간축, 완료 시각과 계산표를 테스트합니다. 자원 할당은 공개 Python 코드와 별도로 모든 완료 순서를 열거하여 세 상태의 안전성·자원 총량·입력 보존을 대조합니다. 실제 운영체제에서 자원을 할당하거나 교착상태를 일으킨 실험이 아닙니다.

예제·데이터·풀이표: 정처LAB 자체 설계 · AI 보조 작성 및 로컬 검증 · 예제 수정일 2026-10-16

• OSTEP: CPU 스케줄링 (저자 공개 교재)
• UIC 운영체제 강의: 안전상태·은행원 알고리즘