프로세스와 스레드편집자 확인

프로세스는 실행 중인 프로그램을 의미한다. 디스크에 저장된 정적인 명령어와 데이터의 집합인 프로그램과 달리, 프로세스는 그 프로그램이 메모리에 적재되어 운영체제에 의해 실행되는 동적인 실체이다. 운영체제는 각 프로세스에게 독립된 주소 공간, CPU 시간, 파일, 입출력 장치 등의 자원을 할당하고 관리한다.

프로세스는 최소한 하나의 실행 흐름, 즉 스레드를 포함하며, 고유한 프로세스 식별자(PID)로 구분된다. 각 프로세스는 일반적으로 코드(텍스트 섹션), 데이터, 힙(Heap) 영역, 스택(Stack) 영역으로 구성된 독립된 메모리 공간을 가진다. 이로 인해 한 프로세스의 메모리는 다른 프로세스가 직접 접근할 수 없으며, 이는 시스템의 안정성과 보안을 보장하는 핵심 메커니즘이다.

프로세스의 생명주기는 생성, 준비, 실행, 대기, 종료 등의 상태를 거친다. 프로세스는 fork()나 exec() 같은 시스템 호출을 통해 생성되며, 작업이 완료되거나 강제 종료되면 소멸한다. 운영체제는 프로세스 제어 블록(PCB)에 각 프로세스의 상태, 프로그램 카운터, 레지스터 정보, 메모리 관리 정보 등을 기록하여 관리한다.

프로세스 제어 블록(PCB)은 운영체제가 프로세스를 관리하기 위해 유지하는 자료 구조이다. 각 프로세스가 생성될 때마다 고유한 PCB가 만들어지며, 프로세스가 종료되면 PCB도 함께 소멸된다. 운영체제는 실행 중인 모든 프로세스의 PCB를 관리하여 프로세스 스케줄링과 상태 관리를 수행한다.

PCB에는 프로세스를 식별하고 상태를 복원하는 데 필요한 모든 정보가 담겨 있다. 주요 구성 요소는 다음과 같다.

문맥 교환(Context Switch)이 발생하면, 실행 중이던 프로세스의 상태(레지스터 값, 프로그램 카운터 등)를 해당 프로세스의 PCB에 저장한다. 그 후 실행할 프로세스의 PCB에서 저장된 상태를 복원하여 CPU에 적재한다. 이 과정을 통해 프로세스는 중단된 지점부터 정확히 실행을 재개할 수 있다. 따라서 PCB는 프로세스의 실행 역사를 보관하는 핵심 데이터 구조 역할을 한다.

프로세스는 실행 중에 여러 상태를 거치며 변화한다. 이러한 상태 변화는 운영체제의 프로세스 스케줄링에 의해 관리되며, 일반적으로 다섯 가지 기본 상태로 모델링된다.

상태 변화는 특정 사건에 의해 트리거된다. 실행 상태의 프로세스는 타임 슬라이스가 만료되거나 더 높은 우선순위의 프로세스가 나타나면 준비 상태로 돌아간다. 또한, 입출력 요청과 같은 시스템 호출을 하면 대기 상태로 전환된다. 대기 상태의 프로세스는 기다리던 사건이 발생하면 준비 상태로 이동하여 다시 프로세서 할당을 기다린다. 준비 상태에서 실행 상태로의 전환은 스케줄러의 결정에 따라 이루어진다. 일부 시스템에서는 일시 중지(Suspend) 상태를 추가로 도입하여 메모리 부족 시 프로세스를 보조 저장장치로 이동시키기도 한다[1].

스레드는 프로세스 내에서 실행되는 흐름의 단위이다. 하나의 프로세스는 최소 하나의 스레드(메인 스레드)를 가지며, 여러 개의 스레드를 생성하여 동시에 작업을 수행할 수 있다. 이를 멀티스레딩이라고 한다. 스레드는 프로세스의 코드, 데이터, 힙 영역과 같은 자원을 공유하지만, 각 스레드는 독립적인 스택 영역과 프로그램 카운터, 레지스터 집합을 가진다.

스레드는 프로세스에 비해 생성 및 문맥 교환 비용이 적게 든다. 이는 스레드가 메모리 공간을 공유하기 때문에 새로운 주소 공간을 할당하거나 복사할 필요가 없기 때문이다. 또한, 같은 프로세스 내의 스레드들은 데이터와 힙 영역을 공유하기 때문에 통신이 간편하지만, 이로 인해 동기화 문제가 발생할 수 있다.

스레드는 크게 사용자 스레드와 커널 스레드로 구분된다. 사용자 스레드는 사용자 수준의 라이브러리에 의해 관리되고, 커널 스레드는 운영체제 커널에 의해 직접 관리된다. 이 두 모델의 차이는 스케줄링과 블로킹 처리 방식에 영향을 미친다.

스레드는 운영체제에 의해 관리되는 방식에 따라 사용자 스레드와 커널 스레드로 구분된다. 이 구분은 스레드의 생성, 스케줄링, 관리 주체가 어디에 있는지에 따라 결정된다.

사용자 스레드는 커널의 지원 없이 사용자 수준의 스레드 라이브러리에 의해 완전히 관리된다. 운영체제는 이 스레드들의 존재를 인식하지 못하며, 하나의 프로세스를 단일 실행 단위로 본다. 따라서 스레드 간의 전환에 커널 모드로의 전환이 필요 없어 문맥 교환 비용이 매우 낮다. 그러나 한 스레드가 블로킹 시스템 호출을 하면, 운영체제는 해당 프로세스 전체를 블록 상태로 간주하기 때문에 같은 프로세스 내의 다른 모든 스레드도 실행을 멈추게 된다는 단점이 있다. 또한 멀티프로세서 시스템에서 여러 스레드를 서로 다른 CPU에 동시에 분배하는 진정한 병렬 처리를 구현하기 어렵다.

반면, 커널 스레드는 운영체제 커널이 직접 생성하고 스케줄링한다. 각 스레드는 커널이 인식하는 독립적인 스케줄링 단위가 된다. 따라서 한 스레드가 블록되어도 같은 프로세스 내의 다른 스레드는 계속 실행될 수 있다. 또한 멀티프로세서 환경에서 하나의 프로세스에 속한 여러 스레드가 서로 다른 프로세서에서 동시에 실행될 수 있다. 단점은 스레드 간 전환 시 커널 모드로의 전환이 필수적이어서 사용자 공간에서의 전환보다 문맥 교환 비용이 더 크다는 점이다.

일부 시스템은 혼합형 스레딩 모델을 사용하여 두 방식을 결합하기도 한다. 예를 들어, 여러 사용자 스레드가 더 적은 수의 커널 스레드에 매핑되어, 사용자 수준의 효율성과 커널 수준의 병렬성 장점을 모두 취하려고 시도한다.

스레드는 프로세스 내에서 실행되는 흐름의 단위로, 같은 프로세스에 속한 스레드들은 메모리 공간과 자원을 공유한다. 이 구조는 여러 장점을 제공하지만, 동시에 특정 단점과 주의 사항을 수반한다.

스레드 사용의 가장 큰 장점은 효율성이다. 새로운 프로세스를 생성하는 것에 비해 스레드를 생성하고 문맥을 전환하는 비용이 훨씬 적게 든다. 또한, 같은 프로세스 내의 스레드들은 힙 메모리, 파일 핸들, 전역 변수 등의 자원을 공유하기 때문에 데이터 교환이 쉽고 빠르다. 이는 스레드 간 통신이 복잡한 프로세스 간 통신 기법보다 간단하다는 의미이다. 멀티코어 또는 멀티프로세서 시스템에서는 여러 스레드를 각각 다른 코어에서 동시에 실행함으로써 진정한 병렬 처리를 달성하고 응용 프로그램의 성능을 크게 향상시킬 수 있다.

반면, 스레드는 공유 자원에 대한 접근으로 인해 복잡성을 증가시킨다. 한 스레드가 프로세스의 자원을 변경하면 다른 모든 스레드에 그 영향이 즉시 반영되므로, 동기화 없이는 데이터의 일관성이 깨질 위험이 크다. 이로 인해 경쟁 상태나 교착 상태와 같은 문제가 발생할 수 있다. 또한, 프로세스 내의 한 스레드가 비정상적으로 종료되거나 오류를 발생시키면, 공유 메모리 공간이 오염되어 전체 프로세스와 그 안의 다른 모든 스레드가 영향을 받고 종료될 수 있다. 이는 프로세스 간의 강력한 격리 보호가 없다는 단점이다.

따라서 스레드를 사용할 때는 뮤텐스나 세마포어와 같은 동기화 메커니즘을 통해 공유 자원을 보호하고, 스레드의 수를 시스템 자원에 맞게 적절히 조정하는 것이 중요하다.

프로세스는 운영체제로부터 독립된 자원을 할당받아 실행되는 단위이다. 각 프로세스는 별도의 주소 공간(Code, Data, Heap, Stack 영역), 파일 디스크립터, 그리고 기타 시스템 자원을 독점적으로 소유한다. 따라서 한 프로세스가 가진 자원에 접근하려면 특별한 프로세스 간 통신(IPC) 메커니즘을 사용해야 한다. 이는 안정성 측면에서는 하나의 프로세스가 비정상 종료되어도 다른 프로세스에 직접적인 영향을 미치지 않는다는 장점이 있다.

반면, 스레드는 하나의 프로세스 내에서 생성되는 실행 흐름의 단위이다. 동일한 프로세스에 속한 모든 스레드는 프로세스가 가진 자원을 공유한다. 이들은 같은 주소 공간과 파일, 신호 등을 공유하기 때문에, 한 스레드가 전역 변수를 변경하면 다른 모든 스레드가 그 변경 사항을 즉시 볼 수 있다. 자원 공유의 정도를 비교하면 다음과 같다.

이러한 자원 공유 방식의 차이는 성능과 복잡성에 직접적인 영향을 미친다. 스레드는 메모리와 같은 자원을 공유하므로 문맥 교환(Context Switch) 비용이 프로세스에 비해 훨씬 적고, 데이터 공유를 위한 통신 오버헤드도 낮다. 그러나 반대로, 공유 자원에 대한 동시 접근은 경쟁 조건(Race Condition)을 초래할 수 있어 뮤텍스나 세마포어와 같은 동기화 메커니즘을 반드시 사용해야 한다. 하나의 스레드가 오류로 비정상 종료되면 전체 프로세스가 종료될 위험도 있다.

프로세스의 생성과 소멸은 상대적으로 많은 비용이 소모되는 작업이다. 새로운 프로세스를 생성하려면 운영체제는 프로세스 제어 블록(PCB)을 할당하고, 독립된 주소 공간과 자원(파일 디스크립터, 메모리 영역 등)을 새로이 설정해야 한다. 이는 부모 프로세스의 주소 공간을 복제하는 fork 시스템 호출과 새로운 프로그램을 메모리에 적재하는 exec 시스템 호출을 포함하는 경우가 많다. 이 과정은 메모리 할당, 페이지 테이블 구성, 자원 관리 테이블 업데이트 등 상당한 운영체제 오버헤드를 유발한다.

반면, 스레드는 이미 존재하는 프로세스 내에서 생성되므로 비용이 훨씬 적게 든다. 스레드는 프로세스의 자원(메모리 공간, 열린 파일 등)을 공유하기 때문에, 새로운 주소 공간을 만들 필요가 없다. 운영체제는 주로 새로운 스레드를 위한 스택 영역과 스레드 제어 블록(TCB)만을 할당하면 된다. TCB는 PCB보다 관리하는 정보가 훨씬 적기 때문에 생성 및 등록 속도가 빠르고, 문맥 교환(context switch) 시에도 공유 메모리 영역을 교체할 필요가 없어 오버헤드가 낮다.

이 차이는 시스템의 반응성과 확장성에 직접적인 영향을 미친다. 많은 수의 동시 작업을 빠르게 생성하고 종료해야 하는 서버 애플리케이션(예: 웹 서버)에서는, 프로세스 기반 모델보다 스레드 기반 모델이 훨씬 효율적이다. 스레드는 적은 비용으로 생성되어 요청을 처리하고 종료될 수 있기 때문이다. 아래 표는 주요 비용 요소를 비교한 것이다.

따라서, 애플리케이션 설계 시 작업 단위의 빈번한 생성과 소멸이 예상된다면, 프로세스보다는 스레드를 사용하는 것이 시스템 성능에 유리하다. 그러나 스레드 간 동기화와 교착 상태 문제를 신중히 고려해야 한다.

프로세스 간 통신은 운영체제가 제공하는 별도의 IPC 메커니즘을 필요로 한다. 각 프로세스는 독립된 메모리 공간을 가지므로, 한 프로세스가 다른 프로세스의 데이터에 직접 접근하는 것은 불가능하다. 대신 공유 메모리, 파이프, 메시지 큐, 소켓 등의 방법을 통해 데이터를 교환한다. 이 과정은 상대적으로 무겁고 복잡하며, 커널의 개입이 필수적이다.

반면, 스레드는 동일한 프로세스 내에서 생성되므로 기본적으로 힙 메모리와 전역 변수 등의 자원을 공유한다. 따라서 한 스레드가 변경한 데이터를 다른 스레드가 즉시 접근하여 읽거나 수정할 수 있다. 이는 통신이 매우 효율적이고 빠르게 이루어질 수 있음을 의미한다.

그러나 자원의 공유는 동기화 문제를 필연적으로 동반한다. 여러 스레드가 공유 자원에 동시에 접근하여 값을 변경하려고 할 때, 실행 순서에 따라 예상치 못한 결과가 발생할 수 있다. 이를 경쟁 조건이라고 한다. 따라서 스레드 프로그래밍에서는 뮤텍스, 세마포어, 모니터 등의 동기화 기법을 사용하여 임계 구역에 대한 접근을 통제해야 한다.

정리하면, 프로세스 간 통신은 명시적인 IPC 기법을 필요로 하는 반면, 스레드 간 통신은 암묵적인 메모리 공유를 통해 이루어진다. 스레드의 효율적인 통신은 강력한 동기화 메커니즘의 사용을 전제로 한다.

멀티프로세싱은 두 개 이상의 프로세스가 동시에 실행되는 것을 의미하며, 이는 단일 프로세서에서의 시분할 방식이나 여러 개의 프로세서를 활용하는 방식으로 구현된다. 핵심은 각 프로세스가 독립된 메모리 공간과 자원을 할당받아 실행된다는 점이다. 운영체제의 스케줄러는 CPU 시간을 여러 프로세스 사이에 할당하여, 사용자에게는 동시에 실행되는 것처럼 보이게 한다.

멀티프로세싱의 동작은 크게 대칭형 멀티프로세싱과 비대칭형 멀티프로세싱으로 구분된다. 대칭형 멀티프로세싱에서는 모든 프로세서가 동등한 지위를 가지며, 하나의 공유 메모리를 통해 작업을 조율한다. 반면, 비대칭형 멀티프로세싱에서는 하나의 마스터 프로세서가 작업을 분배하고 나머지 프로세서는 할당된 작업만을 수행하는 계층적 구조를 가진다.

이러한 방식으로 동작하는 멀티프로세싱은 하나의 프로세스에 장애가 발생하더라도 다른 프로세스에는 영향을 주지 않아 시스템의 안정성을 높인다. 그러나 각 프로세스가 독립된 메모리 공간을 사용하기 때문에 프로세스 간 통신이 필요하며, 이로 인해 문맥 교환 비용과 통신 오버헤드가 발생하는 단점도 존재한다.

멀티스레딩은 하나의 프로세스 내에서 여러 개의 스레드를 생성하여 동시에 실행하는 기법이다. 이는 하나의 응용 프로그램이 동시에 여러 작업을 수행할 수 있게 한다. 멀티스레딩을 구현하는 시스템에서는 CPU가 매우 짧은 시간 간격으로 각 스레드를 번갈아 가며 실행하는 시분할 방식을 사용한다. 이로 인해 사용자에게는 여러 스레드가 동시에 실행되는 것처럼 보인다.

멀티스레딩 환경에서 스레드들은 프로세스가 할당받은 자원을 공유한다. 이는 코드 영역, 데이터 영역, 힙 영역 등의 메모리 자원과 열린 파일, 신호 처리기 등을 포함한다. 각 스레드는 독립적인 실행 흐름을 유지하기 위해 자신만의 스택, 프로그램 카운터, 레지스터 상태를 가진다. 운영체제의 스케줄러는 실행 가능한 스레드들 중 하나를 선택하여 CPU에 할당한다.

멀티스레딩의 동작은 사용되는 스레드 모델에 따라 달라진다. 사용자 스레드 모델에서는 스레드 생성, 관리, 스케줄링이 모두 사용자 수준의 스레드 라이브러리에 의해 이루어진다. 반면 커널 스레드 모델에서는 이러한 작업이 운영체제 커널에 의해 직접 처리된다. 하이브리드 스레드 모델은 두 방식을 혼합하여 사용한다.

멀티스레딩의 주요 이점은 다음과 같다.

그러나 스레드들이 자원을 공유하기 때문에 동기화 문제가 발생할 수 있다. 임계 구역 문제를 해결하기 위해 뮤텍스, 세마포어, 모니터 등의 동기화 기법이 필수적으로 사용된다. 동기화를 잘못 관리하면 교착 상태나 경쟁 상태가 발생하여 프로그램이 오작동할 수 있다.

멀티프로세싱은 각 프로세스가 독립된 메모리 공간을 가지므로, 한 프로세스의 오류나 비정상 종료가 다른 프로세스에 직접적인 영향을 미치지 않는다는 장점이 있다. 이는 높은 안정성과 격리성이 요구되는 서버 환경, 특히 웹 브라우저의 탭이나 마이크로서비스 아키텍처에서 유리하게 작용한다. 반면, 프로세스 간 전환(문맥 교환) 비용이 크고, 프로세스 간 통신이 상대적으로 복잡하며 오버헤드가 발생할 수 있다.

멀티스레딩은 하나의 프로세스 내에서 여러 스레드가 메모리와 자원을 공유하므로, 데이터 공유와 통신이 효율적이고 빠르다. 이는 사용자 인터페이스 응답성 유지와 같은 작업에 적합하며, 대규모 계산 작업을 병렬로 처리하는 과학기술계산이나 동시 다중 연결을 처리하는 웹 서버에서 흔히 사용된다. 그러나 한 스레드의 오류가 전체 프로세스를 중단시킬 수 있으며, 공유 자원에 대한 접근을 관리하기 위한 복잡한 동기화 기법이 필수적이다.

아래 표는 두 방식의 주요 적용 사례를 비교하여 보여준다.

현대 시스템은 두 방식을 혼합하여 사용하는 경우가 많다. 예를 들어, 하나의 응용 프로그램이 여러 프로세스로 구성되어 있고, 각 프로세스 내부에서 다시 멀티스레딩을 활용하는 멀티코어 환경이 대표적이다.

프로세스는 일반적으로 독립된 메모리 공간을 할당받아 실행된다. 이는 한 프로세스가 다른 프로세스의 메모리 영역을 직접 접근할 수 없음을 의미하며, 이로 인해 프로세스 간에 데이터를 교환하거나 작업을 조율하기 위해서는 특별한 통신 메커니즘이 필요하다. 이러한 메커니즘을 프로세스 간 통신(IPC)이라고 부른다.

IPC의 필요성은 크게 세 가지 측면에서 설명할 수 있다. 첫째, 정보 공유이다. 여러 사용자가 동일한 정보에 동시에 접근해야 할 필요가 있을 수 있다. 예를 들어, 공유 메모리를 통해 여러 프로세스가 대용량 데이터를 효율적으로 공유할 수 있다. 둘째, 계산 가속화이다. 하나의 작업을 여러 서브태스크로 나누어 각각 다른 프로세스가 병렬로 실행하게 함으로써 전체 실행 시간을 단축할 수 있다. 이때 서브태스크 간의 중간 결과를 주고받아야 한다. 셋째, 모듈성이다. 시스템을 독립적인 모듈(프로세스)로 설계할 경우, 모듈 간의 통신과 협력이 필요해진다. 이는 클라이언트-서버 모델과 같은 소프트웨어 구조에서 두드러지게 나타난다.

또한, IPC는 보안과 안정성 측면에서도 중요한 의미를 가진다. 프로세스의 메모리 공간이 분리되어 있기 때문에, 한 프로세스의 오류나 악의적인 동작이 다른 프로세스로 직접 전파되는 것을 방지할 수 있다. 통신은 운영체제가 제공하는 제어된 채널을 통해서만 이루어지므로, 시스템의 전체적인 견고함을 유지하는 데 기여한다. 따라서 IPC는 협력적이면서도 안전한 다중 프로세스 환경을 구축하기 위한 필수적인 기반이 된다.

IPC를 구현하는 기법은 크게 공유 메모리 방식과 메시지 전달 방식으로 나눌 수 있다. 공유 메모리 방식은 프로세스들이 특정 메모리 영역을 공유하여 데이터를 직접 읽고 쓰는 방식이다. 이 방식은 통신 속도가 매우 빠르지만, 공유 메모리 영역에 대한 접근을 개발자가 직접 동기화해야 한다는 복잡성이 따른다. 반면, 메시지 전달 방식은 프로세스들이 운영체제가 제공하는 시스템 호출을 통해 메시지를 주고받는다. 이 방식은 커널이 통신의 동기화를 관리하므로 구현이 비교적 간단하지만, 데이터 복사에 따른 오버헤드가 존재한다.

주요 IPC 기법은 다음과 같이 구체화된다.

이러한 기법들은 운영체제와 프로그래밍 환경에 따라 지원 수준과 API가 다르다. 예를 들어, 유닉스 계열 시스템에서는 파이프와 시그널이 역사적으로 널리 사용되었으며, 윈도우에서는 명명된 파이프와 메일슬롯이 유사한 역할을 한다. 응용 프로그램은 통신해야 하는 데이터의 양, 성능 요구사항, 프로세스 간의 관계 등을 고려하여 적절한 IPC 기법을 선택한다.

IPC는 다양한 방법으로 구현된다. 가장 일반적인 기법으로는 공유 메모리, 메시지 전달, 파이프, 소켓 등이 있다.

구체적인 예를 들면, 공유 메모리는 /dev/shm과 같은 메모리 파일 시스템을 활용하거나, shmget(), shmat() 같은 시스템 호출을 사용하여 구현된다. 반면, 메시지 큐는 msgget(), msgsnd(), msgrcv() 시스템 호출을 통해 메시지를 보내고 받는 방식으로 작동한다. 현대 운영체제는 대부분 이러한 기법들을 제공하며, 프로그래밍 언어의 라이브러리(예: Python의 multiprocessing 모듈, Java의 java.nio 채널)를 통해 더 추상화된 형태로 사용하기도 한다.

동기화는 둘 이상의 스레드가 공유 자원에 동시에 접근하거나, 실행 순서를 조정해야 할 때 발생하는 문제를 해결하기 위해 필요하다. 공유 메모리, 파일, 데이터베이스 연결과 같은 자원을 여러 스레드가 경쟁적으로 사용하면 경쟁 조건이 발생하여 데이터의 일관성이 깨질 수 있다. 예를 들어, 한 스레드가 데이터를 읽는 도중에 다른 스레드가 그 데이터를 변경하면, 첫 번째 스레드는 예상치 못한 또는 손상된 데이터를 얻게 된다. 따라서 이러한 비정상적인 실행 결과를 방지하고 프로그램의 정확성을 보장하기 위해 동기화 메커니즘이 필수적이다.

동기화가 필요한 주요 상황은 크게 두 가지로 나눌 수 있다. 첫째는 상호 배제로, 한 번에 하나의 스레드만이 임계 구역에 진입하여 공유 자원을 사용하도록 보장하는 것이다. 둘째는 실행 순서 제어로, 특정 스레드가 다른 스레드의 작업이 끝날 때까지 기다리도록 하여 작업 간의 의존성을 관리하는 것이다. 예를 들어, 생산자 스레드가 데이터를 버퍼에 넣기 전까지 소비자 스레드가 데이터를 가져가지 못하도록 하는 것이 이에 해당한다.

동기화 기법을 적용하지 않으면 발생할 수 있는 문제는 다음과 같다.

따라서 뮤텍스, 세마포어, 모니터와 같은 동기화 도구를 사용하여 스레드 간의 협력적이고 안전한 실행 환경을 조성하는 것이 중요하다. 올바른 동기화는 프로그램의 신뢰성과 성능을 결정하는 핵심 요소이다.

뮤텍스는 상호 배제를 보장하는 동기화 도구이다. 한 번에 하나의 스레드만이 공유 자원에 접근할 수 있도록 잠금을 제공한다. 뮤텍스를 소유한 스레드만이 해당 자원을 사용할 수 있으며, 사용이 끝나면 잠금을 해제하여 다른 스레드가 접근할 수 있게 한다. 이는 주로 임계 구역을 보호하는 데 사용된다.

세마포어는 에츠허르 데이크스트라가 제안한, 더 일반화된 동기화 메커니즘이다. 세마포어는 정수 값과 대기 큐를 가지며, P 연산(wait)과 V 연산(signal)을 통해 카운트를 조절한다. 이진 세마포어는 값이 0 또는 1로, 뮤텍스와 유사하게 동작한다. 계수 세마포어는 0 이상의 값을 가져, 제한된 수의 스레드가 동시에 자원에 접근하도록 제어하는 데 사용된다[4].

두 기법의 주요 차이는 소유권 개념에 있다. 뮤텍스는 잠금을 획득한 스레드가 반드시 잠금을 해제해야 하지만, 세마포어는 한 스레드가 P 연산을 하고 다른 스레드가 V 연산을 할 수 있다. 또한 세마포어는 시스템 범위에 존재할 수 있어 프로세스 간 통신에도 사용되지만, 뮤텍스는 일반적으로 같은 프로세스 내의 스레드 사이에서만 사용된다.

교착 상태는 둘 이상의 프로세스나 스레드가 서로 상대방이 점유하고 있는 자원을 기다리며, 더 이상 진행하지 못하고 영원히 멈춰 버리는 상태이다. 이는 동기화 기법을 사용하는 다중 프로그래밍 환경에서 발생할 수 있는 심각한 문제이다.

교착 상태가 발생하기 위해서는 네 가지 필요 조건이 동시에 성립해야 한다. 이 조건들은 다음과 같다.

교착 상태를 처리하는 주요 방법은 예방, 회피, 탐지 및 복구로 나뉜다. 예방은 위의 네 가지 필요 조건 중 하나 이상을 성립하지 않도록 보장하여 교착 상태가 발생할 가능성을 근본적으로 차단한다. 회피는 은행원 알고리즘과 같이 자원 할당 상태를 사전에 분석하여 안전한 상태에서만 자원을 할당하는 방식이다. 탐지 및 복구는 주기적으로 시스템 상태를 검사하여 교착 상태가 발생했는지 확인하고, 발생한 경우 하나 이상의 프로세스를 강제 종료하거나 자원을 선점하여 상태를 해결한다. 각 방법은 성능 오버헤드와 자원 활용도 간의 트레이드오프 관계에 있다[5].

스케줄링의 주요 목적은 프로세스나 스레드와 같은 실행 단위들에게 CPU를 효율적으로 할당하여 시스템의 전반적인 성능을 최적화하는 것이다. 이는 단일 사용자 시스템에서는 응답 시간을 줄이는 데 초점이 맞춰지지만, 다중 사용자나 다중 작업 환경에서는 공정성과 처리량 극대화가 더욱 중요해진다.

구체적인 목표는 다음과 같이 나열할 수 있다.

이러한 목표들은 서로 상충되는 경우가 많아, 운영체제는 시스템의 종류(일괄 처리, 대화형, 실시간 시스템 등)와 작업 부하에 따라 적절한 스케줄링 알고리즘을 선택하여 균형을 잡는다. 예를 들어, 실시간 시스템은 데드라인을 맞추는 것이 가장 중요하지만, 일반적인 시분할 시스템은 응답 시간과 공정성을 더 중시한다.

스케줄링 알고리즘은 운영체제가 프로세스나 스레드에 CPU 자원을 할당하는 순서를 결정하는 규칙이다. 알고리즘은 시스템의 목표(처리량 극대화, 응답 시간 최소화 등)에 따라 다양하게 설계된다.

주요 알고리즘은 다음과 같이 분류할 수 있다.

실제 운영체제는 이러한 기본 알고리즘들을 변형하거나 조합하여 사용한다. 예를 들어, 현대의 대화형 운영체제는 라운드 로빈의 공정성과 우선순위 스케줄링의 효율성을 결합한 방식을 주로 채용한다. 알고리즘 선택은 시스템의 작업 부하와 성능 목표에 따라 결정된다.

스케줄링 알고리즘의 성능을 평가하는 기준은 크게 시스템 관점과 사용자 관점으로 나뉜다. 시스템 관점의 기준은 프로세서나 메모리 같은 시스템 자원의 효율적인 활용도를 측정하는 반면, 사용자 관점의 기준은 개별 프로세스가 시스템에서 받는 서비스의 질을 평가한다.

주요 평가 기준은 다음과 같다.

이러한 기준들은 서로 트레이드오프 관계에 있는 경우가 많다. 예를 들어, CPU 이용률과 처리량을 극대화하려면 문맥 교환을 최소화해야 하지만, 이는 응답 시간을 악화시킬 수 있다[6]. 따라서 운영체제는 시스템의 목표(예: 실시간 시스템, 일괄 처리 시스템, 대화형 시스템)에 따라 적절한 스케줄링 정책을 선택한다.

주요 운영체제는 프로세스와 스레드를 관리하는 데 있어 고유한 접근 방식을 채택한다. 유닉스 및 리눅스 계열 시스템은 전통적으로 프로세스를 가볍게 생성하는 fork 시스템 호출을 사용하며, POSIX 스레드(pthreads) 라이브러리를 통해 스레드를 지원한다. 리눅스 커널은 스레드를 다른 프로세스와 마찬가지로 태스크 구조체(task_struct)로 표현하지만, 같은 프로세스 식별자(PID)를 공유하는 방식으로 구현한다[7].

마이크로소프트 윈도우는 프로세스와 스레드를 명확히 구분하는 객체 기반 모델을 사용한다. 윈도우 커널은 각 프로세스와 스레드를 실행체 객체(Executive Object)로 관리하며, 스레드 생성은 CreateThread API를 통해 이루어진다. 윈도우의 스레드는 기본적으로 해당 프로세스의 가상 주소 공간과 자원을 공유하지만, 윈도우 API는 프로세스 간 통신을 위한 다양한 메커니즘(파이프, 메일슬롯, 공유 메모리 등)을 제공한다.

macOS와 iOS의 기반인 다윈(Darwin) 커널은 마하 커널의 영향을 받아 태스크와 스레드를 분리한 모델을 사용한다. 여기서 태스크는 자원 컨테이너이며, 스레드는 실행 흐름의 단위이다. 애플의 그랜드 센트럴 디스패치(GCD) 기술은 이 시스템 위에서 동작하며, 스레드 풀을 효율적으로 관리하여 개발자가 저수준의 스레드 생성보다는 작업(task) 단위로 병렬 처리를 설계할 수 있게 한다.

이러한 구현 차이는 성능, 이식성, 프로그래밍 모델에 직접적인 영향을 미친다. 예를 들어, 리눅스의 fork()는 쓰기 시 복사(Copy-on-Write) 기법으로 효율적이지만, 윈도우의 프로세스 생성은 일반적으로 더 무겁다. 반면, 현대 운영체제들은 대부분 선점형 멀티태스킹과 멀티스레딩을 지원하며, 하이퍼스레딩이나 멀티코어 프로세서를 효율적으로 활용하기 위해 내부 스케줄러를 지속적으로 발전시키고 있다.

프로세스와 스레드를 생성하고 관리하는 방식은 프로그래밍 언어와 그 언어의 런타임 환경에 따라 크게 달라진다. 일부 언어는 운영체제의 네이티브 스레드를 직접적으로 지원하는 반면, 다른 언어는 가상 머신이나 런타임 라이브러리 수준에서 추상화된 경량 스레드 모델을 제공하기도 한다.

이러한 차이는 언어의 설계 철학과 주요 사용 영역에 기인한다. 시스템 프로그래밍 언어인 C/C++은 하드웨어에 가까운 저수준 제어를 제공하는 반면, Go나 최신 Java는 높은 수준의 동시성 추상화를 지향한다. Python의 GIL은 구현의 단순성과 안정성에서 비롯된 역사적 유산이다. 따라서 애플리케이션의 요구사항에 맞는 동시성 모델을 지원하는 언어를 선택하거나, 해당 언어의 패러다임 내에서 효과적인 병렬 처리 방식을 적용하는 것이 중요하다.