운영체제

[etama123]

프로세스와 스레드

• 스레드마다 Stack 영역을 따로 두는 이유는? 힙은 그럼 왜 공유하나?
• Context Switching이란 무엇이며, 왜 오버헤드가 발생하나요?
• 프로세스의 메모리 구조를 설명하세요.
• 멀티 프로세스와 멀티 스레드의 차이와 장단점에 대해 설명해주세요.
• 문맥 교환이 비용이 큰 작업인 이유는? (CPU 캐시 관점)
• JVM은 멀티스레드인데, 그러면 하나의 스레드가 죽으면 전체 프로세스가 종료되는 걸까?

동기화와 교착 상태

• mutex, 세마포어, 모니터가 무엇이고 코틀린 코루틴에서는 mutex, 세마포어, 모니터를 제공하고 있나요?
• 코틀린의 mutableList는 스레드 세이프한가요?
• 교착상태는 어떤 상황에서 발생하나요?

CPU 스케줄링

• 우선순위 스케줄링에서 발생할 수 있는 주요 문제점과 그 해결책을 설명해 주세요.
• OS가 프로세스에 우선순위를 부여하는 기본적인 목적과 기준은 무엇인가요?
• 선점형(Preemptive) 스케줄링과 비선점형(Non-preemptive) 스케줄링의 차이점을 정의하고, 각각의 장단점을 비교 설명해 주세요.

가상 메모리

• CPU가 사용하는 논리 주소와 메모리의 물리 주소는 어떻게 다르며, 이 둘을 연결해주는 MMU는 어떤 역할을 하나요?
• 페이지 폴트가 발생하면 어떤 일이 일어나며, 메모리가 가득 찼을 때 운영체제는 어떤 방식으로 페이지를 교체하나요?

[etama123]

Context Switching이란 무엇이며, 왜 오버헤드가 발생하나요?

[HamBeomJoon]

• 프로세스에서 다른 프로세스로 교체할 때 기존 프로세스의 정보를 PCB에 저장하고 다른 프로세스로 교체하는 것

[etama123]

Context Switching은 CPU가 현재 실행 중인 프로세스의 상태를 저장하고, 다음 실행할 프로세스의 상태를 복원하는 과정입니다.
운영체제는 각 프로세스의 정보를 PCB(Process Control Block) 에 저장해두는데, 스위칭 시 이전 프로세스의 PCB를 백업하고 다음 프로세스의 PCB를 불러옵니다.

이 과정에서 레지스터 값, 프로그램 카운터, 메모리 정보 등을 교체해야 하고,
CPU 캐시나 파이프라인도 초기화되기 때문에 캐시 미스(cache miss)가 발생합니다.
또한 커널 영역에서 작업이 이루어져 모드 전환 비용도 발생합니다.

따라서 Context Switching은 필수적이지만, 너무 자주 발생하면 오버헤드가 커지고 시스템 성능이 저하될 수 있습니다.

[ijh1298]

프로세스가 실행된다 = 운영체제에 의해 CPU의 자원을 할당받았다.
프로세스의 CPU 사용 시간은 타이머 인터럽트에 의해 제한된다.

타이머 인터럽트 시 Context Switching 발생

프로세스 간에 너무 잦은 문맥 교환이 발생하면 캐시 미스가 발생할 가능성이 높아져 메모리로부터 실행할 프로세스의 내용을 가져오는 작업이 빈번해지고, 이는 큰 오버헤드로 이어질 수 있다.

[medAndro]

• 프로세스가 타이머 인터럽트로 인해 CPU점유가 끝날때, 중간 정보인 문맥을 PCB(프로세스 제어 블록, 메모리의 커널 영역)에 기록하고, 다시 점유될 떄 복구되며 메모리의 읽기 쓰기 작업으로 인해 오버헤드로 이어짐

[etama123]

프로세스의 메모리 구조를 설명하세요.

[HamBeomJoon]

코드, 데이터(정적 영역)
힙, 스택(동적 영역)

[ijh1298]

코드 - 실행 가능한 명령어 저장, 읽기 전용, CPU의 명령어만 있다.
데이터 - 프로그램이 실행되는 동안 유지, 정적 변수, 전역 변수
힙 - 가비지 컬렉션 사용하는 언어라면 메모리 누수 해제를 알아서
스택 - 매개 변수, 지역 변수, 함수 복귀 주소

[etama123]

프로세스는 메모리에서 커널 영역이랑 사용자 영역으로 나눌 수 있습니다.

커널 영역에는 프로세스를 제어하기 위한 정보가 저장됩니다. 대표적으로 PCB가 있는데, 여기에서는 프로세스 ID, 레지스터 값, 상태, CPU 스케줄링 정보, 파일 입출력 장치 관련 정보가 담겨있습니다.

사용자 영역은 실제 프로그램 코드와 데이터가 저장되는 공간입니다.

• 코드 영역(Code Segment): CPU가 실행할 명령어가 저장된 읽기 전용 공간입니다.

• 데이터 영역(Data Segment): 전역 변수나 정적 변수가 저장되어, 프로그램 종료 시까지 유지됩니다.

• 힙 영역(Heap Segment): 실행 중 동적으로 메모리를 할당하는 공간으로,

  사용자가 직접 관리해야 하며, 반환하지 않으면 메모리 누수가 발생할 수 있습니다.

• 스택 영역(Stack Segment): 함수 호출 시 생성되는 매개변수, 지역 변수, 복귀 주소 등이 저장되는 영역입니다. 함수 호출 시마다 쌓였다가(LIFO 구조) 함수가 끝나면 제거됩니다.

코드 영역과 데이터 영역은 정적 할당 영역이고, 힙 영역과 스택 영역은 동적 할당 영역입니다.

[medAndro]

정적 할당은 크기가 변하지 않고 읽기 전용으로 명령어나 정적, 전역 변수등 실행되는 동안 유지되는 데이터가 저장되고
동적 할당 영역은 GC을 통해 개발자가 할당 해지를 관리하는 힙 영역과 변수 등 일시적으로 사용할 값이 저장되는 스택 영역이 있습니다

[HamBeomJoon]

• 스레드마다 Stack 영역을 따로 두는 이유는?
• 힙은 그럼 왜 공유하나?

[HamBeomJoon]

[HamBeomJoon]

Stack 영역은 함수의 인자나 PC 값, 지역 변수가 저장이 된다. 즉, 해당 실행 컨텍스트에서 필요한 데이터를 저장한다. 그렇기 때문에 thread 간에는 stack 영역을 독립적으로 두어야, 서로의 실행 컨텍스트를 안정적으로 관리할 수 있다. stack 영역이 독립적이기 때문에, 각 thread는 독립적으로 함수를 호출할 수 있다.

[etama123]

서로의 실행 컨텍스트를 독립적으로 관리할 수 있다.

[HamBeomJoon]

힙은 그럼 왜 공유하나?

• 객체와 데이터를 효율적으로 공유하고 관리하기 위해서
• Heap에는 객체, 인스턴스 변수가 저장된다. 객체를 스레드마다 독립적으로 사용하기 위해 복사한다면 메모리 낭비가 심각해질 것이다.
• 지역 변수는 공유할 필요가 없는 임시 값이고 복사 비용도 거의 없다. 또한, 각 스레드의 독립적인 실행을 위해 격리되는 것이 좋기 때문에 스택 영역은 스레드마다 따로 둔다.

[medAndro]

• 인터럽트가 발생했다가 복구되는 등의 작업시 스레드별로 기록을 해두어야 PC값이 스레드별로 관리가 되어 스레드끼리 서로 꼬이지 않고 순서를 유지하기 떄문에 스레드별로 관리되지만, 힙 영역은 단순히 메모리를 할당하고 반환만 하면 되므로 공유하여 사용하여 효율적으로 사용함

[HamBeomJoon]

• 문맥 교환이 비용이 큰 작업인 이유는? (CPU 캐시 관점)

[HamBeomJoon]

CPU는 실행 중인 프로세스(또는 스레드)의 코드, 데이터, 스택을 L1/L2/L3 캐시에 저장해 두고 빠르게 접근합니다.

• 그러나 문맥 교환이 발생하면 이전 프로세스의 데이터는 캐시에 그대로 남아 있지만 새로운 프로세스에는 거의 쓸모 없는 데이터입니다. 새 프로세스가 필요로 하는 데이터는 아직 캐시에 없음(Miss) → 메모리에서 다시 가져와야 함.
• 즉, 문맥을 바꾸는 순간 캐시 히트율이 급격히 떨어지고 캐시 미스 비용이 증가합니다.

[medAndro]

• 캐시미스로 인해 메모리의 읽기 쓰기 작업이 발생하면 캐시에 접근하는 속도보다 메모리에 접근하는 속도가 느리기 때문에

[etama123]

멀티 프로세스와 멀티 스레드의 차이와 장단점에 대해 설명해주세요.

[ijh1298]

멀티프로세스 - 하나의 프로세스에 문제가 생겨도 다른 프로세스에는 영향이 없다. 크롬 같은 브라우저가 하나하나가 멀티프로세스다.
멀티스레드 - 하나의 프로세스에 여러 스레드가 존재, 힙 영역을 공유하기 때문에 스레드간 통신이 비교적 쉽다.

[etama123]

멀티 프로세스는 하나의 프로그램을 여러 프로세스로 나누어 병렬로 실행하는 방식입니다.
각 프로세스는 독립적인 메모리 공간을 가지기 때문에, 한 프로세스가 문제가 생겨도 다른 프로세스에는 영향이 거의 없습니다.
하지만 프로세스 간 자원이 공유되지 않기 때문에 Context Switching 비용이 크고, 데이터를 주고받기 위해 IPC(프로세스 간 통신) 이 필요하다는 단점이 있습니다.

반면, 멀티 스레드는 하나의 프로세스 내에서 여러 실행 흐름(스레드) 을 동시에 수행하는 방식입니다.
스레드는 코드, 데이터, 힙 영역을 공유하고 스택만 독립적으로 가지기 때문에, 자원 접근이 빠르고 통신 비용이 적습니다.
하지만 공유 자원을 동시에 접근할 때 레이스 컨디션이나 교착상태 같은 문제가 발생할 수 있고,
한 스레드에 오류가 발생하면 프로세스 전체가 종료될 위험이 있습니다.

정리하면,

• 멀티 프로세스는 안정성은 높지만 오버헤드가 크고,
• 멀티 스레드는 효율성과 속도는 높지만 안정성이 낮습니다.
  → 즉, 시스템 목적에 따라 둘 중 적절한 방식을 선택해야 합니다.

[medAndro]

멀티 프로세스는 메모리를 독립적으로 사용해 하나에 문제가 발생해도 다른 프로세스에 영향을 주지 않지만 서로간의 통신을 위해 프로세스간 통신을 사용하여 통신 비용이 크다
멀티 스레드는 하나의 스레드가 문제가 발생하면 전체 프로세스에 영향을 미치지만 힙 영역을 서로 공유하기 때문에, 통신 비용이 낮다

[HamBeomJoon]

JVM은 멀티스레드인데, 그러면 하나의 스레드가 죽으면 전체 프로세스가 종료되는 걸까?

[HamBeomJoon]

• 스레드 = 프로세스 안의 실행 흐름 하나
• 스레드 하나가 종료(예외 포함)되어도 프로세스는 계속 살아있음
• 단, UI thread나 GC thread처럼 critical thread가 죽으면 전체가 죽는 것뿐

[ijh1298]

JVM
기본 스레드
데몬 스레드 - 죽어도 큰 상관 없는 스레드

[medAndro]

JVM에서 예외가 발생하면 그 스레드만 종료되도록 스레드독립성을 가지도록 개발되었을 것이고, 공유 자원을 사용하다가 문제가 생기면 예상치 못한 동작이나 데드락이 발생할 수 있을 것 같다.

[etama123]

JVM은 하나의 프로세스 안에서 여러 스레드가 동작하는 멀티스레드 환경이며, 각 자바 스레드는 운영체제의 네이티브 스레드와 1:1로 매핑됩니다.

따라서 한 스레드가 예외나 오류로 종료되더라도 다른 스레드들은 계속 실행되며, JVM 전체가 종료되지는 않는다. 다만 모든 non-daemon 스레드가 종료되면 JVM은 자동으로 프로세스를 종료하고, 반대로 daemon 스레드만 남아 있을 경우에도 JVM은 종료된다.

즉, JVM 종료 여부는 개별 스레드의 생사보다 non-daemon 스레드가 존재하는가 에 의해 결정된다.

[medAndro]

mutex, 세마포어, 모니터가 무엇이고
코틀린 코루틴에서는 mutex, 세마포어, 모니터를 제공하고 있나요?

[ijh1298]

• 뮤텍스 락
  • 프로세스 및 스레드가 공유하는 변수(lock)와 2개의 함수(acquire, release)로 구현
  • acquire 락을 획득하기 위한 함수
  • release 획득한 락을 해제하기 위한 함수
• 세마포어
  • 여러 개의 프로세스나 스레드에서 공유 자원을 접근할 때
  • wait , signal 함수
  • 사용 가능한 공유 자원의 개수 S
  • signal 은 S를 증가, wait 은 감소시킴
• 조건 변수와 모니터
  • 조건 변수란 실행 순서 제어를 위한 동기화 도구, 특정 조건 하에 프로세스를 실행/일시 중단함으로써 프세스나 스레드의 실행 순서를 제어할 수 있다.
  • wait 함수는 호출한 프로세스 및 스레드의 상태를 대기 상태로 전환하는 함수
  • signal 함수는 wait로 일시 중지된 프로세스 및 스레드의 실행을 재개하는 함수

[HamBeomJoon]

코루틴에서 제공?한다기 보다 그냥 java.util.semaphore 같이 갖다 쓰면되는 것 같아요

• Kotlin 코루틴 환경에 적합한 Mutex 사용 권장

[medAndro]

mutex는 락을 걸어 동시 접근을 막는거고, 세마포어는 뮤택스와 비슷하지만 동시 접근수를 제한한 것이며 모니터는 공유자원에 단 하나의 프로세스나 스레드를 접근하도록 큐 방식으로 처리해 준다.
코루틴에서는 뮤택스 세마포어를 자체적으로 제공하고 있지만 모니터는 직접 구현해야 한다.

[medAndro]

코틀린의 mutableList는 스레드 세이프한가요?

[HamBeomJoon]

Kotlin의 MutableList(예: mutableListOf(), ArrayList)는 스레드 세이프(thread-safe) 하지 않습니다.
즉, 여러 스레드가 동시에 같은 MutableList 인스턴스에 접근해서 읽기와 쓰기 작업(추가, 삭제 등) 을 수행하면 경쟁 상태(race condition) 가 발생할 수 있습니다.

[medAndro]

자바의 vector는 스레드 세이프하지만 코틀린의 MutableList는 내부적으로 array List를 사용하기 때문에 스레드 세이프하지 않다.

[medAndro]

교착상태는 어떤 상황에서 발생하나요?

[HamBeomJoon]

• 교착 상태가 발생하는 상황에는 4가지 필요 조건이 있다. 이 중 하나라도 만족하지 않는다면 교착 상태는 발생하지 않고, 4개의 조건이 모두 만족할 때 교착 상태가 발생할 가능성이 생긴다.

1. 상호 배제
   • 한 프로세스가 사용하는 자원을 다른 프로세스가 사용할 수 없는 상호 배제의 상황에서 교착 상태가 발생할 가능성이 생긴다.
2. 점유와 대기
   • 한 프로세스가 어떤 자원을 할당받은 상태(점유)에서 다른 자원 할당받기를 기다린다면(대기) 교착 상태가 발생할 수 있다.
3. 비선점
   • 자원이 비선점되었다는 말은 해당 자원을 이용하는 프로세스의 작업이 끝나야만 비로소 자원을 이용할 수 있다는 것을 의미한다. 즉, 어떤 프로세스도 다른 프로세스의 자원을 강제로 빼앗지 못하는 경우
4. 원형 대기
   • 프로세스와 프로세스가 요청한 자원이 원의 형태를 이루는 경우

[ijh1298]

• CPU가 사용하는 논리 주소와 메모리의 물리 주소는 어떻게 다르며, 이 둘을 연결해주는 MMU는 어떤 역할을 하나요?

[ijh1298]

• CPU와 프로세스는 메모리의 하드웨어 상 실제 주소인 물리 주소(physical address)가 아니라 논리 주소(logical address)를 사용한다. 논리 주소는 프로세스마다 부여되는 0번지부터 시작하는 주소 체계.
• MMU(Memory Manage Unit)는 CPU와 메모리 사이에 위치하며, CPU가 이해하는 논리 주소를 메모리가 이해하는 물리 주소로 변환하는 역할

[medAndro]

프로세스마다 0번부터 각각 논리적으로만 존재하는 주소이고 물리 주소는 메모리에서 저장되는 실제 주소이며 CPU가 MMU에게 논리 주소를 요청하면 MMU는 물리 주소로 변환해준다.

[ijh1298]

• 페이지 폴트가 발생하면 어떤 일이 일어나며, 메모리가 가득 찼을 때 운영체제는 어떤 방식으로 페이지를 교체하나요?

[ijh1298]

요구 페이징(demand paging)

1. CPU가 특정 페이지에 접근하는 명령어를 실행한다.
2. 해당 페이지가 현재 메모리에 있을 경우(유효 비트가 1일 경우) CPU는 페이지가 적재된 프레임에 접근한다.
3. 해당 페이지가 현재 메모리에 없을 경우(유효 비트가 0일 경우) 페이지 폴트가 발생한다.
4. 페이지 폴트가 발생하면 페이지 폴트 처리 루틴을 통해 해당 페이지를 메모리로 적재하고, 유효 비트를 1로 설정한다.
5. 다시 1의 과정을 수행한다.

순수 요구 페이징: 아무런 페이지도 메모리에 적재하지 않은 채 프로세스 실행

메모리에 페이지가 가득 찬 상황에서 추가적으로 페이지를 적재해야 한다면 메모리에 적재된 일부 페이지를 스왑 아웃해야 한다. 좋은 페이지 교체 알고리즘은 메모리에서 사용되지 않을 페이지를 적절하게 보조기억장치로 내보내기 때문에 페이지 폴트의 발생 빈도가 적다. 페이지 폴트의 발생은 보조기억장치로부터 필요한 페이지를 가져와야 하는 시간만큼 성능 저하가 발생한다.

• FIFO(First In First Out) 페이지 교체 알고리즘
• 최적 페이지 교체 알고리즘 - 가장 적게 사용할 페이지 교체, 실제 구현이 어려움
• LRU(Least Recently Used) 페이지 교체 알고리즘 - 가장 적게 사용한 페이지 교체

페이지 폴트의 종류

• 메이저 페이지 폴트
  • 보조기억장치에서 CPU가 원하는 페이지를 읽어 들이기 위해 입출력 작업이 필요한 페이지 폴트
  • CPU가 접근하려는 페이지가 물리 메모리에 없을 때 발생
• 마이너 페이지 폴트
  • 보조기억장치와의 입출력이 필요하지 않은 페이지 폴트
  • CPU가 요청한 페이지가 메모리에는 존재, 페이지 테이블에 반영되지 않은 경우

[HamBeomJoon]

페이지 교체

1. FIFO 페이지 교체 알고리즘

메모리에 가장 먼저 적재된 페이지부터 스왑 아웃하는 알고리즘. 초기에 적재되어 줄곧 참고되고 있는 페이지를 스왑 아웃할 우려가 있다. (페이지 폴트 발생 가능성)

2. 최적 페이지 교체 알고리즘

앞으로의 사용 빈도가 가장 낮은 페이지를 교체하는 알고리즘. ‘앞으로 가장 적게 사용할 페이지’를 미리 예측하기가 어렵기 때문에 실제 구현이 어려움

3. LRU 페이지 교체 알고리즘 (Least Recently Used)

가장 적게 ‘사용한’ 페이지를 교체하는 알고리즘. 보편적으로 사용됨.

[HamBeomJoon]

우선순위 스케줄링에서 발생할 수 있는 주요 문제점과 그 해결책을 설명해 주세요.

[HamBeomJoon]

문제점: 아사(Starvation) 현상 (우선순위가 낮은 프로세스가 영원히 CPU를 할당받지 못하고 실행이 연기되는 현상)
해결책: 에이징(Aging) 기법 (오랫동안 대기한 프로세스의 우선순위를 점차 높여서 아사 현상을 방지)

[medAndro]

문제점: 아사 발생
해결잭: 에이징(낮은 우선순위가 기대릴때마다 우선순위 증가)

[HamBeomJoon]

OS가 프로세스에 우선순위를 부여하는 기본적인 목적과 기준은 무엇인가요?

[HamBeomJoon]

핵심: 높은 CPU 활용률 유지

우선순위 부여 기준: 기본적으로 입출력(I/O) 작업이 많은 프로세스의 우선순위를 높게 유지하여, I/O 작업으로 인해 CPU가 유휴 상태에 빠지는 것을 방지하고 CPU 자원을 효율적으로 사용합니다

[HamBeomJoon]

선점형(Preemptive) 스케줄링과 비선점형(Non-preemptive) 스케줄링의 차이점을 정의하고, 각각의 장단점을 비교 설명해 주세요.

[HamBeomJoon]

• 차이점: CPU 자원을 강제로 빼앗을 수 있는지 여부

선점형:

장점: CPU 독점 방지, 공평한 자원 배분, 실시간 시스템에 적합.

단점: Context Switching 횟수가 많아져 오버헤드 발생 가능.

비선점형:

장점: Context Switching 횟수가 적어 오버헤드 발생이 상대적으로 적음.

단점: CPU 독점 가능성 (호위 효과), 긴급한 프로세스가 무작정 대기해야 함.