이 포스팅은 저번 포스팅이었던 프로세스, 컨텍스트 스위치 ,스케줄러 다음 포스팅입니다.
쓰레드와 프로세스는 밀접한 관계에 있는 만큼 저번 포스팅을 읽고 오심을 추천드립니다.
프로세스, 컨텍스트 스위치, 스케줄러 (Process, Context Switch, Scheduler)
이 포스팅은 저번 포스팅이었던 System Structure & Program Execution 다음 포스팅입니다. 저번 포스팅을 보지 않아도 이해 가능하지만, 보셨다면 더 깊이 이해할 수 있습니다. https://mail-study.tistory.com/e
mail-study.tistory.com
Thread
A thread (or light weight process) is a basic unit of CPU utilization
쓰레드는 CPU에 작업 요청을 하는 실행단위를 말한다.
프로세스가 생성되면 CPU 스케줄러는 CPU에게 해야 하는 일을 전달하고,
CPU는 그 일을 하게 된다. 이때 CPU가 받는 일을 쓰레드라고 본다.
결국 운영체제 입장에서 작업의 단위는 프로세스이지만,
CPU 입장에서는 쓰레드가 되는 것이다.
전통적인 개념의 heavy weight process는 하나의 thread를 가지고 있는 task로 볼 수 있다.
다중 쓰레드로 구성된 태스크 구조에서는 하나의 서버 쓰레드가 Blocked (waiting) 상태인 동안에도 동일한 태스크 내의
다른 쓰레드가 실행(running)되어 빠른 처리를 할 수 있다.
동일한 일을 수행하는 도중 쓰레드가 협력하여 높은 처리율(thread put)과 성능 향상을 얻을 수 있다.
쓰레드를 사용하면 병렬성을 높일 수 있다. = CPU가 여려개 달린 PC에서만 가능 (1000*1000 행렬 연산)
이때 쓰레드는 프로세스와 달리 프로세스 내에서 쓰레드끼리 자원을 공유할 수 있다.
프로세스는 일반적으로 다른 프로세스와 자원을 공유하며 영향을 끼칠 수 없다.
(가능한 경우는 다음 포스팅에서 추가 설명))
Thread의 구성
여러 개의 쓰레드는 하나의 프로세서에서 작동한다.
Code, Data 등 하나의 프로세서의 자원을 여러 개의 쓰레드가 공유한다.
하지만 CPU의 점유와 관련된 PCB의 Program counter와 register 영억에, 쓰레드는
쓰레드마다 각각 메모리를 점유하고 있다.
해당 프로세스의 주소 공간 중 stack 영역에 쓰레드는 쓰레드마다 각각의 메모리를
점유하고 있다.
PCB와 Stack의 분리를 통해, 쓰레드는 CPU를 점유할 수 있고, CPU를 빼앗기더라도
쓰레드 문맥교환을 통해 작업을 계속 유지할 수 있다.
쓰레드의 독립적인 부분
program counter
Register set
Stack space
쓰레드가 동료 쓰레드와 공유하는 부분
code section
data section
OS resources
Benefits of threads
Responsiveness 응답성
eg) multi-threaded web => if one Thread is blocked (eg network), another thread continues (eg display)
멀티 쓰레드 환경에서는 여러개의 쓰레드가 동시에 활동하기 때문에, 하나의 작업이 끝나기 전에,
다른 작업이 끝난다면, 먼저 끝난 작업을 미리 보여주는 행동이 가능해진다.
만약 네이버 포탈 메뉴를 들어갔을 때, 글 정보와 사진 정보가 서로 다른 쓰레드로 실행된다면,
글 정보가 먼저 들어왔으면, 사진 정보가 들어올 때까지 기다리지 않고, 글 정보 부터 보여줄 수 있게 된다.
이처럼 쓰레드를 통해 더 높은 응답성을 기대할 수 있다.
Resouces sharing , Economy
Threads can share binary code, data, resources of the process
앞서 설명했듯이 쓰레드는 생성될 때마다 스택에 새롭게 생성될 뿐만 아니라,
프로세스 내에서 힙, 데이터를 공유하기 때문에 프로세스 콘텍스트 스위칭 (Context Switching)에 비해
오버헤드를 절감할 수 있다.
creating & CPU switching thread ( rather than a process)
Solaris 의 경우 위 두가지 overhead가 각각 30배, 5배
Utilization of MP(Multi Processer) Architectures
each thread may be running in parallel on different Processer
Implementation of threads
Some are supported by kernel => Kernel Threads
커널 수준 Thread
(네이티브 Thread, OS Thread, OS 레밸 Thread라고도 한다.)
커널 레벨에서 생성되는 쓰레드이다.
운영체제 시스템 내에서 생성되어 동작하는 쓰레드로, 커널이 직접 관리한다.
CPU에서 실제로 실행되는 단위 (CPU 스케줄링의 단위)
스케줄러가 쓰레드 1, 쓰레드 2, 쓰레드 3을 직접 관리한다.
스케줄러는 모든 쓰레드의 정보를 알고 있다.
따라서 각 쓰레드의 우선 순위가 동일하다고 가정하면 1/3 만큼 시간을 할당 받아 실행 시킬 것.
쓰레드 1이 I/O 상태가 되면 나머지 쓰레드 2, 쓰레드 3은 상관없이 스케줄링 되어 실행된다.
Others are supported by library => User Threads
사용자 수준 Thread
유저 쓰레드라고도 한다.
쓰레드 개념을 프로그램이 레벨에서 추상화 한 것.
사용자 단에서 생성 및 관리되는 쓰레드이다. (따라서 커널이 관리하지 않고, 알지 못한다.)
커널에 의존적이지 않는 형태로, 쓰레드의 기능을 제공하는 라이브러리를 활용하는 방식이
사용자 레벨(User Level) 쓰레드이다.
유저 쓰레드가 CPU 에서 실행 되려면 커널 쓰레드와 반드시 연결되어야 한다.
커널 영역에 쓰레드의 정보가 없다. 즉, 스케줄러가 직접 쓰레드를 관리하지 않는다.
단순히 사용자 영역에서 작성된 코드로 인해 쓰레드가 실행되는 것이다.
쓰레드 1이 I/O 상태가 되면 쓰레드 2에 시간을 할당하는 것이 아니다.
스케줄러는 프로세스A 가 두게의 쓰레드로 이루어져있는지 모르게 때문에
단순히 프로세스A가 I/O 상태가 되었구나하고 생각하며 프로세스B(쓰레드 3)을 실행시킨다.
=> 이를 해결하기 위해 Non Blocking I/O 가 나왔다.
커널 수준 Thread VS 사용자 수준 Thread 정리
| 커널 수준 Thread | 사용자 수준 Thread | |
| 장점 | 프로세스의 쓰레드를 몇몇 프로세스에 한꺼번에 Dispatch할 수 있기 때문에 멀티 프로세서 환경에서 매우 빠르게 동작한다. 다른 쓰레드가 입출력 작업이 다 끝날 때까지 다른 쓰레드를 사용해 다른 작업을 진행할 수 있다. 커널이 각 쓰레드를 개별적으로 관리할 수 있다. 컨널이 직접 쓰레드를 제공해 주기 때문에 안정성과 다양한 기능이 제공된다. |
운영체제에서 쓰레드를 지원할 필요가 없다. 스케줄링 결정이나, 동기화를 위해 커널을 호출하지 않기 때문에 인터럽트가 발생할 때 커널 레벨 쓰레드보다 오버헤드가 적다. 즉, 위의 말은 사용자 영역 쓰레드에서 행동을 하기에 OS Scheduler의 Context Swithch가 없다 (유저레벨 쓰레드 스케줄러를 이용). 커널은 사용자 레벨 쓰레드의 존재조차 모르기 때문에 모드 간의 전환이 없고, 성능 이득이 발생한다. |
| 단점 | 스케줄링 동기화를 위해 커널을 호출하는데 무겁고 오래걸린다.(내용을 저장하고, 저장한 내용을 불러오는 과정이 필요) 즉, 사용자 모드에서 커널 모드로의 전환히 빈번해 성능 저하가 발생한다. 사용자가 프로그래밍할 때 구현하기 어렵고, 자원을 더 많이 소비하는 경향이 있다. |
시스템 전반에 걸친 스케줄링 우선순위를 지원하지 않는다. (무슨 쓰레드가 먼저 동작할지 모른다.) 프로세스가 속한 쓰레드 중 I/O 작업등에 의해 하나라도 불록이 걸린다면 전체 쓰레드가 블록된다. |
커널 쓰레드와 사용자 쓰레드의 연결
앞서 유저 쓰레드가 CPU 에서 실행 되려면 커널 쓰레드와 반드시 연결되어야 한다. 라고 설명했다.
기본 CPU에서 실행되는 단위는 커널 쓰레드이기 때문에 유저 쓰레드는 반드시 커널 쓰레드와 연결이 되어야
하고, 그 후에 커널 쓰레드가 CPU에서 실행되어야 한다.
One-to-One-model
Java => 유저 쓰레드와 OS 쓰레드가 1:1로 연결된다.
쓰레드 관리, 스케줄링을 OS에 위임한다. = 스케줄링를 커널이 수행
만약 한 프로세스에 쓰레드가 2개 이상인 경우, 한 쓰레드가 블락이 되도 다른 쓰레드는 잘 동작한다.
Many-to-One-model
컨텍스트 스위칭이 매우 빠르다.
유저 쓰레드 레벨에서만 컨텍스트 스위칭이 발생하고, OS 레벨에서 컨텍스트 스위칭이 발생하지
않기 때문에 프로세스간에 컨텍스트 스위칭이 발생하지 않는다.
(앞서 프로세스가 쓰레드보다 5배에서 30배 가량 오래걸린다고 설명했다.)
유저 쓰레드가 블락되는 순간 OS 쓰레드도 블락되기 때문에 한 쓰레드가 블락되면 모든 쓰레드가
블락된다 => non block I/O 로 해결가능
출처
https://simple-ing.tistory.com/67
https://velog.io/@infoqoch/%EC%93%B0%EB%A0%88%EB%93%9CThread%EB%9E%80
KOCW 이화여자대학교 운영체제 반효경 교수 (반효경 [운영체제] 7. Process3)
https://core.ewha.ac.kr/publicview/C0101020140321143516139010?vmode=f
반효경 [운영체제] 7. Process3
설명이 없습니다.
core.ewha.ac.kr
'운영체제' 카테고리의 다른 글
| 프로세스 생성,수행, 종료, 프로세스간 협력, 특성 분류 (0) | 2024.05.19 |
|---|---|
| 프로세스, 컨텍스트 스위치, 스케줄러 (Process, Context Switch, Scheduler) (0) | 2024.05.10 |
| System Structure & Program Execution (0) | 2024.05.09 |
| 운영체제란..? 목적, 분류, 예시 (0) | 2024.05.07 |