Computer Science/Operation System

[OS] Context Switching & Muti Thread, Muti Process

검은 까마귀 2024. 1. 8. 16:10

 

2024.01.03 - [Computer Science/Operation System] - [OS] 프로세스 & 쓰레드(Process & Thread)

 

[OS] 프로세스 & 쓰레드(Process & Thread)

#개요 CS를 공부할때는 언어에 대해서 1차적인 고민을 해야한다. 우리는 PC를 사용할때 프로그램(Program)을 사용한다. 프로그램(Program)을 실행하여 원하는 동작을 구현하는데 우리는 이 단위를 프

blaj2938.tistory.com

 

위에 포스팅한 내용에 따르면 PCB(Context)와 Context Switching을 잠시 다뤘었고 이어서 OS에서 공부해야할 양이 많은 항목중 하나이기 때문에 이를 이어서 포스팅 하겠다.

 

# 복습

Context라고 하는건 PCB와 같다. PCB, 즉, Context에는 프로세스의 메타데이터를 저장해 놓는 곳이며, 한 PCB안에는 한개의 프로세스 정보가 담기게 된다.

PCB는 커널의 스택 영역에 저장되게 된다. 그 이뉴는, 프로세스의 중요한 정보를 포함하고 있기 때문에, 일반 사용자가 접근하지 못하도록 하기 위함이다. 커널은 일반 사용자에게 보호 받는 영역이다.

 

# PCB, 왜 필요한가?

CPU에서는 프로세스의 상태에 따라 교체작업(interrupt)이 이루어진다. 이때, 기존의 진행중이던 프로세스가 원복할때 저장된 데이터 값을 PCB의 저장하기 위함이다. 또한 이런 PCB들은 연결리스트(Linked List)로 관리된다.연결리스트의 장점을 살펴보면 PCB를 연결리스트로 구현했을때 유리하다.

  • 데이터의 공간을 미리 할당하지 않고 동적으로 생성되고 삭제된다. 프로세스가 생성과 종료는 동적으로 발생하기 때문에 연결리스트를 사용하면 프로세스가 생성될 때마다 새로운 PCB를 리스트에 추가하고 종료될때 쉽게 제가할 수있게 된다. 자료구조중 하나인 배열을 생각해보면 왜 연결리스트가 용이한지 알 수 있을 것이다.
  • 연결리스트는 삽입과 삭제가 자주 일어나는 구현체에서 매우 유리하게 작용하게 되는데 PCB 리스트는 프로세스 상태의 변화가 자주 업데이트 됨으로 연결리스트가 유리하다.

이 두 가지의 장점만으로 연결리스트로 구현하는게 유리하다는 것을 알 수 있다. 항상 공부를 하면서 느끼지만 왜 연결리스트로 구현해야하는지 알아야한다. 연결리스트 왜 삽입삭제에 유리한지도!

 

 

# Context Switching

그렇다면 더 나아가서 Context Switching에 대해서 알아보고자한다. Context Switching, 즉 PCB의 메타정보를 교환하는 것을 의미한다.

 

 

왜? Context Switching을 하게 될까?

CPU는 한가지 일밖에 진행을 하지못하는데 여러가지 일이 쌓여있거나 그것보다 중요한 일(interrupt)이 있다면, Context Switcing을 진행하게된다. 그리고 다시 작업을 기존처럼 돌려둬야하기 때문에 Context라는 데이터 셋을 갖고 있게된다.

이후에 나올 프로세스 상태와 멀티 프로세스, 멀티 쓰레드와 관련이 있게 된다.

즉, 프로세스가 Ready → Running, Running → Ready, Running → Waiting처럼 상태 변경 시 발생!

 

# OverHead

Context Switching이 될때 데이터셋이 교체되는것들을 알았다. 그렇다면 Context swtching을 빠르게 하기 위해서는 결국 적은 데이터 셋을 갖고 교체를 해야하는 이때 사용되는 자원을 OverHead라고 부른다.

다시말해, Context swtching에 의해 CPU Dispatcher에 발생하게 되는 부담을 Context Switching OverHead이다.

 

 

그렇다면 문맥교환은 Process와 Thread에서 가능하다. 어떤 것이 OverHead가 더 클까??

OverHead는 Process가 더 크고 Thread가 더 작다. 그 이유는 Thread는 자원을 공유하지만, Process는 자원을 공유하지 않기 때문이다.

 

# Muti Process VS. Muti Thread

결론적으로는 Context Switching에서 응용되서 사용이 되게 된다. 멀티 프로세스는 프로세스 자원을 공유하지 않기 때문에 프로그램 자체에 안정성을 갖고 있지만, 쓰레드는 자원을 공유하기 때문에 멀티 쓰레드로 동작시 쓰레드가 비정상적으로 종료가 되면 모든 쓰레드가 죽게되어있다. 이전 포스팅에서 앞선 은행과 은행안의 창구와 같다.

은행의 돈은 100일때 실수로 누가 1이라도 잃어버렸다면, 1때문이라는 자원의 공유때문에 모든 창구가 1을 찾기 위해 비상체제를 돌입할 것이다. 하지만 창구가 여러개면 사용자의 처리속도도 빨라지게 되어있다. 차후에 나올 세마포어, 뮤텍스, 데드락과 같이 스케듈링과 데이터 동기화에서 문제가 생길 수 있다.

 

멀티 프로세스이냐 멀티 스레드냐는 서비스가 어떤 서비스냐에 따라 다를 것이다. 응답시간을 최소화 해야하는 서비스이면 멀티 스레드를 사용할 것이고, 응답속도가 늦더라도 서비스가 안정적으로 운영되기를 바란다면 멀티 프로세스 환경이 더 좋을거 같다. 하지만 우리가 하고 있는 JAVA프로그래밍, PYTHON 프로그래밍은 대게 싱글쓰레드 이다. 우리는 코드를 활용해 멀티 스레드에 접근 할 수있을것이다.

 

 

반응형