.jpeg)
Process 모델의 한계점
- Cooperation 프로세스의 관점
웹 서버와 같이 자기 프로세스를 복사(fork)하여서 이용하는데, 만약 공유되는 주소 공간이나 자원이 있는 경우에 낭비가 심하다.
- 멀티 프로세싱의 관점
고전적 프로세스의 모델에서는 하나의 프로세스는 하나의 프로세서만을 이용함
Thread
- 프로세스는 무겁다(heavy-weight)
- 프로세스는 image+ context를 전부 가지고 있음
- 새로 프로세스 생성시 위의 모두를 복사해서 할당하는 것을 매우 비용이 많이듬.
- IPC를 통해 데이터 전달하는 것은 OS를 한번 거치므로 비용 많이듬.
- Thread
프로그램에 의해서 실행되는 일련의 명령들
- PC(program counter) + Stack(+SP) + data registers
- 대부분의 데이터, 이미지들을 공유함
- 프로세스의 OS 상태 또한 공유
Process vs Thread
- 고전적 해석
- 프로세스는 쓰레드를 담고있는 컨테이너(하나의 프로세스안에 여러개의 쓰레드를 포함)
- 프로세스는 정적, 쓰레드는 동적
- 공통점
- 각각 각자 자신의 실행 흐름을 가짐
- 각각은 서로 다르게 스케쥴링
- 차이점
- Thead는 코드, 데이터를 공유, Process 는 공유 X
- Thread는 생성하는데 있어서 코스트가 Process에 비해서 매우 작음
Thread의 이점
- 경제성
- concurrency를 만드는 것이 쉽다(싸다).
- 생성, 종료, 컨텍스트 스위칭의 시간이 적게든다(프로세스의 비해서)
- 자원을 공유하므로 커뮤니케이션을 하는게 쉽다.
- 여럿의 쓰레드는 같은 주소에서 같은 메모리와 파일들을 공유하므로 커널을 통하지 않아도 커뮤니케이션 가능
- 반응속도 빠르다
- 멀티 프로세서를 잘 이용가능
User-level-thread VS kernel-level-thread
- user-level-thread: 특정 라이브러리가 쓰레드와 관련된 것들을 관리.
- kernel-level-thread: OS가 쓰레드 생성과 관리를 하는데 있어서 관여(시스템콜 필요)
- 유저-레벨-쓰레드
- 유저-레벨-쓰레드 라이브러리에서 모든 것을 관리
- 커널은 아무것도 관여 하지 않음
- 장점: 매우 가볍다. 생성, 관리, 스케쥴링을 모든 유저라이브러리에서 관여(mini-kernel)
- 단점: I/O로 하나가 블락만 되도 전부 블락, 멀티 프로세서의 효과를 전혀 볼수 없음
- 커널-레벨-쓰레드
- 커널에 의해서 쓰레드가 생성되고 관리됨
- 각각이 따로 스케쥴됨
- 각각의 커널 스택을 갖고 있음
- kernel context와 글로벌 데이터를 공유
- 커널의 일반적인 싱크로나이즈 하는 방식을 따름
- one to one model & many to many model(user-level-thread 방식을 믹스한 것)
