Notice
Recent Posts
Recent Comments
Link
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Tags more
Archives
Today
Total
관리 메뉴

ultra_dev

프로세스와 스레드 본문

혼자 공부하는 컴퓨터구조+운영체제

프로세스와 스레드

ultra_dev 2023. 9. 21. 21:49

프로세스와 스레드

“실행중인 프로그램”, 프로세스

 

 

프로세스의 종류

  • 포그운드 프로세스(foreground process)
  • : 사용자가 볼 수 있는 공간에서 실행되는 프로세스
  • 백그라운드 프로세스(background process): 사용자와 직접 상호작용이 가능한 백그라운드 프로세스와
  • 사용자와 상호작용하지 않고 그저 정해진 일만 수행하는 프로세스가 있다. → 데몬, 서비스라고 부름
  • : 사용자가 볼 수 없는 공간에서 실행되는 프로세스


  • 모든 프로세스는 실행을 위해 cpu가 필요하다
    → but, cpu 자원은 한정되어 있음!!
  • 프로세스들은 돌아가며 한정된 시간 만큼만 cpu를 이용한다.
    • 자신의 차례에 정해진 시간만큼 cpu 이용
    • 타이머 인터럽트가 발생하면 차례 발생

프로세스 제어 블록(PCB)

  • 빠르게 번갈아가며 수행되는 프로세스들 관리하기 위해
  • 사용하는 자료구조가 프로세스 제어 블록! (PCB)
    • 프로세스 관련 정보를 저장하는 자료 구조
    • 마치 상품에 달린 태그와 같은 정보
    • 프로세스 생성 시 커널 영역에 생성, 종료 시 폐기
  • PCB에 담기는 대표적인 정보
  • 프로세스 ID ( = PID )
    • 특정 프로세스를 식별하기 위해 부여하는 고유한 번호 (학교의 학번 느낌!)
  • 레지스터 값
    • cpu를 혼자서 독차지 못하니까 여러 프로세스가 실행 될테고,
      프로세스 1번이 막 실행하고나서
      본인이 실행했던 프로그램 카운터나 스택 포인터같은 걸 기억하지 않는다면
      다음에 다시 자기 차례 돌아왔을 때도 이전에 했던걸 몰라서 다시 반복해야 하니까
    • 프로세스는 자신의 실행 차례가 오면 이전까지 사용한 레지스터 중간 값을 모두 복원 → 실행 재개한다. → 이전까지 했던 작업들 다시 재개하기 위함!
    • 프로그램 카운터(다음 번에 실행할 메모리의 주소) , 스택 포인터
  • 프로세스 상태
    • 입출력 장치를 사용하기 위해 기다리는 상태, cpu 사용하기 위해 기다리는 상태, cpu 이용 중인 상태 등등
    • 프로세스마다 상태값이 담김
  • CPU 스케줄링 정보
    • 프로세스가 언제, 어떤 순서로 cpu를 할당받을지에 대한 정보
  • 메모리 정보
    • 프로세스가 어느 주소에 저장되어 있는지에 대한 정보
    • 페이지 테이블 정보 (일단은 ‘메모리 주소를 알 수 있는 정보가 담기는구나’ 정도로 이후에 다시 딥하게!!)
  • 사용한 파일과 입출력장치 정보
    • 할당된 입출력장치, 사용 중인(열린) 파일 정보

→ 운영체제는 커널 영역에 적재된 PCB를 보고 프로세스를 관리한다.

문맥교환 (Context Switch)

  • 한 프로세스에서 다른 프로세스로 실행 순서가 넘어가면?
    • 기존에 실행되던 프로세스 A는 지금까지의 중간 정보를 백업해야 함
      • 프로그램 카운터 등 각종 레지스터 값, 메모리 정보, 열었던 파일, 사용한 입출력장치 등
      • 이러한 중간 정보 == 문맥 (context)라고 함
      • 다음 차례가 왔을 때 실행을 재개하기 위한 정보다.
      • 즉 실행 문맥을 백업해두면 언제든 해당 프로세스의 실행을 재개할 수 있다!! 는 것임
    • 그러면 뒤이어 실행할 프로세스 B의 문맥을 복구하고
      • 자연스레 실행 중인 프로세스가 바뀐다!
    • 이러한 과정을 컨텍스트 스위칭! 문맥 교환!이라고 한다.
      • 여러 프로세스가 끊임없이 빠르게 번갈아 가며 실행되는 원리

예를 들어서 프로세스 A 실행하다가 타이머 인터럽트 발생해서
이제 프로세스 B할 차례면

프로세스 A의 문맥을 pcb에 저장하고, 프로세스 b의 pcb로부터 문맥을 가져오고 → (문맥 교환 과정)
그 이후 프로세스 B 실행하는 것

cpu에 있는 프로세스a 값들을 프로세스a pcb에 담고 프로세스b값 불러와서 cpu에 딱!




프로세스의 메모리 영역

pcb가 커널 영역에 저장된다면

프로세스는 사용자 영역에 어떻게 저장될 것인가!

  • 크게 코드 영역(=텍스트 영역), 데이터 영역, 힙 영역, 스택 영역으로 나눠진다.
  • 코드 영역 ( = 텍스트 영역)
    • 실행할 수 있는 코드, 기계어로 이루어진 명령어 저장
    • 데이터가 아닌 CPU가 실행할 명령어가 담기기에 쓰기가 금지된 영역(read-only)
  • 데이터 영역
    • 잠깐 썼다가 없앨 데이터가 아닌 프로그램이 실행되는 동안 유지할 데이터 저장
      • Ex) 전역 변수(프로그램이 실행되는 동안 유지되는.. 프로그램 전체에서 접근 가능한..)
  • 힙 영역
    • 프로그램을 만드는 사용자, 즉 프로그래머가 직접 할당할 수 있는 저장공간
    • 나 이만큼 저장공간이 필요한데 직접 할당할래!
  • 스택 영역
    • 데이터가 일시적으로 저장되는 공간
    • 데이터 영역에 담기는 값과는 달리 잠깐 쓰다가 말 값들이 저장되는 공간
      • EX) 매개 변수, 지역 변수

코드 영역과 데이터 영역은 정적 할당 공간이지만(변할 일이 없으니..)

힙과 스택은 동적 할당 공간이다



힙 영역과 스택 영역의 크기는 가변적이다

  • 일반적으로 힙 영역은 낮은 주소 → 높은 주소로 할당 된다.
    • 힙이 스택 영역 침범하면 힙오버플로우
  • 일반적으로 스택 영역은 높은 주소 → 낮은 주소로 할당 된다.
    • 스택이 힙 영역 침범하면 스택오버플로우

프로세스 상태

보조기억장치에 있는 프로그램이라는 데이터 덩어리를 실행하면

프로세스가 생성되고 운영체제는 프로세스에게 pcb할당, 프로세스가 종료되면 pcb 폐기

  • 생성 상태
    • 이제 막 메모리에 적재되어 PCB를 할당 받은 상태
    • 준비가 완료되었다면 준비 상태로!!
  • 준비 상태
    • 당장이라도 cpu를 할당 받아 실행할 수 있지만
    • 자신의 차례가 아니기에 기다리는 상태
    • 자신의 차례가 된다면 실행 상태로 전환되겠지 (= 디스패치)
  • 실행 상태
    • cpu를 할당 받아 실행중인 상태
    • 할당된 시간 모두 사용 시(타이머 인터럽트 발생 시) 준비 상태로
    • 실행 도중에 입출력장치를 사용하면(프린트 출력 등) 실행 상태였던 프로세스는 입출력 작업이 끝날 때까지 대기 상태로 바뀜(완료 인터럽트 받을 때까지 대기 상태로!)!
  • 대기 상태
    • 프로세스가 실행 도중 입출력장치를 사용하는 경우
    • 입출력 작업은 CPU에 비해 느리기에 이 경우 대기 상태로 접어듬
    • 입출력 작업이 끝나면 (입출력 완료 인터럽트를 받으면) 준비 상태로
  • 종료 상태
    • 프로세스가 종료된 상태
    • PCB, 프로세스의 메모리 영역 정리

프로세스 계층 구조

  • 프로세스 실행 도중 ( 시스템 호출을 통해 ) 다른 프로세스 생성 가능
  • 새 프로세스를 생성한 프로세스 : 부모 프로세스
  • 부모 프로세스에 의해 생성된 프로세스 : 자식 프로세스

부모 프로세스와 자식 프로세스는 별개의 프로세스이므로 각기 다른 PID를 가진다.

일부 운영체제에서는 자식 프로세스 PCB에 부모 프로세스 PID(PPID, Parent PID)를 명시하기도 한다!

자식 프로세스는 또 다른 자식 프로세스를 낳을 수 있고, 이런 식으로 프로세스의 계층적인 구조가 형성된다.

프로세스 생성 기법

  • 부모 프로세스는 자식 프로세스를 어떻게 만들어 내고, 자식 프로세스는 어떻게 자신만의 코드를 실행하는가?
    • 복제와 옷 갈아입기(windows 운영체제는 해당 x)
      • 부모 프로세스는 fork 시스템 호출을 통해 자신의 복사본을 자식 프로세스로 생성한다.(복제)
        •         fork 시스템 호출

                  : 복사본 (=자식 프로세스) 생성

                  : 부모 프로세스의 자원 상속(호출한 부모 프로세스와 동일한 복사본이 생성되는 느낌.. 부모 프로세스의 자원들.. 예를 들어 메모리의 내용이나 열린 파일들의 목록같은 것들이  자식프로세스에게 상속됨) 

              - 자식 프로세스는 exec 시스템 호출을 통해 자신의 메모리 공간을 다른 프로그램으로 교체한다.(옷 갈아입기)


          exec 시스템 호출

          : 자신의 메모리 공간을 새로운 프로그램으로 덮어써라! 는 호출(새로운 프로그램으로 전환해서 실행..?)

          : 코드/데이터 영역은 실행할 프로그램 내용으로 바뀌고 나머지 영역은 초기화

          : 예를 들어, 부모 프로세스에서 fork()로 자식 프로세스 만들고 자식 프로세스가 exec() 호출하면
            내가 지금부터 실행할 새로운 프로그램으로 바뀐다!!

즉 프로세스 생성 기법은

fork() exec()의 반복!!

부모 프로세스로부터 자식 프로세스가 복제되고

자식 프로세스는 자신만의 프로그램을 실행하기 위한 메모리 공간을 exec() 호출로 채워 나가는 방식으로 계층 구조가 완성된다.


 

스레드(소프트웨어적인 스레드)

스레드는 프로세스를 구성하는 실행 흐름의 단위

하나의 프로세스는 하나 이상의 스레드를 가질 수 있다.

 

즉 한 프로세스를 여러개의 스레드로 동시에 실행 가능

ex) 웹브라우저 프로세스가 메모리에 적재되어 실행된다면 이 안에서 화면출력스레드, 입력스레드, 검색스레드가 동시에 실행될 수 있음

 

실행 흐름이 여러개인 프로세스를 멀티 스레드 프로세스라고 한다.

→ 프로세스를 이루는 여러 명령어를 동시에 실행 가능


스레드의 구성 요소

: 스레드 id, 프로그램 카운터를 비롯한 레지스터 값, 스택 등 실행에 필요한 최소한의 정보

: 이때 스레드는 프로세스의 코드영역(같은 코드 영역에서 프로그램 카운터를 가지는 거니까), 데이터 영역 ,힙 영역 등의 자원을 공유하며 실행 된다.

: 스택만 독립적이고 나머지는 같이 공유


멀티 프로세스 vs 멀티 스레드

동일한 작업을 수행하는 단일 스레드 프로세스 여러개 실행(멀티 프로세스)

vs

하나의 프로세스를 여러 스레드로 실행(멀티 스레드)

프로세스끼리는 기본적으로 자원을 공유하지 않지만,

스레드끼리는 기본적으로 같은 프로세스 내의 자원을 공유한다.

 

: 프로세스끼리는 자원을 공유하지 않는다 → 남남처럼 독립적 실행

  • 예외: 프로세스간 통신(IPC)을 통해서 프로세스 간에도 자원을 주고 받을 수 있다.
    • 통신은 네트워크 통신만 의미하는 건 아니다. 같은 컴퓨터 내 프로세스나 스레드들끼리 데이터 주고받는 것도 통신이라고 부를 수 있다. 여기서 말하는 통신은 그런 통신임
    • 파일을 통한 프로세스 간 통신, 공유 메모리를 통한 프로세스 간 통신!
      • 예를 들어, 프로세스 A가 hello.txt 에다가 새로운 값을 쓰고 프로세스 b가 hello.txt 파일을 읽어들인다면 이 두 프로세스는 hello.txt 통해 ‘통신’을 주고 받았다고 할 수 있음. → 파일을 통한 통신
      • 프로세스들끼리 공유하는 메모리 영역을 따로 두는 방식 → 공유 메모리를 통한 통신
        • 예를 들어, 공유 메모리에다가 전역 변수 name이라는 값을 저장하고, 프로세스 A가 name에 어떤 값을 썼다면 프로세스 B는 공유 메모리 안에 있는 name이라는 변수를 읽어들이면서 ‘통신’한다고 할 수 있음

: 스레드는 프로세스의 자원을 공유 → 협력과 통신에 유리 but 하나가 문제 생기면 나머지도 똑같이 문제 생기겠지

'혼자 공부하는 컴퓨터구조+운영체제' 카테고리의 다른 글

프로세스 동기화  (0) 2023.09.25
cpu 스케줄링  (0) 2023.09.24
운영체제  (0) 2023.09.19
입출력장치  (0) 2023.09.12
보조기억장치  (0) 2023.09.11
Comments