[운영체제] Process 2 [비동기,동기식 입출력과 Scheduling Queue, Thread]

전 포스팅에 이어서 Procees와 관련된 이야기를 해보겠습니다 

 

동기식 입출력과 비동기식 입출력 

일단 동기식 입출력을 프로세스 관점에서 이야기 해보도록하겠습니다. 일단 프로세스가 입출력을 진행하면 본인(프로세스)가 직접하는것이 아닌 입출력 처리를 운영체제(System call)을 통해서 해야하기때문에 사용자 프로세스는 운영체제에게 입출력 요청을 합니다. 하지만 입출력 수행이 오래기다리게 됩니다. 이 수행을 사용자 프로세스는 가만히 기다려야한다면 이것 자체를 동기식 입출력이라고 합니다. 

즉 User Process가  입출력 요청을했을때 입출력 요청이 끝날때까지 계속 기다려야 하는것입니다. 

 

비동기식 입출력은 동기식 입출력의 반대라고 생각하시면됩니다. 비동기식 입출력 요청을 한다음, 입출력이 진행되는 동안  사용자 프로세스는 곧바로 CPU를 부여받아 곧바로 기계어를 실행하는 것입니다. 

watiting을 기준으로 나뉘어진 입출력

 

이 둘의 차이점은 프로세스가 입출력이 진행되는 동안 CPU의 유무를 떠나서 기계어를 실행할수있는가? 에 따라 갈립니다. 

 

동기식 입출식 구현방법엔 총 2가지가  존재합니다.

1. 입출력이 진행되는 동안에 CPU를 다른 프로세스에게 부여하지않고 계속 갖고있습니다.

2. 입출력이 진행되는 동안에 CPU를 다른 프로세스가 가져갑니다. 

 

비동기식 입출식 구현방법은 말 그대로라고 생각하시면됩니다.

1. 입출력이 진행되는 동안에 상관없이 사용자 프로그램이 기계어를 실행합니다. 

 

프로세스 스케줄링 큐의 모습

프로세스 동기식,비동기식 입출력을 다루다보니 이제는 어떻게 프로세스가 Queue에 담겨져서 실행되는지 그림으로 알아보겠습니다. 

프로세스가 스케줄링 큐를할때의 도식

 

프로세스가 CPU를 부여하기전 Ready queue에 담겨졌습니다. 그 이후, 프로세스가 실행되다가 I/O 요청을 하게되면 I/O 작업을 하기위해서 I/O queue에 들어가게됩니다 이때 오래걸리기때문에 CPU를 내려놓고 수행을 다 하게된다면 ready queue로 들어갑니다.

만약 CPU를 가지고 I/O 작업과같은 오랜작업을 실행하게되면 Interrupt을 통해 알려줍니다. I/O을 하러가는 상황이라면 Interrupt을 기다리면서 대기하다가 interrupt가 발생하면 ready queue 로 갑니다

Thread

프로세스 내부에 CPU 수행단위가 여러개있는 경우에 그 수행단위를 Thread라고 합니다.

쓰레드의 내부 모습 ,PCB가 Thread를 얻었을때 모습

 

code,data, stack의 주소공간이 프로세스마다 생성됩니다. 이때 프로세스 하나를 관리하기위해서 운영체제 내부에 PCB를 두게됩니다. 만약 동일한 일을 하는 프로세스가 여러개 있다는 가정하에 별도의 행동을하게되면 별도의 여러개의 메모리 주소가 만들어지게됩니다 (메모리 낭비 현상)

같은일을하는 프로세스들을 여러개 띄어놓고싶다면 메모리공간을 하나만 띄워놓고 프로세스마다 각 다른 부분의 코드를 실행해주면됩니다 (쓰레드의 개념)

 

Thread의 개념 설명

 

즉, 프로세스는 하나만 띄우고 현재 CPU가 코드 어느부분을 실행하고있는가 알기위해서 프로그램 카운터만 여러개 두는것입니다. CPU수행을 위해 (기계어를 실행하기위해) 현재 코드 어느 부분을 실행하고있는지 알기위해선 Program Counter가 필요하고 CPU에서 실행되는 메모리에  Register값들을 세팅해놓고 실행되어야합니다. 

각 쓰레드 마다(각 CPU 수행단위) 현재 Register에 값을넣고 Program Counter가 코드 어느 부분을 가리키면서 실행하고있었는가를 별도로 유지하고있다라고 생각하시면 될것같습니다. 프로세스는 하나이기때문에 프로세스 상태도 쓰레드간에서 공유하는 개념이되기때문에 프로세스가 사용하는 각종자원들끼리는 쓰레드끼리 공유해야만 합니다.  그러나 별도로 가지고있는 고유의 자원들은 CPU 수행과 관련된 정보들임을 중요시 여겨야합니다 (Register, Stack, Program Counter)

 

그럼 우리는 왜 쓰레드를 두는것일까요? 

하나의 프로세스를 여러개의 쓰레드를 두게되면 응답시간이 빨라집니다.

예를들어 웹브라우저에 네이버를 본다고 가정한다면 네트워크를 통해 웹페이지를 읽어오는 작업(I/O 작업) 을 하게되면 I/O 작업은 오래걸리기때문에 (blocked 상태) 사용자 입장에서는 답답하다고 느낍니다. 이때 쓰레드의 역할은 웹브라우저에 쓰레드를 여러개 두면 하나의 쓰레드가 그림을 불러오는동안 다른 쓰레드를 빨리 불러오는(Text 역할) 역할을 할수있습니다 결국 우리는 빠른응답성, 자원 절약을 할수있다고 봅니다.

PCB 내부의 Thread 관리

 

프로세스마다 하나의 PCB가 만들어져 운영체제가 관리합니다. 프로세스는 하나기때문에 PCB도 하나입니다만, PCB안에 쓰레드가 여러개있으면 CPU 수행과 관련된 정보만 각각 쓰레드마다 별도의 Copy를 가지게 됩니다 (Register, Program Counter)

 

결론적으로 프로세스라는건 메모리 주소공간에 Code,Data,Stack이 존재하고, 각 프로세스마다 PCB가 있으면서 Thread는 프로세스 안에서 독자적인 정보를 갖게되는것을 아시면 될것같습니다. (공유할건 프로세스 안에서만)

 

 

쓰레드의 장점은 무엇일까요?

 

CPU가 1개이상일때의 장점 

응답성

웹브라우저에서 여러개의 Thread가 있다고 가정해봅시다. 포털사이트 홈페이지 주소를 입력하면 HTML 문서를 가져오는 I/O 작업을 하게되지만 이미지와 TEXT로 나눠생각해보겠습니다. 이미지를 갖고오기위해선 오래걸리는 작업이기때문에 프로세스를 잠시 Blocked 시킵니다. 이때 사용자들은 매우 불편함을 느끼게됩니다. 하지만 A쓰레드가 이미지작업, B쓰레드가 Text 작업 등.. 여러개를 나눈다면 A쓰레드만 Blocked된상태로 B,C,D 쓰레드를 먼저 호출시킬수있게됩니다. 이는 이미지나 요청많이걸리는 작업을 제외한 일들을 병렬적으로 처리할수있습니다 

우리는 비동기식 입출력이라고 생각할수있습니다 I/O 작업을 무시한채 쓰레드는 다른일들을 갖고오기때문입니다. 또한 응답성 부분또한 해결할수있습니다. 

 

자원공유

똑같은일들을 하는 기능을 별도의 프로세스를 나누는것보단 여러쓰레드를 두어서 자원공유를 통해서 효율적으로 사용할수있지않을까요??

 

Economy(경제성이라곤 하지만 응답성과 별개로 빠르다라고 생각하자)

프로세스 만드는 자체행위는 Overhead가 상당히 큽니다. 프로세스안에 여러 쓰레드를 만드는것이 훨씬더 Overhead 비용이 적게 드는것입니다.

또한 문맥교환 자체에서 오버헤드가 굉장히 큽니다 (프로세스 to 프로세스), 프로세스 내부에선 쓰레드간의 문맥교환은 대단히 간단하다고 볼수있습니다.

 

CPU가 여러개여야 얻을수있는 장점

MP 아키텍쳐의 유용성

프로세스는 하나지만 그안에 쓰레드가 여러개있으면 또 각각의 쓰레드가 서로 다른 CPU에서 병렬적으로 일할수있기때문에 빠른결과를 얻어낼수있습니다. 

 

쓰레드의 종류 

커널의 지원을 받으면 커널쓰레드, 그게 아니라면 유저레벨 쓰레드입니다. 또한 Real-time Thread도 존재합니다.