[CS 스터디] 4주차 ver 1.0

제가 보려고 만들었습니다. 계속 내용이 추가될 예정입니다

Process와 Thread의 Context Switching의 차이에 대해 설명해주세요

# Context Switching?

운영체제가 CPU 실행을 한 컨텍스트에서 다른 실행 컨텍스트로 변경할 때 발생하는 작업을 의미한다. 이 작업이 발생하게 되는 이유로는 다중 작업 처리, 인터럽트 처리같은게 있다. CPU는 한번에 하나의 작업만을 처리할 수 있기 때문에 여러작업을 동시에 처리하려면 Context Switching이 필수적이다.

• 인터럽트
  • IO장치같은 곳에서 하드웨어 인터럽트가 발생하게되면 CPU가 작업을 중단하고 해당 인터럽트 처리를 위해 전환한다.
• 멀티태스킹
  • 멀티 프로세스, 멀티 스레드 환경에서 필요하고 CPU는 짧은 시간 간격으로 여러 작업을 바꿔가며 수행해서 동시에 실행되는 것 처럼 보인다.
• 커널 / 유저 모드변경
  
  • 커널모드랑 유저모드가 OS에 접근할 수 있는 권한이 다르기 때문에 이때도 스위칭이 발생한다.

Context Switching은 크게 3단계로 나뉜다.

1. 현재 실행중인 작업의 상태 저장(프로세스, 스레드) - 다시 실행하기 위한 정보
   • 레지스터 값, PC(Program Counter)같은 작업 복원을 위한 상태정보와 구체적인 정보를 PCB에 저장해둔다. 
2. 다음에 실행할 작업의 상태 로드(프로세스, 스레드)
   • 메모리에서 다음 작업에 대한 상태를 로드한다(PCB의 PC에서 불러온다). CPU에서 새로운 작업을 실행할 때 필요한 초기화를 수행하는데 사용된다. 
3. 교환

 

프로세스의 상태정보를 저장하는 걸 PCB(Process Control Block)에 한다. PCB는 한 프로세스의 모든 정보가 저장되는 자료구조고,  프로세스가 생성될 때 운영체제가 프로세스 매니저를 만든다.

이 단계들을 거치면 한 개의 CPU가 여러 프로세스의 요청을 처리할 수 있게된다. 이런 작업은 필수적인 오버헤드가 존재해서 기본적으로 시간이 소요된다. 그래서 잦은 Context Switching은 시스템 전체에 영향을 미칠 수 있게 된다. 그래서 이걸 효율적으로 만들기 위한 알고리즘과 OS의 역할이 중요하다.

 

프로세스와 스레드 각각의 Context Switch 방식에는 차이가 있다. 프로그램은 프로세스를 실행하는데, 이때 여러 스레드를 포함하는 프로세스를 실행할 수 있다. 단일 스레드를 갖는 프로세스는 스레드 = 프로세스니까 생각할 부분이 없는데, 멀티 스레드를 갖는 프로세스는 스레드 간 스위칭이 필요하기 때문에 생각해봐야될 문제다.

# Thread Context Switching

동일 프로세스 내 스레드 간 context switching을 의미한다. 프로세스 간 context switching 보다 효율적이고 빠르며 굉장히 비용이 저렴하다는 장점이 있다. PC, 레지스터, 스택포인터같은 리소스와 식별자만 전환하면 되기 때문이다. 스레드간 스위칭은 커널 진입비용이랑 거의 비슷하다.

# Process Context Switching

프로세스 간 context switching을 의미하며 새 프로세스로 전환하기 전에 원래 있던 프로세스의 모든 리소스(메모리 주소값, 페이징 테이블, 커널 리소스, 프로세서에 있던 캐시들)를 전환해야된다. 즉 메모리주소 공간을 스위칭한다는 의미로 스레드 간 스위칭보다 비용이 훨씬 많이든다. 

스레드 간 Context Switching	프로세스 간 Context Switching
동일 프로세스에서 일어나기 때문에 메모리 주소 공간의 스위칭이 발생하지않는다. 스택포인터, 레지스터간 스위칭이 일어나긴하는데 이 비용이 메모리 주소공간 스위칭보다 저렴하다.	메모리 주소 공간의 스위칭이 발생한다.(이 비용이 비싸다)
스위칭해도 캐시를 공유한다.	스위칭 시 프로세스의 캐시와 TLB도 flush된다...

https://www.geeksforgeeks.org/difference-between-thread-context-switch-and-process-context-switch/

https://www.geeksforgeeks.org/process-table-and-process-control-block-pcb/

https://www.geeksforgeeks.org/context-switch-in-operating-system/

cpu 스케줄러가 무엇인가?

CPU를 선점한 프로세스가 대기하는 시간을 보다 효율적으로 쓰는 방법을 결정하는 구성요소가 CPU 스케줄러다. 선점, 비선점 두 종류로 스케줄링 방식이 나뉜다. 공통점은 다음에 실행할 프로세스를 정하고, 프로세스들을 실행가능한 상태로 만든다는 것이다. 비선점은 프로세스가 자발적으로 CPU를 반납하고, 선점은 OS가 CPU를 강탈해서 우선순위가 높은 프로세스에게 넘기는 것이다.

프로세스들은 Job queue(전체 프로세스), Ready queue(할당 대기중), Device queue(입출력 대기중)를 돌아다닌다.

 

# 선점

• 우선순위 스케줄링
  • 각 프로세스는 우선순위를 가지고 있고, 높은 우선순위를 가진 프로세스에게 먼저 할당한다.
  • 기아 문제가 존재한다.
• SRJF(Shortest Remaining Job First)
  • 일찍 끝날 수 있는 작업 먼저 우선순위를 둬서 처리하는 방식이다
  • 오버헤드가 작지만 동작방식이 SJF랑 비슷해서 기아위험이 있다.(긴 프로세스가 계속 대기)
• LRJF(Longest Remaining Job First)
  • 평균대기시간이 매우크다
  • 가장 작업시간이 많이 남은걸 먼저 처리하기 때문에 운영체제에서 시스템적으로 필요한 작업을 처리할 때 이 방식을 선택한다. 
• RR(Round-Robin)
  • 각 프로세스는 동일하게 할당시간(time quantum)을 갖고, 이게 지나면 ready queue 맨 뒤로 가서 대기한다
  • 할당시간을 어떻게 설정하느냐에 따라서 Context Switching 비용이 달라지며 오버헤드가 너무 커지면 FCFS나 다름없다.

# 비선점

• FCFS = FIFO (먼저 들어온걸 먼저 처리한다)
  • 구현이 쉽다
  • 사용시간이 긴 프로세스에 의해 짧은 프로세스가 오래기다린다는 단점이있다(평균 대기시간 차이가 크다 (Convoy Effect) )
• SJF(Shortest Job First)
  • 평균 대기시간을 최소화하기 위해 사용하는 방식 -> 작업시간이 짧은 프로세스부터 CPU를 할당한다
  • 대기시간을 최소화할 수 있는 대신에 작업시간이 긴 프로세스가 계속 기다리게 되므로 기아상태가 발생한다.
• LJF(Longest Job First)
  • SJF 반대, 선점 비선점 모두 가능하다.
  • 만약 작업시간(burst time)이 동일하면 FCFS로 처리한다.
  • 평균 대기시간이 매우길어질 수 있다.(Convoy Effect)
• HRN(Highest Response Ratio Next)
  • 가장 최적인 알고리즘 중 하나다. 
  • 응답 비율이라는 걸 사용하며 가장 응답 비율이 높은 걸 선택한다
  • 응답 비율 = (대기 시간 + 작업시간) / 작업시간
  • SJF에서 발생하는 기아문제를 줄였다.
  • 연산량이 많아 CPU에 과부하가 올수 있다는 단점이 있고 모든 작업의 작업시간을 알지못하면 사용하지못하는 방법이다.

# 그 외

• MQ(Multilevel Queue)
  • Ready Queue를 여러개로 분할한다.
  • 각 큐에 독립적인 스케줄링 알고리즘을 배정해서 처리한다.
• MFQ(Multilevel Feedback Queue)
  • MQ방식에서 프로세스가 다른 큐로 이동할 수 있도록 설게된 알고리즘이다. Aging을 채택해서 기아를 방지한다.
• MP(Multiple-Processor)
  • CPU를 여러개 사용하는 방식 
  • 한 프로세서에 작업이 몰리지 않도록 Load Sharing이 필요하다

 

https://www.geeksforgeeks.org/cpu-scheduling-in-operating-systems/?ref=header_search

HTTP 1.1은 어떤 문제점이 있었는가? 2.0은 어떻게 보완했는지 설명해주세요

# HTTP 1.1이 갖는 문제점

• HOL(Head of Line) Blocking
  • 커넥션에서 순차적으로 처리하기 때문에  한 요청이 지연되면 뒤에있는 요청들도 대기해야한다.
• Header Overhead
  • 각 요청-응답 시 이미 알고있는 불필요한 헤더를 반복해서 전송해야된다. 메시지 크기가 작은경우 잦은 통신으로인해 오버헤드가 더욱 커지는 문제가 존재한다. 
• 단일 연결의 한계 
  • 기본적으로 한 번에 하나의 요청만을 처리할 수 있어서 성능 저하가 발생한다. 
  • 기존 커넥션을 재사용해서 효율성은 높였는데 여러개의 리소스를 한번에 요청하면 순차적으로 처리돼서 성능저하가 발생한다

순차적으로 요청을 처리하고, 한번에 하나씩 요청을 처리하는 게 HTTP/1.1의 문제점이었다.

# HTTP 2.0에서 개선된 점

• Multiplexing
  
  • 단일 TCP connection으로도 여러개의 요청과 응답을 동시에 처리할 수 있도록해서 HOL Blocking문제는 물론이고 전체적인 성능향상을 이뤄냈다.
  • Frame이라는 단위로 데이터를 분할하는데 각 프레임에 식별자를 사용해서 구분이 가능하다.
  • 이 프레임을 여러개의 스트림으로 나누어 관리하고 스트림 역시 식별자를 갖는다.
• Header Compression
  • 정적 헤더 테이블과 동적 헤더 테이블을 사용해서 헤더를 인코딩해서 전송하기 때문에 오버헤드가 줄어든다. 
• Server Push
  • 서버가 클라이언트 요청에 대한 응답으로서 아직 요청하지않은 리소스도 미리 전송하는 기능이다. 추가요청없이 응답을 해주기때문에 로딩 속도를 늘릴 수 있다.

 

---

::출처::

https://github.com/VSFe/Tech-Interview?tab=readme-ov-file

https://github.com/WooVictory/Ready-For-Tech-Interview

https://github.com/gyoogle/tech-interview-for-developer

https://github.com/JaeYeopHan/Interview_Question_for_Beginner

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^