Operating System - Treads

안녕하세요 :)

 

운영체제를 주제로 한 네번째 포스팅은쓰레드에 대하여 다루어 보겠습니다.

 

 

4.1)processed and threads

 

프로세스의 두가지 특성

-resource ownership - 메인메모리 파일권한 프린터권한 등

-sheduling/execution - 수행의 단위로서

 

4장부터는 리소스의 오너쉽에서는 프로세스라는 단위로 사용하고 수행의 단위에선 라잇 웨이!(로니콜먼)프로세스 또는 스레드라는 단위로 사용될것입니다.

 

수행의 단위가 스레드가 된다는것은 레디큐에 들어가는 단위가 프로세스가 아닌 스레드가 된다는것 입니다.

 

지난 포스팅까지 공부한 내용에서는 한프로세스내에 한 스레드가 들어있는 단위로만 프로세스를 생각했습니다. 하지만 이번 포스팅부터는 한 프로세스내에 여러 스레드가 들어있을수 있고 여러 프로세스에 여러 스레드가 들어있을수도 있습니다. 이러한 것들에 대하여 공부하여보겠습니다.

 

프로세스의 단위가 스레드로 변한다면 옮겨지는 권한)

프로세스가 가지고 있는 리소스를 생각해보면 첫번째에는 메모리가 있습니다, 그리고 파일 그리고 각종 입출력 장치들이 있습니다. 이러한 리소스에 대한 오너쉽은 아직 프로세스가 가지고 있고 PCB 내의 수행에 관련된 부분들은 스레드로 넘어갈 것입니다. 

 

또한 스케줄링과 디스패칭의 단위 또한 스레드가 됩니다. 이러한 과정에서 쓰레드가 늘어난 멀티 스레딩 환경의 프로세스가 가지고 있는 권한과 스레드가 가지고있는 권한에 대하여 나누어보면 다음과 같습니다.

 

프로세스 - virtual address space which hold process image, file, I/o resources, 

쓰레드 - excution state, thread context, excution stack, local variables, register values, priority

 

이러한 멀티 스레딩 환경에서 스레드 A가 열어둔 파일을 같은 프로세스 내의 스레드 B가 접근할수 있을까요? 정답은 yes입니다.

 

그렇다면 이러한 스레드가 프로세스와 비교하였을때 장점은 무엇일까요?

대부분의 면에서 프로세스보다 시간이 절약될 것입니다. 스레드의 경우 메모리에 이미 할당되어있는 프로세스 이미지를 이용하여 execution path 하나만 더 만들면 되지만, 프로세스의 경우 ID 부여하고 메모리에 이미지 하나 더 만들고 유저 어드레스 스페이스 또 만들고 해될테니까 말입니다.

 

이전포스팅에서 열심히 프로세스의 state에 대하여 다루었습니다. 이번에는 이 state의 관점도 한번 확인해볼것입니다. 프로세스가 스레드로 바뀐다면 바뀌는 state 는 어떠한것이 있을까요?

 

Tread states)

거두절미하고 결과만 확인하면 suspend 상태만 없어질 것입니다. 이유는 조금만 생각해도 바로 나옵니다. 서스펜드란 블락된 프로세스 중에서 특정한 이벤트를 기다리고 있게 되어 바로 레디큐로 할당못되는 프로세스를 스와핑을 통해 디스크의 한부분으로 쫒김당하는 state를 뜻합니다. 그런데 이 디스크는 자원이고 즉 리소스입니다. 이러한 리소스에 대한 오너쉽이 계속 프로세스에게 있기때문에 suspend 상태는 존재할수 없습니다.

 

그래서 state 는 new ready running blocked exit 다섯가지 입니다. 그림으로 본다면 다음과 같지만 이름만 new 가 spawn(알깐다), exit 가 finish 로 바뀌었을뿐 역할은 같습니다.

다음은 유저레벨의 스레드와 커널레벨의 스레드를 각각 비교해 보겠습니다.

유저 레벨의 스레드는 라이브러리의 도움을 받아 만드는 눈속임입니다. 

커널 레벨의 스레드가 진짜 라잇웨이(로니콜먼) 프로세스! 입니다.(지금까지 쭉 공부한)

 

간단히 유저레벨의 스레드는 스레드 라이브러리 리눅스에선 POSIX 스레드 라이브러리를 통한 어플리케이션으로 관리됩니다. 즉 진짜 스레드를 다루는 운영체제입장에서는 process로 보이기 떄문에 프로세스의 스레드 라이브러리가 스레드를 관리합니다. 하지만 역할은 비슷합니다. 운영체제의 입장에서 보았을때만 스레드가 아닌 프로세스로 보이는 눈속임일뿐입니다.

 

이 유저레벨 스레드의 장점으로 멀티스레드 환경이 아닌 운영체제에서도 유저레벨에서 스레드를 사용할수 있다는것이 있습니다. 하지만 단점으로는 하나의 스레드가 블럭 되었을때 프로세스단위로블럭되기때문에 모든 스레드가 블럭됩니다.

 

하지만 운영체제가 관리 하는 커널레벨의 스레드에서는 그런일이 발생하지 않습니다. 라이브러리의 지원이 아닌 운영체제에서 스레드를 공유하기 때문이죠 블럭시 스레드 단위로 블럭되지만 당연히 이를 위해서 운영체제의 소스를 사용해야하는데 이때는 이전포스팅에서 열띄게 배운것이 빈번하게 발생하죠! 바로 모드스위칭입니다... 유저레벨 단위의 처리에비해 월등히 코스트가 많이 들기 때문에 이것이 단점이됩니다.

 

실제로 코스트가 많이들수록 소요되는 응답시간은 늘어나기 때문에 유저레벨 스레드보다 커널레벨 스레드가 생성시 더오래 걸리고 프로세스를 생성시에는 그것보다 더 오래 걸립니다. 

 

멀티코어 성능)