1. 프로세스와 쓰레드의 차이
프로세스는 운영체제로부터 자원을 할당받는 작업의 단위이다. 실행 중인 프로그램의 인스턴스로, 독립된 메모리 공간을 가지고, 다른 프로세스의 메모리에 직접 접근할 수 없다. (프로세스 간 통신 위해서는 IPC 필요)
반면 쓰레드는 프로세스 내에서 실행되는 작업의 단위로, 같은 프로세스의 다른 쓰레드와 메모리를 공유한다. (프로세스 간 통신보다 더 쉽고 빠르다.) 한 쓰레드에 문제가 생기면 같은 프로세스 내의 다른 쓰레드에도 영향을 줄 수 있다.
프로세스는 각각의 독립된 회사라고 생각할 수 있다. 각 회사는 자체 사무실, 직원, 자원을 가지고 있으며, 다른 회사의 내부에 직접 접근할 수 없다. 회사 간 협력을 위해서는 공식적인 의사소통 채널(이메일, 회의)이 필요하다.
쓰레드는 한 회사 내의 여러 부서나 팀과 같다. 이들은 같은 사무실 공간과 회사 자원을 공유하며, 서로 쉽게 의사소통할 수 있다. 하지만 다른 팀에 문제가 생기면 다른 팀의 작업에도 영향을 줄 수 있다.
프로세스는 각각 독립된 식당이라고 생각할 수 있다. 각 식당은 자체 주방, 재료, 직원을 가지고 있다.
쓰레드는 한 식당에서 일하는 요리사다. 요리사들은 같은 주방과 재료를 공유하면서 각자의 요리를 만든다.
2. 멀티 프로세스와 멀티 쓰레드의 특징
멀티 프로세스는 여러 개의 프로세스가 동시에 실행되는 것으로, 각 프로세스는 독립적이다. 한 프로세스가 죽어도 다른 프로세스에 영향을 주지 않아 안정성이 높다. 프로세스 생성과 컨텍스트 스위칭에 많은 비용이 든다. 프로세스 간 통신이 복잡하고(IPC) 오버헤드가 크다. (ex: 웹 브라우저 각 탭, 여러 응용 프로그램 동시 실행)
멀티 쓰레드는 프로세스 내에서 여러 쓰레드가 실행되는 것으로, 자원을 공유가 쉽고, 컨텍스트 스위칭 비용이 적다. 응답 시간이 빠르고 처리량이 높다. 하지만 한 쓰레드의 오류가 전체 프로세스에 영향 줄 수 있고, 동기화 문제가 발생할 수 있다. (ex: 웹 서버, db관리 시스템)
멀티 프로세스는 여러 개의 체인점을 운영하는 것과 같다. 각 지점은 완전히 독립적으로 운영되어 한 지점의 문제가 다른 지점에 영향을 주지 지 않는다.
하지만 각 지점을 설립하고 관리하는 데 많은 비용이 들며, 지점 간 협력이 필요할 때는 복잡한 절차가 필요하다.
멀티 쓰레드는 한 대형 식당 안에서 여러 요리사와 직원이 협력하여 일을 하는 것과 같다. 자원을 쉽게 공유하고 빠르게 의사소통할 수 있어 효율적이다. 하지만 한 요리사의 실수가 전체 식당의 운영에 영향을 줄 수 있으며, 주방 기구 사용이나 작업 순서를 조율하는 데 주의가 필요하다.
3. 멀티 쓰레드의 동시성과 병렬성
동시성은 여러 작업이 번갈아가며 실행되어 동시에 실행되는 것처럼 보이는 것이다. 실제로는 짧은 시간 단위로 작업을 번갈아 수행한다. 단일 코어에서도 구현 가능하다. 입출력 작업이 많은 경우 효율적이다.
병렬성은 여러 작업이 실제로 동시에 실행되는 것이다. 멀티 코어 프로세서에서 실제로 여러 작업을 동시에 수행한다. 계산 집약적인 작업에서 효율적이다.
멀티 쓰레드 환경에서는 동시성과 병렬성이 모두 가능하다.
동시성은 한 명의 요리사가 여러 요리를 번갈아가며 조금씩 만드는 것과 같다. 파스타 물을 끓이는 동안 샐러드를 준비하고, 소스가 졸아드는 동안 고기를 굽는 등 여러 작업을 번갈아 수행한다. 겉보기에는 모든 요리가 동시에 진행되는 것처럼 보이지만, 실제로는 요리사가 빠르게 작업을 전환하며 진행하고 있다.
병렬성은 여러 요리사가 각자의 요리를 동시에 만드는 것과 같다. 한 요리사는 파스타를 만들고, 다른 요리사는 스테이크를 굽고, 또 다른 요리사는 디저트를 준비하는 식으로 동시에 진행된다.
4. 멀티 쓰레드 환경에서의 주의사항
멀티 쓰레드 환경에서는 공유 자원에 대한 동기화, 데드락 방지, 경쟁 상태(race condition) 관리, 과도한 쓰레드 생성 방지 등에 주의해야 한다.
- 동기화(Synchronization): 공유 자원에 대한 접근을 제어하여 데이터 일관성을 유지해야 한다.
- 데드락(Deadlock) 방지: 쓰레드 간 자원 요청과 할당을 신중히 관리하여 상호 대기 상태를 피해야 한다.
- Race Condition 관리: 여러 쓰레드가 동시에 같은 데이터를 수정하려 할 때 발생할 수 있는 문제를 방지해야 한다.
- 과도한 쓰레드 생성 방지: 너무 많은 쓰레드를 생성하면 시스템 리소스를 과도하게 사용하고 성능이 저하될 수 있다.
- 쓰레드 안전성(Thread Safety): 동시에 여러 쓰레드에서 안전하게 호출될 수 있는 코드를 작성해야 한다.
- 컨텍스트 스위칭 오버헤드 고려: 너무 빈번한 쓰레드 전환은 성능 저하를 일으킬 수 있다.
여러 요리사가 한 주방에서 일할 때, 칼이나 불 사용 순서를 정하고, 서로 기다리다 아무도 일을 못하는 상황을 피하며, 재료를 동시에 가져가려는 것을 방지하고, 너무 많은 요리사를 고용하지 않도록 주의해야 하는 것과 같다.
- 동기화: 요리사들이 같은 칼이나 조리대를 사용할 때 서로 충돌하지 않도록 규칙을 정해야 한다.
- 데드락 방지: 두 요리사가 서로의 도구를 기다리며 아무도 일을 못 하는 상황을 방지해야 한다.
- Race Condition 관리: 여러 요리사가 동시에 같은 수프 냄비에 간을 하려 할 때 발생할 수 있는 문제를 예방해야 한다.
- 과도한 쓰레드 생성 방지: 주방 크기에 비해 너무 많은 요리사를 고용하면 오히려 효율이 떨어지는 것과 같다.
- 쓰레드 안전성: 여러 요리사가 동시에 사용해도 문제가 없는 조리 도구와 레시피를 사용해야 한다.
- 컨텍스트 스위칭 오버헤드 고려: 요리사가 너무 자주 다른 요리로 전환하면 전체적인 요리 시간이 늘어날 수 있다.
5. 데드락
데드락은 두 개 이상의 프로세스나 쓰레드가 서로가 가진 자원을 기다리며 무한히 대기하는 상태이다.
- 상호 배제(Mutual Exclusion): 최소한 하나의 자원이 비공유 모드로 점유되어야 한다
- 점유 대기(Hold and Wait): 자원을 가진 프로세스가 다른 자원을 기다릴 때 보유 자원을 놓지 않는다
- 비선점(No Preemption): 자원을 강제로 빼앗을 수 없다
- 순환 대기(Circular Wait): 프로세스의 집합에서 순환 형태로 자원을 기다린다
데드락을 해결하기 위한 방법으로는 예방, 회피, 탐지 및 복구 등이 있다.
데드락은 좁은 골목길에서 마주 오는 두 대의 차가 서로 양보하지 않고 계속 대치하는 상황과 같다. 양쪽 운전자 모두 자신의 차를 뒤로 빼지 않고 상대방이 먼저 빠져나가기를 기다린다. 이 상황에서:
- 차들은 프로세스나 쓰레드를 나타낸다.
- 좁은 골목길은 공유 자원이다.
- 차가 지나갈 수 있는 공간은 한 번에 하나뿐이다(상호 배제).
- 양쪽 모두 자신의 위치를 고수한다(점유 대기).
- 강제로 차를 밀어낼 수 없다(비선점).
- 서로가 서로의 양보를 기다린다(순환 대기).
이 상황을 해결하려면 한 쪽이 양보하거나(예방), 교통 통제원이 개입하거나(회피), 외부에서 상황을 파악하고 한 차를 강제로 후진시키는(탐지 및 복구) 등의 방법이 필요하다.
6. 콘보이 현상 (convoy effect)
콘보이 현상은 짧은 프로세스들이 긴 프로세스 뒤에서 대기하며 지연되는 현상이다. 이는 주로 FIFO 알고리즘에서 발생할 수 있다.
주로 다음과 같은 문제가 발생한다.
- 시스템의 전체적인 처리량 감소
- 짧은 작업의 대기 시간 증가
- CPU와 I/O 장치의 비효율적 사용
이를 해결하기 위해 SJF(Shortest Job First)나 라운드 로빈(Round Robin) 같은 다른 스케줄링 알고리즘을 사용할 수 있다.
고속도로 톨게이트에서 현금으로 요금을 내는 차량 한 대가 앞에 있고, 그 뒤로 하이패스를 사용하는 여러 차량이 줄지어 기다리는 상황과 같다.
- 현금 결제 차량은 긴 프로세스를 나타낸다.
- 하이패스 차량들은 짧은 프로세스들이다.
- 톨게이트는 CPU를 의미한다.
이 상황에서 하이패스 차량(짧은 프로세스들)은 현금 결제 차량(긴 프로세스) 때문에 불필요하게 오래 기다려야 한다. 이는 전체 시스템의 처리량을 떨어뜨리고 대기 시간을 증가 시킨다.
이 문제를 해결하기 위해서는 하이패스 전용 레인(SJF)을 만들거나, 일정 시간마다 차량을 번갈아 통과시키는(RR) 방식을 도입할 수 있다.
7. 선점형 스케줄링과 비선점형 스케줄링의 차이
선점형 스케줄링은 실행 중인 프로세스를 중단하고 다른 프로세스에게 CPU를 할당할 수 있는 방식이다. 응답 시간이 빠르다. 컨텍스트 스위칭이 자주 일어나 오버헤드가 크다. (ex: RR, SRT)
비선점형 스케줄링은 자발적으로 CPU를 반환할 때까지 기다리는 방식이다. 컨텍스트 스위칭이 적어 오버헤드가 작지만 긴급한 작업의 처리가 지연될 수 있다. (FIFO, SJF)
선점형 스케줄링은 응급 환자가 오면 현재 진료 중인 환자를 잠시 중단하고 응급 환자를 먼저 처치하는 응급실과 같다. 의사(CPU)는 언제든 현재 환자의 진료를 중단하고 더 위급한 환자를 볼 수 있다. 빠른 대응이 가능하지만, 환자(프로세스)를 자주 바꾸면 의사가 각 환자의 상태를 다시 파악하는 데 시간이 걸린다.(컨텍스트 스위칭 오버헤드)
비선점형 스케줄링은 한 환자의 진료가 끝날 때까지 다른 환자들이 기다리는 병원과 같다. 의사(CPU)는 현재 환자의 진료가 끝날 때까지 계속 진료한다. 하지만 응급 상황(위급한 프로세스)에 빠르게 대처하기 어렵다.
8. 동기와 비동기의 차이
동기 방식은 작업이 완료될 때까지 기다렸다가 다음 작업을 수행하는 방식이다. 작업이 순차적으로 실행되며 한 작업이 완료될 때까지 다음 작업이 블록된다. 코드의 실행 순서가 예측 가능하고 디버깅이 쉽다. 하지만 긴 작업이 있을 경우 전체 프로그램의 응답성이 떨어질 수 있다. (ex: 파일 읽기/쓰기, 쿼리 실행)
비동기 방식은 작업의 완료를 기다리지 않고 다음 작업을 진행하는 방식이다. 콜백 함수, Promise, async/await 등을 사용해 구현한다. I/O 바운드 작업에서 효율적이며, 전체 프로그램의 응답성이 향상된다. 코드의 실행 순서가 예측하기 어려울 수 있어 디버깅이 복잡할 수 있다. (ex: AJAX요청, 이벤트 리스너)
패스트푸드 주문 시스템을 떠올렸을 때,
동기(Synchronous):
- 주문을 하고 그 자리에서 음식이 나올 때까지 기다리는 방식이다.
- 주문한 사람(프로세스)은 음식(작업 결과)이 나올 때까지 다른 일을 하지 못하고 기다려야 한다.
- 음식이 나오는 순서가 예측 가능하고, 주문과 수령이 바로 연결된다(디버깅이 쉽다).
- 하지만 주문이 복잡하면 뒤의 손님들(다른 작업들)이 오래 기다려야 한다.
비동기(Asynchronous):
- 주문을 하고 진동벨을 받아 자리에 가서 기다리는 방식이다.
- 주문한 사람(프로세스)은 음식(작업 결과)을 기다리는 동안 다른 일(다른 작업)을 할 수 있다.
- 진동벨이 울리면(콜백) 음식을 가지러 간다.
- 여러 주문이 동시에 처리될 수 있어 효율적이지만, 음식이 나오는 순서가 주문 순서와 다를 수 있다(실행 순서 예측이 어렵다).
9. 임계 영역 (Critical Section)
임계 영역은 여러 프로세스가 공유하는 자원에 접근하는 코드 영역으로, 한 번에 하나의 프로세스만 접근할 수 있어야 한다. 임계 영역을 해결하기 위한 세 가지 조건은 다음과 같다.
- 상호 배제(Mutual Exclusion): 한 프로세스가 임계 영역에서 실행 중이면 다른 프로세스는 진입할 수 없다
- 진행(Progress): 임계 영역에서 실행 중인 프로세스가 없다면, 진입하려는 프로세스가 들어갈 수 있어야 한다
- 한정 대기(Bounded Waiting): 프로세스가 임계 영역에 진입하려고 요청한 후부터 허용될 때까지 다른 프로세스들이 임계 영역에 진입하는 횟수에 한계가 있어야 한다
이를 위해 세마포어, 뮤텍스 등의 동기화 도구를 사용한다.
임계 영역은 공용 화장실과 같다.
- 화장실은 여러 사람(프로세스)이 사용하지만, 한 번에 한 사람만 들어갈 수 있다.
- 화장실 문 앞에는 "사용 중" 표시등(잠금 장치)이 있어 누군가 사용 중일 때 다른 사람이 들어가지 못하게 한다(상호 배제).
- 화장실이 비어있으면 기다리는 사람 중 누군가는 반드시 들어갈 수 있어야 한다(진행).
- 화장실을 기다리는 사람들은 너무 오래 기다리지 않고 결국에는 사용할 수 있어야 한다(한정 대기).
여기에서:
- 화장실은 공유 자원이다.
- 사람들은 프로세스나 쓰레드다.
- "사용 중" 표시등은 잠금 장치(lock)다.
- 화장실 사용 규칙은 동기화 메커니즘이다.
10. 뮤텍스(Mutex)와 세마포어(Semaphore)의 차이
뮤텍스는 한 번에 하나의 스레드만 접근을 허용하는 동기화 기구다. 이진(0 또는 1) 상태만 가진다. 한 번에 하나의 쓰레드만 접근을 허용한다. 소유권 개념이 있어, 락을 획득한 쓰레드만 해제 가능하다. 주로 상호 배제를 위해 사용한다.
세마포어는 여러 쓰레드의 접근을 허용할 수 있는 더 일반적인 동기화 도구다. 0 이상의 정수 값을 가질 수 있다. 카운팅 세마포어의 경우, 여러 쓰레드의 동시 접근을 허용할 수 있다. 상호 배제뿐만 아니라 프로세스 동기화에도 사용한다.
이 둘의 차이는 화장실 열쇠와 주차장 시스템으로 설명할 수 있다.
뮤텍스(화장실 열쇠):
- 화장실에는 하나의 열쇠만 있다.
- 한 번에 한 사람만 열쇠를 가질 수 있고, 화장실을 사용할 수 있다.
- 열쇠를 가진 사람만 화장실 문을 잠그고 열 수 있다(소유권 개념).
- 사용이 끝나면 반드시 열쇠를 반납해야 다른 사람이 사용할 수 있다.
세마포어(주차장 시스템):
- 주차장에는 여러 개의 주차 공간이 있다.
- 입구의 전광판은 남은 주차 공간의 수를 보여준다(정수 값).
- 차가 들어오면 숫자가 줄고, 나가면 숫자가 늘어난다.
- 주차 공간이 있으면(숫자가 0보다 크면) 여러 차가 동시에 들어올 수 있다.
- 누구나 주차장을 나갈 때 전광판의 숫자를 증가시킬 수 있다(소유권 개념 없음).
11. 페이지 교체 알고리즘
페이지 교체 알고리즘은 VM에서 메모리가 부족할 때 어떤 페이지를 교체할지 결정하는 알고리즘이다. FIFO, LRU, LFU 등이 있다.
꽉 찬 책장에서 새 책을 넣기 위해 어떤 책을 빼낼지 결정하는 방법과 같다. 가장 오래된 책을 빼거나, 가장 오랫동안 읽지 않은 책을 빼거나, 가장 적게 읽은 책을 빼는 등 방법이 있다.
12. 컨텍스트 스위칭(Context Switching)
현재 실행 중인 프로세스나 쓰레드의 상태를 저장하고 다른 프로세스나 쓰레드로 전환하는 과정이다.
- 현재 프로세스의 상태 저장 (레지스터 값, 프로그램 카운터 등)
- 해당 프로세스의 PCB(Process Control Block)를 업데이트한다
- 새로운 프로세스의 PCB를 로드한다
- 새 프로세스의 메모리 맵을 메모리 관리 유닛(MMU)에 로드한다
- 새 프로세스의 상태를 복원한다
컨텍스트 스위칭은 멀티태스킹 운영체제에서 필수적이지만, 너무 자주 발생하면 오버헤드로 인해 시스템 성능이 저하될 수 있다. 따라서 효율적인 스케줄링 알고리즘과 적절한 시간 할당이 중요하다.
컨텍스트 스위칭은 요리사가 한 요리에서 다른 요리로 전환하는 것과 같다. 현재 요리의 상태를 기억하고 메모해두었다가 나중에 다시 그 요리로 돌아와 이어서 만드는 과정과 유사하다.
- 현재 요리의 상태를 기록한다(현재 프로세스 상태 저장).
- 예: "파스타 소스는 약불에서 5분간 더 끓이기"
- 요리 레시피 북에 현재 진행 상황을 메모한다(PCB 업데이트).
- 예: "파스타 페이지에 현재 상태 기록"
- 다음 요리의 레시피와 진행 상황을 확인한다(새 프로세스의 PCB 로드).
- 예: "스테이크 요리법 펼치고 진행 상황 확인"
- 다음 요리에 필요한 재료와 도구를 준비한다(메모리 맵 로드).
- 예: "스테이크, 양념, 그릴 팬 준비"
- 다음 요리를 이어서 만들기 시작한다(새 프로세스 상태 복원).
- 예: "스테이크 굽기 시작"
이 과정에서 요리사(CPU)는 각 요리(프로세스) 사이를 전환하면서 모든 요리를 조금씩 진행시킨다. 하지만 너무 자주 요리를 바꾸면 각 요리의 상태를 파악하고 도구를 바꾸는 데 시간이 많이 소요될 수 있다(오버헤드). 따라서 효율적인 요리 순서(스케줄링 알고리즘)와 각 요리에 적절한 시간 배분이 중요하다.
'CS' 카테고리의 다른 글
CS_운영체제_멀티프로세스, 스레드와 멀티 스레딩 (1) | 2024.06.30 |
---|---|
CS_운영체제_교착상태 (0) | 2024.06.30 |
CS_동기화(Synchronization)_스핀락, 뮤텍스, 세마포어 (0) | 2024.06.30 |
CS_운영체제_Paging: Smaller Table (0) | 2024.06.25 |
CS_운영체제_TLB (0) | 2024.06.25 |