[Operating System] Threads

프로세스에 이어서 스레드이다.

프로세스에서 다룰 때는 프로세스가 실행의 기본 단위라고 배웠지만 실제로는 그렇지 않다.
실제로는 프로세스는 할당의 기본 단위이고 스레드는 실행과 스케쥴링의 기본단위라고 보면 된다.

스레드의 정의는 스스로의 실행 컨텍스트와, 레지스터, 스택을 가지고 실행하는 인스트럭션의 시퀀스 이다.
즉 프로세스는 전체 프로그램과 실행 컨텍스트의 함으로 보면 되고
스레드는 프로그램의 부분과 실행 컨텍스트의 부분집합으로 보면 된다.
즉 같은 프로세스 내의 스레드는 코드, 데이터, 파일은 공유하며 각각 고유의 스택과 레지스터를 가지게 된다.

프로세스와 스레드의 차이는 위에서 언급한 단위의 차이도 있고, 커뮤니케이션 오버헤드에서도 차이가 난다.
프로세스같은 경우에는 프로세스간 커뮤니케이션(Interprocess Communication, IPC) 시에 컨텍스트 스위칭을 필요로 하므로 오버헤드가 발생하지만 스레드간 커뮤니케이션은 물론 컨텍스트 스위칭이 필요하지만 프로세스의 그것에 비해 매우 작은 비용으로 컨텍스트 스위칭을 할 수 있다. 하지만 같은 메모리 내에서 각각의 스택을 가지는 것이므로 안전함을 보장할 수는 없다.

어쨌든 멀티스레딩은 멀티프로세싱보다 효율적이고 병렬성적인 측면에서 더 우월하다.

이러한 스레드 관리의 책임을 어디에 둘 것인가에 따라 Kernel level thread와 user level thread로 나뉜다.
앞에서 언급하였듯이 Kernel이라는 말이 들어가는 것이면 OS가 관리한다고 보면 된다.
Kernel level thread는 커널, 즉 OS 자체에서 스레드를 인식하고 개개로 관리가 가능한 것이고,
user level thread는 스레드가 스택, 레지스터 값들만 다르다는것에 착안하여 실제로 그 값들을 어셈블리언어로 바꿔주는 방식으로 컨텍스트 스위칭을 하는 것을 의미한다.
각각의 장단점이 있는데, user level thread가 속도 측면에서는 우월하다. 복잡한 컨텍스트 스위칭을 거치지 않고 유저 모드에서 레지스터 값 변경만으로 컨텍스트 스위칭이 일어나기 때문에 효율적이다.
하지만 user level 스레드는 blocking에 매우매우 취약하다.
OS가 바라보기에는 다 같은 프로세스이자 스레드이므로 어떤 스레드 하나가 자원을 요청하고 대기 상태로 넘어가게 되면
그 프로세스 내의 모든 스레드가 다 블락 상태가 되버리는 문제가 생긴다.
이것을 Transparent to OS 성질이라고 한다. 

커널 스레드와 유저 스레드와 어떻게 매칭되느냐에 따라 Many-to-One, Many-to-Many, 그리고 One-to-One 등의 모델이 있으며 일반적인 OS에서는 one-to-one으로 구현된다.