Home [CS] 프로세스와 스레드 05 - 프로세스와 여러 현상
Post
Cancel

[CS] 프로세스와 스레드 05 - 프로세스와 여러 현상

Posted Sep 30, 2023 Updated Mar 25, 2024
By yanghs6
14 min read

개요

안녕하세요.

이번 글에서는 프로세스와 관련된 여러 현상에 대해 살펴보겠습니다.

상호배제의 문제

교착 상태(Deadlock)

교착 상태는 2개 이상의 프로세스가 각자 소유한 자원을 대기하면서 작업을 수행하지 못 하는 상태를 의미합니다.

다시 말하자면, 그들이 소유한 자원을 할당하고 필요한 자원을 획득하지 못해 순환되는 의존에 갇힌 상태입니다.

다음 그림은 교착 상태를 표현한 그림입니다.

교착 상태 [그림01] 교착 상태

P1은 Resource2를, P2는 Resource1을 소유하고 있습니다.

하지만 P1은 Resource1을, P2는 Resouce2를 필요로 합니다.

이러한 상황이 바로 교착상태입니다.

교착 상태는 시스템 진행의 완전한 중단으로 이어집니다.

따라서 자원 선점이나 교착 상태 탐지 또는 복구 메커니즘과 같은 개입이 필요합니다.

경쟁 상태(Race Condition)

경쟁 상태는 다수의 프로세스나 쓰레드가 공유 메모리에 동시에 접근하거나 조작할 때 발생하며 예측 불가능하고 오류로 분류되는 행동으로 이어집니다.

다음 그림은 경쟁 상태의 예시입니다.

경쟁 상태 [그림02] 경쟁 상태

P1과 P2는 x라는 변수를 읽어와서 각각의 연산을 수행합니다.

하지만 P2의 실행 중 P1이 실행되었습니다.

P1에서 수행한 결과를 저장하기 이전에 P2에서 먼저 x를 읽었기 때문에 P2는 x의 변화를 알지 못합니다.

그렇다면 이 두 프로세스의 결과물은 x는 어떤 값이 되어야 할까요??

이러한 상태가 경쟁 상태입니다.

경쟁 상태는 데이터 오염, 부정확한 결과, 프로그램 충돌 등을 일으킵니다.

따라서 프로세스 간 경쟁 상태를 방지하고 각자의 협업을 보장하기 위해서는 락, 세마포어, 원자 조작과 같은 적절한 동기화 메커니즘이 필수적입니다.

스케줄링의 문제

기아 상태(Starvation)

기아 상태는 다른 프로세스들 때문에 지속적으로 지연되거나 우선순위가 밀리면서 프로세스가 필요한 자원의 접근하거나 CPU 시간을 받지 못 할 때를 의미합니다.

기아 프로세스는 리소스를 계속 기다리거나 반복적으로 우선순위가 밀리면서 진행되지 않을 수 있습니다.

다음 그림은 기아 상태를 표현한 그림입니다.

기아 상태 [그림03] 기아 상태

4개의 프로세스가 우선순위 큐를 통해 대기합니다.

그렇지만 P1, P2, P3의 우선순위가 P4보다 높다보니 P4는 무한정 기다리게 됩니다.

여기서 P4는 기아 프로세스가 되며 이러한 상황이 지속되는 것이 기아 상태입니다.

기아 상태는 불공평한 스케줄링 정책이나 특정 프로세스가 리소스를 독점하거나 다른 프로세스의 요구를 무시할 때 발생할 수 있습니다.

호위 효과(Convoy Effect)

호위 효과(Convey Effect)는 프로세스 스케줄링 알고리즘 중 FCFS(First-Come-First-Serve)에서 발생합니다.

호위 효과는 큰 프로세스나 리소스를 차지하는 작업이 직접적 연관이 없는 작은 프로세스들을 기다리게 하는 현상을 말합니다.

큰 프로세스가 CPU와 I/O 같은 공유 자원을 오랫동안 독점하면서 발생합니다.

호위 효과 [그림04] 호위 효과

실행시간(execution)이 짧은 프로세스(P1, P3)과 긴 프로세스(P2)가 있다고 가정하겠습니다.

A 상황은 실행시간이 짧은 프로세스를 먼저 실행한 경우입니다.

P1과 P3를 먼저 처리 후 P2을 실행한다면 대기시간(wait)이 길지 않으며 덕분에 응답시간(response)도 짧습니다.

반면 실행시간이 긴 프로세스를 먼저 실행한 B 상황을 확인해봅시다.

P3의 실행시간을 기다리면서 전체적인 응답시간이 굉장히 길어지는 모습을 보입니다.

이처럼 작은 프로세스들은 대기하거나 큰 프로세스 뒤에서 호위받는 형태를 보이고, 결국 전체 시스템의 효율과 처리량의 감소로 이어집니다.

호위 효과를 줄이는 방법으로는 다른 스케줄링 알고리즘 도입, 필요한 프로세스에 자원 할당, 병렬 처리, 시스템 모니터링과 튜닝 등이 있습니다.

우선순위 역전(Priority Inversion)

우선순위 역전은 낮은 우선순위 작업이 공유 자원을 해제하지 않으면서 높은 우선순위 작업이 지연되거나 멈추는 우선순위 선점 기반 스케줄링 시스템에서 발생합니다.

이는 낮은 우선순위 작업이 의도치 않게 높은 우선순위 작업의 진행을 막게되고 우선순위의 지연이나 위반을 초래합니다.

다음 그림은 우선순위 역전을 나타낸 그림입니다.

우선순위 역전 [그림05] 우선순위 역전

3개의 프로세스가 존재하며 우선순위는 P3 > P2 > P1 순입니다.

이 중 P1과 P3는 서로 세마포어를 통해 공유자원에 접근합니다.

가장 먼저 P1이 실행됩니다.

이후 우선순위에 따라 P3가 실행됩니다.

하지만 P1이 아직 세마포어를 소유하고 있어 이를 기다리면서 P1이 재실행됩니다.

이렇게 P1이 실행되다가 우선순위에 따라 P2가 실행됩니다.

P2의 실행이 종료되고 다시 P1이 실행되다가 세마포어를 해제합니다.

마지막으로 P3는 해제된 세마포어를 가져와 작업을 이어갑니다.

여기서 우선순위가 더 낮은 P2가 더 높은 P1보다 먼저 실행되고 종료되는 현상이 발생합니다.

이 현상이 바로 우선순위 역전입니다.

우선순위 역전은 우선순위 상속이나 높은 우선순위 작업의 필요 자원 획득을 보장하는 우선순위 상한 프로토콜을 통해 완화할 수 있습니다.

프로세스 구조 상의 문제

스래싱(Thrashing)

위키백과에서는 스래싱(thrashing)을 “컴퓨터의 가상 메모리 리소스가 과도하게 사용되면서 페이징 및 페이지 장애가 지속적으로 발생하고 대부분의 응용 프로그램 수준 처리를 방해하는 것”이라고 설명합니다.

주로 시스템이 너무 많은 프로세스를 적재하고 가용 실제 메모리를 초과하는 메모리를 요구하면서 발생합니다.

다음 그림을 통해 조금 더 살펴보겠습니다.

스래싱 [그림06] 스래싱

프로세스나 스레드는 특정 신호를 받았을 때 작업을 멈추고 각자 실행에 필요한 내용을 대기 큐에 삽입합니다.

만약 프로세스나 스레드가 컴퓨터 처리 능력 이상으로 중단되고 재실행된다면 메모리의 페이지를 점점 차지하기 시작합니다.

이 상황이 지속된다면 메모리의 페이지 장애가 늘어나게 됩니다.

결과적으로 시스템은 실제 작업 실행보다 페이지 이동에 더 많은 시간과 메모리를 소요합니다.

스래싱은 저조한 퍼포먼스와 응답 시간 증가, 전체 시스템의 처리량 감소를 일으킵니다.

문맥 교환 오버헤드(Context Switching Overhead)

문맥 교환은 프로세스나 스레드의 상태를 추후에 실행할 수 있도록 저장하고 복구하는 과정입니다.

문맥 교환은 레지스터, 메모리 매핑, 프로세스만의 정보를 저장하고 복구해야하므로 오버헤드가 동반됩니다.

만약 시스템의 프로세스가 너무 많고 문맥 교환이 자주 발생한다면 문맥 교환의 오버헤드가 커지면서 전체 시스템의 퍼포먼스와 효율이 감소합니다.

마무리하며

이번 글에서는 프로세스가 일으키는 다양한 현상에 대해 알아보았습니다.

제 편의대로 상호배제, 스케줄링, 프로세스 구조라는 분류로 나눠보았으나 정답은 아니라고 생각합니다.

또한 스래싱에 대한 내용은 나름대로 정리해봤지만 개인적으로 조금 더 이해가 필요하다고 여겨집니다.

수정이나 보완이 필요한 점은 편하게 댓글 남겨주세요!

추가로 각 현상에 대한 기술했을 뿐 그 해결방안에 대해서는 적지 않았습니다.

특정 현상을 보다 깊이 이해한 뒤 찾아보시길 추천드립니다.

이 글이 조금이나마 도움이 되셨으면 합니다.

감사합니다. 😀

참고 문헌

Computer Science, general
컴퓨터과학(computer_science) 개념(concept) 프로세스(process)
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents

[CS] 프로세스와 스레드 04 - 프로세스와 상호배제

[Python] Python GIL(Global Interpreter Lock) 살펴보기

Comments powered by Disqus.