ECF(Exceptional Control Flow;예외적인 처리 흐름)이란?#

프로세서가 전원을 공급받아 작동을 시작하는 순간부터 종료될 때까지, 프로그램 카운터는 일련의 주소 값을 순차적으로 가리킵니다. 이러한 주소 값의 흐름, 즉 제어 흐름은 프로그램 내에서 명령어가 순차적으로 실행되는 기본적인 방식입니다. 점프, 호출, 반환과 같은 프로그래밍 명령어들은 프로그램 내부 상태 변화에 따라 제어 흐름을 변경하는 데 필수적인 메커니즘입니다. 이러한 명령어들은 프로그램 변수에 의해 표현되는 내부 프로그램 상태 변화에 반응하여 제어 흐름에 갑작스러운 변화를 일으킵니다.

그러나 실제 컴퓨터 시스템은 프로그램 내부 변수에 의해 포착되지 않거나 프로그램 실행과 직접적인 관련이 없는 시스템 상태 변화에도 대응할 수 있어야 합니다. 예를 들어, 하드웨어 타이머는 주기적으로 작동하며 처리되어야 하고, 네트워크 어댑터로 패킷이 도착하면 메모리에 저장되어야 합니다. 프로그램은 디스크에서 데이터를 요청한 후 데이터 준비 완료 알림을 받을 때까지 대기해야 하며, 자식 프로세스를 생성한 부모 프로세스는 자식 프로세스가 종료될 때 알림을 받아야 합니다. 현대 시스템은 이러한 상황에 대응하기 위해 제어 흐름에 갑작스러운 변화를 일으키며, 이러한 변화를 일반적으로 예외적인 제어 흐름(Exceptional Control Flow, ECF)이라고 합니다. ECF는 컴퓨터 시스템의 모든 수준에서 발생합니다.

응용 프로그램 수준에서 프로세스는 다른 프로세스에 시그널을 보내 수신자의 시그널 처리기로 제어를 갑자기 전달할 수 있습니다. ECF를 이해하는 것은 응용 프로그램이 운영 체제와 상호 작용하는 방식을 이해하는 데 도움이 됩니다. 응용 프로그램은 트랩 또는 시스템 호출이라는 형태의 ECF를 사용하여 운영 체제에 서비스를 요청합니다. 컴퓨터 시스템의 모든 수준에서 존재하는 다양한 형태의 ECF를 설명하며, 하드웨어와 운영 체제의 교차점에 있는 예외부터 시작하여 응용 프로그램에 운영 체제로의 진입점을 제공하는 예외인 시스템 호출까지 논의합니다.

예외 (Exceptions)#

예외는 프로세서 상태의 변화(이벤트)에 대한 응답으로 응용 프로그램에서 예외 처리기로 갑작스럽게 제어가 전달되는 것을 의미합니다. 처리기가 처리를 완료한 후에는 중단된 프로그램으로 제어를 반환하거나 프로그램을 중단시킵니다. 시스템에서 발생할 수 있는 각 예외 유형에는 고유한 음이 아닌 정수 예외 번호가 할당됩니다. 이러한 번호 중 일부는 프로세서 설계자가 할당하고, 다른 번호는 운영 체제 커널(운영 체제의 메모리 상주 부분) 설계자가 할당합니다. 런타임 시(시스템이 일부 프로그램을 실행 중일 때), 프로세서는 이벤트가 발생했음을 감지하고 해당 예외 번호 k를 결정합니다.

예외는 명령어 실행의 직접적인 결과인 동기적 예외와 현재 명령어 실행과 관련이 없는 비동기적 예외로 나눌 수 있습니다. 동기적 예외의 예로는 0으로 나누기, 유효하지 않은 메모리 접근, 산술 오버플로, 정의되지 않은 명령어, 시스템 호출 등이 있습니다. 비동기적 예외(인터럽트)의 예로는 하드웨어 타이머 만료, 네트워크 패킷 도착, 디스크 I/O 완료, 키보드 입력 등이 있습니다.

프로세스 (Processes)#

프로세스는 실행 중인 프로그램의 인스턴스입니다. 각 프로세스는 고유한 주소 공간(가상 메모리), 코드, 데이터, 스택 및 힙을 가진 활성 엔티티이며, 운영 체제에 의해 관리됩니다.

프로세스는 생성, 준비, 실행, 대기, 종료의 생명 주기를 거칩니다. 새로운 프로세스는 생성되어 보조 기억 장치에 로드된 후, 준비 상태로 전환되어 주 메모리에 로드되고 CPU 할당을 기다립니다. 실행 상태에서 프로세스는 CPU에 의해 현재 실행 중입니다. 단일 CPU 코어에서는 한 번에 하나의 프로세스만 실행 상태에 있을 수 있습니다. 대기/차단 상태에서 프로세스는 I/O 완료 또는 리소스 가용성과 같은 이벤트가 발생하기를 기다립니다. 프로세스 실행이 완료되면 종료 상태로 전환됩니다. 메모리가 부족할 때 프로세스가 보조 기억 장치로 스왑 아웃되는 경우 일시 중단 준비 및 일시 중단 대기와 같은 선택적 상태가 일부 시스템에 포함될 수 있습니다.

운영 체제는 프로세스 제어 블록(Process Control Block, PCB)이라는 데이터 구조에 각 프로세스에 대한 정보를 유지합니다. PCB에는 프로세스 ID(PID), 현재 프로세스 상태, 다음에 실행할 명령어의 주소를 나타내는 프로그램 카운터(PC), CPU 레지스터 내용, 메모리 관리 정보(예: 페이지 테이블 베이스 주소), 회계 정보(예: 사용된 CPU 시간), I/O 상태 정보(예: 열린 파일)와 같은 필수 정보가 포함되어 있습니다. PCB를 통해 OS는 스케줄링, 컨텍스트 스위칭 및 리소스 할당을 포함하여 프로세스를 관리하고 제어할 수 있습니다.

컨텍스트 스위칭은 실행 중인 한 프로세스의 컨텍스트(상태)를 저장하고 다른 프로세스의 컨텍스트를 복원하여 새 프로세스가 CPU에서 실행될 수 있도록 하는 프로세스입니다. 이는 멀티태스킹에 필수적이며, 여러 프로세스가 단일 CPU를 공유할 수 있도록 합니다. 컨텍스트 스위칭은 시간 공유 시스템에서 시간 할당량 만료, I/O 요청으로 인한 프로세스 차단 또는 리소스 대기, 인터럽트 처리(하드웨어 또는 소프트웨어), 우선순위가 높은 프로세스가 실행 준비 상태가 됨(선점), 시스템 호출(사용자 모드에서 커널 모드로 전환), 프로세스 종료 등의 원인으로 발생합니다. 컨텍스트 스위칭 단계에는 현재 프로세스의 상태를 PCB에 저장하고(CPU 레지스터, PC, 메모리 맵, 스택 포인터), 다음에 실행할 프로세스를 선택하고(스케줄링 알고리즘 사용), 새 프로세스의 저장된 상태를 PCB에서 복원하는 작업이 포함됩니다. 컨텍스트 스위칭은 CPU가 실제 응용 프로그램 코드를 실행하지 않고 상태를 저장하고 복원하는 작업을 수행하므로 오버헤드를 발생시킵니다. 잦은 컨텍스트 스위칭은 시스템 성능 저하로 이어질 수 있으며, 과도한 컨텍스트 스위칭은 시스템이 유용한 작업 실행보다 스위칭에 더 많은 시간을 소비하는 스래싱을 초래할 수 있습니다. 컨텍스트 스위치 시간은 하드웨어 지원(예: 여러 레지스터 세트)에 따라 크게 달라집니다.

시그널 (Signals)#

시그널은 실행 중인 프로그램에 특정 동작(종료 또는 오류 처리 등)을 유발하기 위해 전송되는 표준화된 메시지입니다. 이는 제한적인 형태의 프로세스 간 통신(Inter-Process Communication, IPC)입니다. 시그널은 특정 이벤트 또는 조건을 나타내기 위해 운영 체제, 다른 프로세스 또는 프로세스 자체에서 생성될 수 있는 비동기적 알림입니다. 시그널의 일반적인 용도는 프로세스 중단, 일시 중단, 종료 또는 강제 종료입니다.

각 시그널에는 번호(일반적으로 1에서 1 사이)와 기호 이름(예: SIGINT, SIGTERM, SIGSEGV)이 할당됩니다. 몇 가지 일반적인 시그널과 그 의미는 다음과 같습니다.

프로세스는 특정 시그널을 수신했을 때 실행할 시그널 처리기 함수를 등록할 수 있습니다. 시그널 처리기는 signal() 또는 sigaction() 시스템 호출을 사용하여 설치할 수 있습니다. sigaction()은 더 고급 제어를 위해 일반적으로 선호됩니다. 시그널이 전달되면 OS는 프로세스의 일반적인 실행을 중단하고 등록된 처리기를 호출합니다. 처리기가 등록되지 않은 경우 시그널의 기본 동작이 수행됩니다. 프로세스는 또한 SIG_IGN을 사용하여 시그널을 무시하거나 SIG_DFL을 사용하여 기본 동작으로 되돌릴 수 있습니다.

시그널 처리기를 구현할 때 몇 가지 중요한 고려 사항이 있습니다. 시그널 처리기는 언제든지 프로세스를 중단할 수 있으므로, 재진입 가능한 함수(함수 호출이 완료되기 전에 다시 호출되어도 안전한 함수)만 호출하여 경합 조건 및 정의되지 않은 동작을 피해야 합니다. 특정 함수 집합만 시그널 처리기 내에서 안전하게 호출할 수 있도록 보장됩니다(비동기 시그널 안전 함수). 이러한 함수는 일반적으로 간단하며 중단된 코드에서 수정 중일 수 있는 전역 상태에 의존하지 않습니다.printf() 및 malloc()과 같은 함수는 일반적으로 비동기 시그널 안전 함수가 아닙니다. 시그널 처리기 내에서 전역 변수에 대한 접근은 신중하게 관리해야 합니다. 처리기와 메인 프로그램 간에 공유되는 변수에는 volatile sig_atomic_t를 사용하여 원자성을 보장하고 컴파일러 최적화로 인한 문제를 방지하는 것이 좋습니다. 시그널 처리기가 실행되는 동안 해당 시그널을 트리거한 시그널은 일반적으로 재귀 호출을 방지하기 위해 차단됩니다. 적절한 처리를 위해 다른 시그널도 차단해야 할 수 있습니다.

각 프로세스에는 현재 전달이 차단된 시그널을 결정하는 시그널 마스크가 있습니다. 시그널은 생성될 수 있지만(프로세스에 전송됨) 현재 시그널 마스크에 의해 차단된 경우 보류 상태로 유지됩니다. 커널은 프로세스가 사용자 모드로 복귀하려고 할 때 보류 중인 시그널을 확인합니다. 차단되지 않은 보류 중인 시그널이 있으면 이 시점에서 전달됩니다. 사용자 모드 처리기가 있는 프로세스에 시그널이 전달되면 해당 유형의 시그널은 처리기가 실행되는 동안 자동으로 차단됩니다. 시스템 호출은 시그널에 의해 중단될 수 있습니다. 일부 시스템 호출은 시그널 처리기가 반환된 후 자동으로 다시 시작되는 반면(sigaction에서 SA_RESTART 플래그가 설정된 경우), 다른 시스템 호출은 오류(예: EINTR)를 반환합니다.

비지역 점프 (Non-local Jumps): setjmp와 longjmp#

비지역 점프는 일반적인 함수 호출 및 반환 메커니즘을 우회하여 두 개의 분리된 함수 간의 코드 실행 점프입니다. 이는 setjmp() 및 longjmp() 함수를 사용하여 수행됩니다.

비지역 점프의 일반적인 사용 사례는 다음과 같습니다.

• 깊이 중첩된 함수에서 전체 호출 스택을 언와인딩하지 않고 오류 처리 루틴으로 직접 점프하여 오류를 처리하는 경우.
• 이는 일반적인 오류 반환 값이 충분하지 않거나 전파하기 번거로운 상황에서 유용할 수 있습니다.
• C에는 기본 제공 예외 처리가 없으므로 C에서 try/catch와 유사한 구조를 만드는 경우.
• 단일 프로세스 내에서 다른 실행 컨텍스트 간을 전환하여 코루틴을 구현하는 경우(그러나 이는 종종 스택 조작을 위한 플랫폼별 트릭이 필요함).
• 시그널 처리기에서 프로그램 실행의 특정 지점으로 반환하는 경우.

setjmp(jmp_buf env) 함수는 현재 실행 컨텍스트(프로그램 카운터, 스택 포인터 및 레지스터 값 포함)를 env가 가리키는 jmp_buf 구조체에 저장합니다. setjmp()가 처음 호출되면 컨텍스트가 저장되었음을 나타내는 0을 반환합니다. jmp_buf는 저장된 상태를 보유하는 불투명 데이터 유형(일반적으로 배열 또는 구조체)입니다. 정의되지 않은 동작을 피하기 위해 setjmp()는 특정 컨텍스트(예: if 또는 while 문의 전체 제어 표현식 또는 독립 실행형 표현식)에서 호출해야 합니다.

longjmp(jmp_buf env, int val) 함수는 setjmp() 호출에 의해 이전에 env에 저장된 실행 컨텍스트를 복원합니다. 실행은 해당 setjmp() 호출이 val에 지정된 값으로 반환된 것처럼 재개됩니다.

setjmp()와 longjmp()를 사용할 때는 몇 가지 주의 사항과 잠재적인 문제점이 있습니다. setjmp() 호출과 longjmp() 호출 사이에 획득한 리소스(malloc으로 할당된 메모리, 열린 파일 등)는 C에 스택 언와인딩 중에 호출되는 소멸자 개념이 없기 때문에 자동으로 해제되지 않습니다. 따라서 수동 리소스 관리가 중요합니다. setjmp()를 호출한 함수에서 자동(지역, 비정적, 비외부) 변수의 값은 longjmp() 후 예상대로 보존되지 않을 수 있습니다. 값을 복원하려면 setjmp()와 longjmp() 호출 사이에 수정된 경우 이러한 변수를 volatile로 선언해야 합니다. setjmp()와 longjmp() 사이의 호출 스택에 가변 길이 배열(Variable Length Array, VLA)을 사용하면 메모리 누수 및 정의되지 않은 동작이 발생할 수 있습니다. 이러한 컨텍스트에서는 VLA를 피해야 합니다. 시그널 마스크에 대한 setjmp()와 longjmp()의 동작은 기본 표준에 엄격하게 정의되어 있지 않습니다.