쓰레드(Thread)

프로세스의 문제점

• 프로세스 생성의 오버헤드가 큼
  • 메모리 할당 → fork() → PCB → Page mapping table → …
• Process context switching의 오버헤드가 큼
  • 기존에 처리하던 레지스터 정보들 저장, 처리 영역 저장, 새로운 컨텍스트를 불어오고..
  • 새로 메모리에서 레지스터 값 가져오고, 처리 위치 가져오고..
• 프로세스 간의 통신이 어려움
  • 프로세스들은 완전히 독립된 주소 공간을 가지고 있음
    • 서로 다른 프로세스끼리 개입 불가
  • 프로세스 간의 통신을 위해 별도의 방법이 필요
    • shared memory, socket, message queue등
• 미디어 플레이어의 경우
  • 영상처리
  • 자막처리
  • 소리 처리
  • ….
• 기능들이 동시에 작동이 이뤄져야 함!
  • ‘사실 진짜로 동시는 아님’ → ‘시분할’
• 각 기능들이 프로세스 기반 ‘멀티태스킹’이라면?
  • context switching 하기에는 하나하나가 너무 무거움
  • 시분할 사이의 시간이 길어질 수 밖에 없다!

쓰레드

• 프로세스를 사용하는 문제점을 해결하기 위해서 고안!
• 프로세스보다 ‘작은’ 실행단위, 운영체제가 작업을 ‘스케쥴링’ 하는 단위
  • CPU 스케쥴러가 CPU에 작업을 전달하는 단위
  • 쓰레드를 lightweight process라고 부름
• 프로세스의 생성 및 소멸에 따른 오버헤드 감소
• 빠른 Context switching, 손쉬운 통신

프로세스는 쓰레드 컨테이너

• 쓰레드는 곧 함수! 프로세스는 반드시 1개 이상의 쓰레드로 구성: 메인 쓰레드(main)
• 하나의 쓰레드가 여러개의 쓰레드를 가질 수도 있음 → 멀티쓰레드
  • 다른 쓰레드들은 함수를 쓰레드로 만들어줄 것을 요청하여 생성됨
  • 그리고 각 쓰레드마다 TCB(Thead Control Block)이 생성되고 프로세스에 속한 스레드를 관리하기 위해 PCB는 TCB와 연결된다.
• 프로세스는 쓰레드들의 공유 공간 제공
  • 모든 쓰레드는 프로세스의 코드, 데이터, 힙을 공유 → 쓰레드 사이의 통신 용이
  • ‘단, 스택만은 쓰레드 별로 별도의 공간을 사용’
• 쓰레드의 생명과 프로세스의 생명
  • 쓰레드로 만든 함수 종료되면, 쓰레드 종료
    • 쓰레드가 종료되면 TCB도 제거
  • 프로세스에 속한 모든 쓰레드가 종료될 때,
    • 프로세스 종료
  • 프로세스가 강제 종료되면?
    • 당연히 쓰레드도 종료
• 프로세스는 쓰레드들간의 공유 자원 제공
  • Data 영역은 확실히 공유됨
  • stack 영역은 별개!
• 쓰레드의 실행 순서는 알 수 없음
  • 공유 자원(전역변수)의 합이 0이 되지 않는다!

쓰레드 장점 및 단점

• 장점
  • CPU 응답성 향상
  • 자원 공유, 효율성 향상
  • 다중 CPU 운용 용이
• 단점
  • 모든 자원을 공유한다? → 하나의 쓰레드가 잘못되면 프로세스 전체가 죽을 수 있음!
  • 너무 많은 쓰레드? → 너무 많은 Context switching 발생!

쓰레드 주소공간

• 쓰레드가 생성되고 실행하는 동안 접근 가능한 메모리 영역
• 쓰레드의 주소공간은 프로세스의 주소공간 내에 생성
  • 일반 함수가 수직적인 관계라면, 쓰레드는 side by side 형태
• 쓰레드 사적공간
  • 쓰레드 코드(Thread code)
  • 쓰레드 로컬 스토리지(Thread local storage)
  • 쓰레드 스택(Thread stack)
• 쓰레드 사이의 공유 공간
  • 프로세스 코드
  • 프로세스의 데이터 공간
  • 프로세스의 힙 영역

쓰레드 라이프 사이클

• 프로세스 라이프 사이클과 비슷 → TCB로 관리
• 쓰레드의 상태 변화
  • 준비 상태(Ready) - 쓰레드가 스케줄 되기를 기다리는 상태
  • 실행 상태(Running) - 쓰레드가 CPU에 의해 실행 중인 상태
  • 대기 상태(Blocked) - 쓰레드가 입출력을 요청하거나 sleep()과 같은 시스템 호출로 인해 커널에 의해 중단된 상태
  • 종료 상태(Terminated) - 쓰레드가 종료한 상태

Thread operation

• 쓰레드 생성
  • 쓰레드는 쓰레드를 생성하는 시스템 호출이나 라이브러리 함수를 호출하여 다른 쓰레드 생성 가능
  • 프로세스가 생성되면 자동으로 main 쓰레드 생성
• 쓰레드 종료
  • 프로세스 종료와 쓰레드 종료는 구분
  • 프로세스 종료
    • 프로세스의 어떤 쓰레드라도 exit() 시스템 호출을 부르면 프로세스 종료(모든 쓰레드 종료)
    • 메인 쓰레드의 종료 - 모든 쓰레드 종료
    • 모든 쓰레드 종료되면 프로세스 종료
  • 쓰레드 종료
    • pthread_exit()처럼 쓰레드만 종료하는 함수 호출시 해당 쓰레드만 종료
    • main함수에서 pthread_exit() 호출해도 메인 쓰레드만 종료(나머지 쓰레드 생존)
• 쓰레드 조인(join)
  • 쓰레드가 다른 쓰레드가 종료될때까지 대기
    • 주로 부모 쓰레드에서 자식 쓰레드의 종료 대기

  

• 쓰레드 양보(yield)
  • 쓰레드가 자발적으로 yield()와 같은 함수를 통해 자신의 실행을 중단하고 다른 쓰레드를 스케줄하도록 지시

Thread Context

• 쓰레드의 실행중인 상태정보는 TCB(Thread Control Block)에 저장
  • TCB(Thread Control Block)
    • 쓰레드가 생성될 때, 커널에 의해 생성
    • 쓰레드가 종료되면 같이 사라짐
  • 각종 CPU 레지스터 값을 관리
    • PC: 실행중인 코드 주소
    • SP: 실행 중인 함수의 스택 주소
    • Flag: 현재 CPU의 상태 주소
  • 나머지 메모리들은 어차피 공유하기 때문에 레지스터 값들만 저장하면 CPU에 복귀할때 이전의 상태로 돌아갈 수 있음

Thread Context Swithcing

• 현재 실행 중인 쓰레드를 중단하고 다른 쓰레드에게 CPU 할당, 현재 CPU Context를 TCB에 저장하고 다른 TCB에 저장된 컨텍스트를 CPU에 적재
• CPU 레지스터 저장 및 복귀
  • 현재 실행 중인 쓰레드 A의 컨텍스트를 TCB-A에 저장
  • TCB에 저장된 쓰레드 B의 컨텍스트를 CPU에 적재
  • CPU는 쓰레드 B가 이전에 중단되었던 위치에서 실행 가능
  • SP 레지스트를 복귀함으로서 자신의 이전 스택을 되찾게 됨
  • 스택에는 이전에 중단될때 함수의 매개변수나 지역변수들 그대로 저장되어 있음
• 커널 정보 수정
  • TCB-A와 TCB-B에 쓰레드 상태 정보나 CPU 사용시간 수정
  • TCB-A를 준비리스트나 블록리스트로 옮김
  • TCB-B는 준비리스트에서 분리

  

Overhead in context switching

• Context switching은 상당히 비싼 연산 중 하나!
  • 작업을 바꾸기 위해 하는 작업
  • CPU가 다른 할일은 못하고 다른 작업에 리소스를 빼앗긴다! → CPU 시간 소모
    • Context switching은 그 시간이 길거나 잦은 경우 컴퓨터 처리율이 심각하게 저하될 수 있음
• 동일한 프로세스의 다른 쓰레드로 스위칭 되는 경우
  • 컨텍스트 저장 및 복귀
    • CPU의 컨텍스트(PC, SP, 레지스터) TCB에 저장
    • TCB로부터 쓰레드 컨텍스트를 CPU에 복귀
• 다른 프로세스의 쓰레드로 스위칭 되는 경우
  • 다른 프로세스로 교체되면, CPU의 실행공간이 바뀌는 큰 변화로 추가적인 오버헤드 발생
    • 추가적인 메모리 오버헤드
      • 시스템 내에 현재 실행 중인 프로세스의 매핑 테이블을 새로운 프로세스의 매핑 테이블로 변경
    • 추가적인 캐시 오버헤드
      • 프로세스가 바뀌기 때문에 CPU 캐시에 담긴 코드와 데이터 무력화
      • 새 프로세스의 쓰레드가 실행되기 때문에 CPU 캐시 미스 발생, 다시 채우는데 상당한 시간 소요

Kernel-level thread

• 운영체제에서 관리하는 쓰레드
• 커널 쓰레드: 커널이 직접 생성하고 관리하는 쓰레드
  • 응용 프로그램이 시스템 호출을 통해 커널 레벨 쓰레드 생성
  • 커널이 쓰레드에 대한 정보(TCB)를 커널 공간에 생성하고 소유 → 커널에 의해 스케줄
  • 쓰레드 주소 공간(쓰레드 코드와 데이터): 사용자 공간에 존재
  • 메인 쓰레드는 커널 쓰레드
    • 응용프로그램이 적재되어 프로세스가 생성될때, 자동으로 커널은 main 쓰레드 생성
• 순수 커널 레벨 쓰레드
  • 부팅 때부터 커널의 기능을 돕기 위해 만들어진 쓰레드
  • 커널 코드를 실행하는 커널 쓰레드
  • 쓰레드 주소공간은 모두 커널 공간에 형성
  • 커널 모드에서 작동, 사용자 모드에서 실행되는 일은 없음

User-level thread

• User-space에서 관리하는 쓰레드
• 사용자 쓰레드: 라이브러리에 의해 구현된 일반적인 쓰레드
  • 응용프로그램이 라이브러리 함수를 호출하여 사용자 레벨 쓰레드 생성
  • 쓰레드 라이브러리가 쓰레드 정보(U-TCB)를 사용자 공간에 생성하고 소유
    • 쓰레드 라이브러리는 사용자 공간에 존재
    • 쓰레드 라이브러리에 의해 스케쥴
  • 커널은 사용자 레벨 쓰레드의 존재에 대해 알 수 없음 → 하나의 프로세스로만 인식
  • 쓰레드 주소 공간(쓰레드 코드나 데이터): 사용자 공간에 존재

Multithreading model

• 멀티 쓰레드의 구현
  • 응용프로그램에서 작성한 쓰레드가 시스템에서 실행되도록 구현하는 방법
    • 사용자가 만든 쓰레드가 시스템에서 스케줄되고 실행되도록 구현하는 방법
    • 쓰레드 라이브러리와 커널의 시스템 호출의 상호 협력 필요
• Many to One ‘N:1’ model
  • N개의 사용자 레벨 쓰레드를 1개의 커널 레벨 쓰레드로 매핑
• One to One ‘1:1’ model
  • 1개의 사용자 레벨 쓰레드를 1개의 커널 레벨 쓰레드로 매핑
• Many to Many ‘N:N’ model
  • N개의 사용자 레벨 쓰레드를 N개의 커널 레벨 쓰레드로 매핑

  

멀티 쓰레드와 fork()와 exec()

• 멀티 쓰레드에서 fork() 시스템콜을 실행한다면 어떻게 될까?
  • 여러 쓰레드 중 한 쓰레드가 fork()를 호출 → 새로운 프로세스는 fork()를 ‘호출한 쓰레드만’ 복제
  • 한 쓰레드가 exec()를 호출 → 프로세스 전체가 사라짐
• 그러면 fork()가 모든 쓰레드를 복제한다면 어떻게 될까?
  • c.f., 몇몇 시스템은 전체 쓰레드를 복제하는 fork도 지원함… 그러나
  • fork() 이후 exec()를 호출하면, 모든 쓰레드를 복제할 이유가 없음
  • fork() 이후 exec()를 호출하지 않는다면, 모든 쓰레드의 복제가 의미가 있음

자원동기화 문제: Thread-safe 개념

• 하나의 자원에 여러 쓰레드가 동시에 접근 → 공유 데이터 훼손 문제
• Thread-safe
  • 멀티 쓰레드 프로그래밍에서 어떤 함수나 변수, 객체에 여러 쓰레드로부터 동시에 접근이 이뤄져도 프로그램 실행에 문제가 없음을 뜻함
• Thread-safe를 지키기 위해
  • Re-entrancy
    • 어떤 함수가 한 쓰레드에 의해 실행되고 있을 때, 다른 쓰레드가 그 함수를 호출하더라도 각각에게 올바른 결과가 주어져야 함
  • Thread-local storage
    • 공유자원의 사용을 최대한 줄여, 각각의 쓰레드들만 접근 가능한 공간을 사용함으로써 동시 접근을 막음
    • 이 방법은 동기화 상태와 관련되어 있고, 공유상태를 피할 수 없을 때 사용
  • Mutual exclusion
    • 공유 자원을 꼭 사용해야할 때, 해당 자원의 접근을 세마포어 등의 락으로 통제
  • Atomic operations
    • 공유 자원에 접근할 때 원자 연산을 이용하거나 ‘원자적’으로 정의된 접근 방식을 사용함으로써 상호 배제를 구현

프로세스와 쓰레드

• 프로세스는 쓰레드들의 공유 공간이다
  • 쓰레드의 주소 공간이 형성되고 공유됨
• 프로세스는 운영체제가 응용프로그램을 적재하는 단위이고, 쓰레드는 실행 단위이다.
  • PCB에 저장된 정보는 환경 컨텍스트
  • TCB에 저장된 정보는 실행 컨텍스트
• 다른 프로세스에 속한 쓰레드 스위칭보다 동일한 프로세스에 속한 쓰레드 스위칭은 속도가 더 빠르다.
• 프로세스의 모든 쓰레드가 종료할때 프로세스가 종료된다.

쓰레드로 프로그램을 작성하면

• 병렬 실행 덕분에 실행 성능이 좋아진다.
• 우수한 응답성을 가진다.
  • 한 쓰레드가 블록되어도 다른 쓰레드를 통해 사용자 인터페이스 응답 가능
  • 서버 프로그램을 운용하는데 용이
• 시스템 자원 사용의 효율성도 좋아진다.
  • 쓰레드는 프로세스에 비해 생성 유지시 메모리나 자원 적게 사용
• 응용프로그램 구조의 단순화
  • 응용프로그램을 작업 기준으로 여러 함수로 분할
  • 각 함수별로 쓰레드를 만들어 동시 실행
  • 새로운 기능 추가 용이, 프로그램의 높은 확장성
• 작성이 쉽고 효율적인 통신