반응형

프로세스와 스레드 차이?

프로세스는 운영체제로부터 자원을 할당받는 작업의 단위이고

스레드는 프로세스가 할당받은 자원을 이용하는 실행의 단위이다.


즉, 프로그램에서 프로세스로 메모리에 올라올 때 운영체제로부터 프로세스를 운영하기 위해 필요한 주소 공간, 메모리(Text, Data, Heap, Stack 공간)를 부여받게 되고  스레드는 한 프로세스 내에서 동작되는 여러 실행의 흐름으로, 프로세스 내의 주소 공간이나 자원들을 같은 프로세스 내의 스레드끼리 공유하며 실행된다.




즉, 스레드는 프로세스 내에서 각각의 스택 공간을 제외한 나머지 공간과 시스템 자원을 공유한다.그러므로 프로세스를 이용하여 동시에 처리하던 일을 스레드로 구현할 경우 메모리 공간은 물론 시스템 자원 소모도 현격히 줄어들게 된다. 하나의 프로세스에서 여러 스레드가 존재하게 되니 스레드 간의 통신이 필요한 경우 별도의 자원을 이용하는 것이 아니라 메모리 공간을 공유하므로 데이터 세그먼트, 즉 전역 변수를 이용하여 구현한다. 그런데 공유하는 전역 변수를 여러 스레드가 함께 사용하게되면 충돌이 발생하게된다. 따라서 스레드 간에 통신할 경우에는 충돌 문제가 발생하지 않도록 동기화 문제를 해결해야 한다.

스레드의 장점을 정리하면 다음과 같다.  

- 시스템의 처리량이 향상된다.  

- 시스템의 자원 소모가 줄어든다  

- 프로그램의 응답 시간이 단축된다.  

- 프로세스 간 통신 방법에 비해 스레드 간의 통신 방법이 훨씬 간단하다.


스레드는 장점만 갖고 있는 것이 아니라 다음과 같은 단점도 지니고 있다.

- 여러 개의 스레드를 이용하는 프로그램을 작성하는 경우에는 크리티컬 섹션을 잘 관리하여 여러 스레드가 함께 공유 자원을 이용하는데 오류가 없도록 해야한다.

- 프로그램 디버깅이 어렵다.

- 단일 프로세서 시스템에서는 효과를 기대하기 어렵다.



스레드를 쓰는 이유?

운영체제는 시스템 작업을 효율적으로 관리하기 위해 스레드를 이용한다.

즉, 멀티 프로세스로 실행되는 작업을 멀티 스레드로 실행하게 되면 프로세스를 생성하여 자원을 할당하는 과정도 줄어들 뿐더러 프로세스를 컨텍스트 스위칭(Context Switching)하는 것 보다 오버헤드를 더 줄일 수 있게 된다.

뿐만 아니라 프로세스간의 통신 비용보다 하나의 프로세스 내에서 여러 스레드간의 통신 비용이 훨씬 적으므로 작업들 간의 통신 부담을 줄일 수 있게 된다.


예를들어보자. 구글 docs를 이용하여 어떤 문서를 함께 작성해야한다.

이때 하나의 구글 docs를 프로세스라 생각하고 문서에 참여하는 사용자를 스레드라 생각해보자.

만약 멀티 프로세스라면 사용자 한명당 하나의 구글 docs를 켜서 자신이 해야하는 임무를 마무리 하고 도출된 결과를 합쳐야 할 것이고

멀티 스레드라면 하나의 구글 docs에서 여러 사람들이 분배받은 커서를 이용하여 자신의 임무를 마무리 하면 된다.

위 예시를 살펴보면 여러 구글 docs가 아닌 하나의 구글 docs를 만들었기에 자원 할당에서도 유리한 모습을 보였고, 모든 구글 docs를 하나의 구글 docs로 합치는 것을 통신 비용이라 생각한다면 하나의 구글 docs에서 여러 사용자들이 함께 임무를 수행하는게 더 효율적이라고 쉽게 생각 할 수 있다.





PCB vs TCB

PCB는 OS의 스케줄러에 의해 Context Switching되는 프로세스의 정보 단위를 의미하고 TCB는 스레드 라이브러리에의해  Context Switching되는 스레드의 정보 단위를 의미한다.


즉, 우리가 흔히 배우는 OS의 스케줄러가 스케줄링 해주는 것은 프로세스의 PCB이고, TCB는 프로세스에 있는 스레드 라이브러리에 의해 스케줄링 되는 것이다.

그래서 컨텍스트 스위칭이 일어날 때 멀티 프로세스를 통해 PCB를 컨텍스트 스위칭 하는 것 보다 멀티 스레드를 통해 TCB를 컨텍스트 스위칭 하는 것이 더 오버헤드가 적다는 것이다.(위의 그림만 봐도 TCB가 PCB보다 작은 크기를 가지고 있다.)







반응형