[08] Thread

Conventional View of Process

-- process 는 두가지 방법으로 볼 수 있음

: 1. resource 소유 단위 - 주소 공간, 프로그램 코드, 데이터, 입출력을 사용하는 열린 파일 등의 process 는 가짐

: 2. scheduling 단위 - CPU 스케줄러는 한 번에 하나의 프로세스를 CPU 로 dispatch

-- 현대의 os 

: Process = unit of resource 소유 단위

++ 주소 공간, 프로그램 코드, 전역변수, 힙, 스택 파일, 입출력 장치와 같은 OS 자원을 가짐 

++ text, data, bss, stack 으로 구성

: Thread = unit of scheduling 단위

++ 프로세스 내의 단일 순차 실행 stream 

++ 다른  thread 와 자원 공유 가능

++ 각 thread 가 소유하는 것 : register, program counter, stack pointer

각 thread 의 공유 자원

++ 1개의 thread 는 1개의 프로세스에 속해 있음

++ 프로세스 내에는 여러개의  thread 가 있음

++ thread 도 block 되고 자식을 만들 수 있음 ( fork() )

++ 한 프로세스 내의 모든 thread 는 address space, program code, global variables, heap, OS resource 를 공유함

++ thread 각각의 PC, SP, register 를 가지고 동시병렬 수행 가능

 

-- thread 를 사용하는 이유

: 다중 thread 가 더 나은 서버를 만듦

: thread 는 동시 병렬적으로 수행되므로 수많은 thread 가 있으면 하나의 thread 가 block 되더라도 다른 많은 thread 가 일을 수행하므로 서버 성능이 올라감

: process 간의 데이터 접근을 위해서는 프로세스 통신을 통해 복잡하게 진행되지만 process 내부의 데이터 접근은 수월하게 할 수 있어 thread 간의 데이터 접근은 process 간의 엑세스보다 훨씬 빠르고 간단함

: multiprocessor 에서 이점을 취할 수 있음 ( thread 는 하나의 process 내부에서만 실행되기 때문 )

: thread 는 더 적은 resource 를 사용하여 process에 비해 비교적 저렴

: context switch 가 빠르게 일어남 ( PC,SP 등을 저장할 때 발생 )

:  thread 간의 보호는 안됨

 

Multi-Thread 사용하기 좋은 program 

: 1.여러개의 독립적인 일을 하는 program 들 

++ ex) debugger : 4 multiple indenpent task 실행

++ 1) 모니터 프로그램 실행

++ 2) GUI 활성 상태 유지

++ 3) 대화형 데이터 검사기 display

++ 4) dynamiic call grapher

: 2. 여러 요청을 동시에 처리해야하는 서버

: 3. 반복적인 수치 연산을 하는 program - 날씨 예츠과 같은 큰 문제 -> 작은 문제로 분할 후 thread 할당

 

 

User-Level thread

장점

-- 사용자 프로세스가 자체 스레드를 생성하고 관리할 수 있는 기능 라이브러리르 제공함

-- OS 를 수정할 필요 없음

-- 간단하게 보여짐 : PC, 레지스터, 스택, 사용자 프로세스 주소 공간에 저장된 작은 제어 블록으로 표현됨

-- 관리가 간단함 : 새로운 스레드 생성 -> 스레드 간의 switching -> 스레드 간의 동기화는 커널 개입없이 수행 가능

-- 스레드 간의 switching 하는 것은 매우 빠름

-- CPU 스케줄링은 사용자가 요구하는 알고리즘에 맞는 thread 를 shcedule 해줄 수 있어 유동적임

 

단점

-- OS kernel 과 thread 사이의 협력이 안됨

: 프로세스가 실행되는 동안 CPU time slice 를 여러번 나눠서 thread 에게 할당하는 것

: : thread 가 1개이든 1000 개이든 같은 CPU 시간을 할당하는 것

-- non-blocking (호출된 프로셋가 데이더 return 을 기다리지 않고 즉시 반환 ) 을 사용

: process 는 종료되었는데 실행중인 thread 가 있을 수 있음......흠.....

-- 1rodml thread 가 page fault 발생 시 해당 프로세스가 block 됨 -.>  현재 물리적 메모리에 없는 메몸리의 페이지에 엑세스하는 경우 운영체제가 보소 storage에서 물리적 메모리로 load

: 결과적으로 entire process block 

 

 

Kernel-level Thread

-- kernel 이 스레드 생성 및 관리를 위한 system call 을 지원하는 것

-- kernel 은 모든 스레드에 대한 정보를 가짐

: 스케줄러는 10개 스레드가 있는 프로세스에 1개의 스레드가 있는 프로세스보다 더 많은 시간 제공

-- 프로세스 통신이 찾은 application 에 good 

: 일반적으로 blocking system call 을 사용하는 경우가 많음

 

단점

-- user level 보다 100배는 느림

-- 오버헤드가 매우 크고 커널의 복잡성이 높아짐

: 커널이 process + thread 스케줄링을 해야하기 때문

: 각 thread 에 TCB 를 사용해 thread 정보 저장

each level scheduler

-- user thread 는 "Lightweight process (LWP)" 는 가상 CPU 처럼 제공된다

-- kernel 은 각각의 LWP 에 연결

-- 다중 스레드 어플리케이션에서는 각 스레드가 LWP 를 가지고 작동

-- LWP 와 상관없는 파일 시스템 관리, 네트워크 관리 등과 같은 작업은 별도의 스레드 사용

 

 

Nachos,,, 포기할래요,,,,