마음대로 개발 LIFE

<< EC2 HTTPS로 연결하기 >>

1편) 도메인 구매하고 ACM 인증서 발급하기 <-- 현재 글

(도메인 구매 --> 도메인 인증 --> ACM 인증서 발급 --> Target Group 생성 --> Load Balancer 생성 --> 규칙 수정 --> Health check 성공)

2편) 로드 밸런서 사용하고 Health check 통과하기 (링크)

(도메인 구매 --> 도메인 인증 --> ACM 인증서 발급 --> Target Group 생성 --> Load Balancer 생성 --> 규칙 수정 --> Health check 성공)

개요

HTTPS는 SSL이라는 보안 프로토콜 위에서 HTTP 통신을 하는 프로토콜을 뜻합니다. (요즘은 발전된 버전인 TLS 사용)

요즘은 http로 된 주소를 찾아보기 힘들고, 서비스 중인 대부분의 웹사이트는 https 주소를 사용합니다.

https는 구글 검색 엔진에 가산점이 있다.

http는 브라우저에서 보안 위험 표시가 나온다.

클라이언트 서버 배포 시 자주 사용하는 Vercel에서 http 주소를 지원하지 않는다. (프론트는 잘 몰라서 정확한 건 아닙니다)

등 여러가지 이슈가 있습니다.

서버 개발자 입장에서, 그냥 https 사용을 염두에 두는 것이 마음이 편할 지경입니다.

하지만 처음 https 주소를 사용하고자 한다면, 과정이 꽤 길고 복잡합니다.

(물론 이것도 과거에 하나하나 코딩으로 리다이렉트를 하던 것보다는 훨씬 편해진 것이라고 합니다.)

그래서 누구나 쉽게 따라하실 수 있도록

https 주소 사용을 위한 과정을 A to Z로 기록해보고자 합니다.

자세하게 적느라 내용이 길지만, 그만큼 쉽게 따라하실 수 있을테니

절대 포기하지 마시고 끝까지 함께하시길 바랍니다!

사전 필요사항

- EC2 인스턴스 개설

- 실행 가능한 웹 서버

EC2 인스턴스가 개설되고, 그 위에서 웹 서버를 구동할 수 있는 상태를 가정하고 작성하겠습니다.

도메인 구매

특정 IP에 부여된 naver.com, google.com 과 같은 주소들을 도메인이라고 합니다.

https 연결을 위해서는, 도메인을 소유하고 있어야 합니다.

도메인 구매는 AWS에서도 가능하고, '무료 도메인'이라고 검색하면 나오는 방법으로도 가능합니다.

저는 적당히 원하는 도메인을 구매하면서도, 가격이 AWS보다는 저렴한

'가비아'라는 사이트에서 도메인을 구매했습니다. 그 기준으로 내용을 작성해보겠습니다.

위 사이트에 접속합니다.

사용을 원하는 도메인 명을 검색합니다.

woojin 으로 검색했더니 도메인 별 가격이 나옵니다. (가격은 1년 기준입니다.)

EVENT 가격은 최초 1년만 적용되는 가격임에 주의합니다.

연장할 경우 오른쪽의 높은(호구)가격으로 결제됩니다만,

1년이 지나고 연장하지 않으면 자동으로 삭제되니 걱정은 안 하셔도 됩니다. (가비아에 직접 문의해보았습니다.)

원하는 도메인을 선택하여 구매합니다. (shop은 쓰지 말라는 말을 어디서 봤는데.. 정확하지는 않습니다.)

등록 기간을 1년으로 설정하고 (Event 가격 적용을 위해)

나머지 필수 정보를 입력합니다.

네임서버는 타사(AWS) 것을 사용할 예정이지만,

나중에 수정할 것이므로 일단 가비아 네임서버를 사용하고 넘어갑니다.

결제를 마치면, My가비아>이용 중인 서비스>도메인 메뉴에서 나의 도메인을 확인할 수 있습니다.

본 포스팅에서 사용할 도메인을 domain.com이라고 가정하겠습니다.

(실제 사용하고 있는 도메인은 아닙니다.)

'관리' 버튼을 클릭하면,

위와 같은 정보를 확인할 수 있습니다.

도메인 구매를 마쳤으니, 인증서를 발급받아 보겠습니다.

Route 53에서 도메인 인증

인증서 발급에 앞서, 내가 도메인을 소유하고 있다고 인증을 해야 합니다.

먼저 AWS 계정에 로그인 하여 Route 53 서비스에 대시보드로 이동합니다.

호스팅 영역을 생성합니다.

도메인 이름은 위에서 구매한 도메인으로 작성합니다.

나머지는 default를 유지하고 도메인을 생성합니다.

다시 호스팅 영역 탭에서 방금 생성한 호스팅 영역을 클릭하면 위와 같은 화면을 확인할 수 있습니다.

현재 레코드는 NS(네임서버), SOA 유형 각 1개로, 총 2개 존재합니다.

그 중 NS 유형에는 라우팅 대상이 4개 존재합니다.

나중에는 위와 같이 A, NS, SOA, CNAME 4개의 레코드가 존재해야 합니다.

현재는 A, CNAME이 없는데, A는 다음 포스팅에서 만들 것이니 기억만 해주세요.

CNAME은 바로 아래에서, 인증서 발급 후 만들 예정입니다.

이번에는 내가 구입한 가비아의 도메인의 네임서버를,

방금 생성한 도메인 영역의 것으로 바꿔줍니다.

가비아 홈페이지에서 My가비아>이용 중인 서비스>도메인>(내가 구입한 도메인)관리 로 들어갑니다.

설정을 누르고

위의 호스트명을 모두 바꿔주어야 하는데요,

호스팅 영역에서 확인할 수 있던 NS 레코드의 라우팅 대상 4개를 넣어주면 됩니다.

(마지막에 있는 . 은 제거하고 넣습니다.)

소유자 인증까지 마치고 적용을 눌러주면,

AWS에서 해당 도메인이 내 도메인이라는 것을 인식할 수 있습니다!

ACM(AWS Certificate Manager) 인증서 발급 받기

이제, SSL(TSL) 인증서를 발급 받아야 합니다.

위에서 구매한 도메인에 대한 보안 인증서를 발급 받는다고 생각하시면 됩니다.

먼저 Certificate Manager 대시보드로 이동합니다.

설명에 써있듯, SSL/TLS 인증서를 프로비저닝 해줍니다.

구매한 도메인을 입력합니다.

위와 같이 설정(기본값임)하고 요청을 클릭합니다.

DNS 검증은 이메일 검증보다 빠르고 간편하다고 합니다. (자동 갱신도 지원)

사실 이메일 검증은 안 해봐서 모르겠습니다만..

ACM 메뉴(왼쪽)에서 인증서 나열을 클릭하면, 요청한 인증서를 확인할 수 있습니다.

DNS 검증 기준, 검증 대기중 / 아니요 / 부적격 이 나온다면 정상입니다.

이번에는 위에서 말씀드린 대로, CNAME 레코드를 만들어 보겠습니다.

발급 받은 인증서 ID를 클릭합니다.

Route 53에서 레코드 생성을 클릭합니다.

도메인을 체크하면 되는데, 저는 이미 레코드를 생성해서 체크가 되지 않습니다.

체크 후 레코드 생성을 클릭합니다.

이후 일정 시간이 지나면,

상태가 발급됨으로 변경된 것을 확인하실 수 있습니다.

걸리는 시간에 대한 의견이 분분한데요,

대개 20~30분 정도 소요되고, 길면 2시간까지도 걸린다는 것 같습니다.

그 이상 소요된다면, 과정을 점검해서 다시 요청해볼 필요가 있을 것 같습니다.

지금까지 EC2와 HTTPS 연결을 위해,

도메인을 구매하고,

호스팅 영역을 생성해 도메인을 인증하고,

ACM으로 SSL 인증서를 발급받았습니다.

다음 포스팅에서는 발급 받은 인증서를 가지고,

Load Balancer를 통해 EC2로 접근하는 요청을 리다이렉트해서

https로 연결해보도록 하겠습니다.

다음 포스팅 링크 :

https://woojin.tistory.com/94

감사합니다.

Postman Mock API에 Request param(Path variable)을 사용하는 방법을 적어보겠습니다.

쉽게 말하면, Mock API에 변수를 사용한다고 볼 수 있습니다.

Mock API를 만드는 방법은 생략하겠습니다.

구글에 검색하시면 좋은 아티클이 많이 있습니다!

실제 서버에서는 약속을 통해 woojin.com/user/3 과 같이 주소로 값을 주고 받을 수 있는데요,

Postman의 Mock API에서 Request parameter를 사용하는 방법은 아래와 같습니다.

아래는 Mock API의 Example입니다.

Example이란 Mock API의 요청, 응답 예시 세트 한 개를 의미합니다.

Mock API 생성과 관련한 아티클을 보시면 아시겠지만,

Mock API는 최소 1개의 Example이 존재합니다.

Example에서 {{변수명}} <-- 이렇게 주소의 원하는 위치에 삽입하고,

Response Body의 원하는 위치에 {{변수명}} 과 같이 삽입해주면 됩니다.

해당 Mock API 주소에 GET 메서드를 요청보내보겠습니다.

주소에 넣은 treeId 값대로 Response에 적용된 것을 볼 수 있습니다.

Postman의 Mock API에 더 많은 기능이 생긴 것 같지만

ChatGPT가 안 알려줘서 못 쓰겠네요..

잘 찾아보면 정말 많은 기능을 사용할 수 있을 것 같은데,

오버헤드가 너무 커지는 것도 문제이니 이쯤에서 만족했습니다.

감사합니다.

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

Address 종류

• Logical address (= Virtual address)
  • 프로세스마다 독립적으로 가지는 주소 공간
  • 각 프로세스마다 0번지부터 시작
  • CPU가 보는 주소
• Physical address
  • 메모리에 실제 올라가는 위치
• 주소 바인딩 : 주소를 결정하는 것
  • Symbolic Address → Logical Address —(T)—> Physical address
    • Symbolic Address? → 프로그래머 입장에서 사용하는 숫자가 아닌 변수, 함수 등
  • T가 언제인가?

주소 바인딩 (Address Binding)

• Complie time binding → 비효율적, 요즘은 잘 쓰지 않음 (프로그램을 하나만 실행하던 예전에만 사용)
• Load time binding → 실행 시 메모리 주소 결정
• Run time binding → Load time binding처럼 실행 시 주소 결정 → 실행 도중 바뀔 수 있음

Memory Management Unit (MMU)

• MMU : Logical address를 Physical address로 매핑해주는 Hardware device
• MMU scheme : CPU에서 수행되는 모든 주소값에 base register(=relocation register) 값을 더한다.
• User program은 logical address만 다루고, physical address를 볼 수 없고 알 필요도 없다.

• Limit register는 보안 문제도 해결 → 다른 프로그램 주소 요청은 에러

용어 설명

• Dynamic Loading
  • Loding : 메모리로 올리는 것
  • 프로세스 전체를 메모리에 미리 다 올리는 것이 아니라, 불려지는 루틴에 대해서만 메모리에 load
  • 대개 프로그램 자체에서 구현 (라이브러리 활용)
• Dynamic Linking
  • Linking을 실행 시간까지 미루는 기법
  • Static Linking
    • 라이브러리가 프로그램의 실행 파일 코드에 포함됨 → 실행 파일의 크기가 커짐
    • 동일 라이브러리를 각각의 프로세스가 메모리에 올려 메모리 낭비 (eg. printf 함수의 라이브러리 코드)
  • Dynamic Linking
    • 라이브러리가 실행 시 연결됨
    • 라이브러리 호출 부분에 라이브러리 루틴의 위치를 찾기 위한 stub이라는 작은 코드를 둠
    • 라이브러리가 이미 메모리에 있으면 그 루틴의 주소로, 없으면 디스크에서 읽어옴
    • 운영체제의 도움이 필요
• Overlays
  • 프로그래머가 수작업으로 구현
  • 프로세스에서 실제 필요한 정보만 Loading
• Swapping
  • 프로세스를 일시적으로 메모리에서 Backing store(=swap area)로 쫓아내는 것
  • Backing store : 디스크

Allocation of Physical Memory

Contiguous allocation

• 전체를 밀기 보다는, 최소한의 이동만으로 적당히 큰 hole을 만드는 것도 방법일 수 있음
• 현대 운영체제에서 사용하는 방식은 Noncontiguous allocation

Paging

• Page의 주소는 바뀌지만, Page 내부에서 할당된 상대적 주소는 바뀌지 않는다.

• TLB : 자주 사용되는 Page table의 내용을 가지고 있는 Cache의 일종

• TLB(Associative register) 사용을 안했다면 → Memory cycle time x 2 = 2 였을 것
• 입실론은 알파에 비해 매우 작은 값이라, 실제 주소 접근 시간은 많이 감소한다.

Two-Level Page Table

• 시간, 공간적 손해이지만, 사용되지 않는 주소 공간에 대한 Outer page table의 엔트리 값이 NULL이므로, Outer page table은 전체 길이에 대해 생기지만, Inner page table이 상당 부분 생성되지 않아 메모리 효율이 좋다!

Memory Protection

Inverted Page Table

Shared Page

Segmentation

• Paging에서는 보안이 쉽지 않았음

메모리 관리에서 운영체제의 역할은?

• 대부분의 내용은 주소 변환 → OS의 역할은 없음, 모두 하드웨어가 해줘야 할 일
  • 주소 변환할 때마다 OS가 개입한다면 비효율적

다음 강의에서 배울 가상 메모리에서는 운영체제의 역할이 확실히 있다!

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

The Deadloc Problem

• Deadlock
  • 프로세스들이 서로가 가진 자원을 기다리며 block된 상태
• Resource
  • 하드웨어, 소프트웨어 등을 포함하는 개념
    • I/O device, CPU cycle, Memory space, Semaphore 등
  • 프로세스가 자원을 사용하는 절차는 Request, Allocate, Use, Release

Deadlock 발생의 4가지 조건 (&조건)

• Mutual exclusion (상호 배제)
  • 매 순간 하나의 프로세스만이 자원을 사용할 수 있음
• No preemption (비선점)
  • 프로세스는 자원을 스스로 내어놓을 뿐 강제로 빼앗기지 않음
• Hold and wait (보유 대기)
  • 자원을 가진 프로세스가 다른 자원을 기다릴 때 보유 자원을 계속 가지고 있음
• Circular wait (순환 대기)
  • 자원을 기다리는 프로세스 간에 cycle이 형성되어야 함
  • P0 → P1 → P2 … Pn-1 → Pn → P0

Resource-Allocation Graph (자원 할당 그래프)

• P→R 화살표 : 요청
• R→P 화살표 : 할당
• Cycle이 없으면 deadlock이 아니다
• Cycle이 있으면 (No preemption, Hold and wait 가정)
  • 하나의 리소스에 하나의 인스턴스만 있다면 (cycle에서 사용하는 점이 하나라면) → Deadlock
• 왼쪽 그림
  • Cycle 2개가 각각 Mutual exclusion을 만족 → 남은 Resource가 없음
• 오른쪽 그림
  • P2에게 할당되어 있는 R1, P4에게 할당되어 있는 R2 → P2, P4가 R1 또는 R2를 반납하면 Deadlock이 해소됨 → Deadlock이 아님

Deadlock의 처리 방법

• Deadlock Prevention
  • 자원 할당 시 Deadlock의 4가지 필요 조건 중 하나가 만족되지 않도록 하는 것
• Deadlock Avoidance
  • 자원 요청에 대한 부가 정보를 통해 deadlock 가능성이 없을 때만 자원 할당
  • 시스템 state가 원래 state로 돌아올 수 있는 경우에만 자원 할당
• Deadlock Detection and recovery
  • Deadlock 발생은 허용하되, 그에 대한 detection 루틴을 두어 발견 시 recover
• Deadlock Ignorance
  • Deadlock을 시스템이 책임지지 않음
  • UNIX를 포함한 대부분의 OS가 채택
    • 미연에 방지하는 것이 손해!
  • 작동 안 하면 사람이 알아서 프로세스를 종료하든 한다!

Deadlock Prevention

• Mutual Exclusion
  • 공유해서는 안되는 자원의 경우 만족할 수밖에 없음
• Hold and Wait
  • 프로세스가 자원을 요청할 때 다른 자원을 가지고 있지 않게 한다
  • 방법 1 : 프로세스 시작 시 필요한 모든 자원 할당
  • 방법 2 : 자원이 필요할 경우 보유 자원을 모두 놓기;
• No Preemption
  • 프로세스가 자원을 기다릴 때, 이미 보유한 자원이 선점됨
  • 모든 필요한 자원을 얻을 수 있을 때 프로세스 다시 시작
  • State를 쉽게 save, restore할 수 있는 자원에서 주로 사용 (CPU, Memory)
• Circular Wait
  • 모든 자원 유형에 할당 순서를 정한다.
    • 순서가 3인 Ri를 보유 중인 프로세스가, 순서가 1인 자원 Rj를 할당 받기 위해서는 Ri를 우선 release해야 한다

→ Utilization 저하, Throughput 감소, Starvation 문제

발생하지 않을 Deadlock을 위해 제약 조건을 달아놓아야 해서 비효율적이다.

Deadlock Avoidance

• Available이 Max보다 큰 프로세스에 대해서만 자원을 할당해준다
• P1 → P3 → P4 → P2 → P0 순서로 수행가능하므로 deadlock이 절대 생기지 않음 (다른 순서도 가능)
• 작은 Deadlock 가능성만 가지고도 할당을 하지 않으므로 비효율적

Deadlock Detection and Recovery

• Recovery
  • Process termination
    • Deadlock에 연루된 프로세스를 모두 종료
    • Deadlock cycle이 소멸될 때까지 프로세스를 하나씩 종료
  • Resource Preemption
    • 비용을 최소화 할 victim 선정
    • Safe state로 rollback하여 프로세스를 재시작
    • Starvation 문제
      • 동일한 프로세스가 계속 victim으로 선정되는 경우
        • Cost factor에 rollback 횟수도 같이 고려

Deadlock Ignorance

• Deadlock은 매우 드물게 발생 → 조치 자체가 더 큰 Overhead일 수 있음
• Deadlock 발생 → 시스템 비정상 작동 사람이 감지 → 직접 Process 종료 등
• UNIX, Windows 등 대부분의 범용 OS가 채택

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

데이터 접근

만약 연산 주체(E-Box)가 여러 개라면?

Race Condition(경쟁 상태)

• S-box를 공유하는 E-box가 여럿 있는 경우
  • 메모리 주소공간(S-box), CPU 프로세서(E-box) → Multiprocessor system
  • 공유메모리를 사용하는 프로세스들
  • 커널 내부 데이터를 접근하는 루틴들 간(예: 커널모드 수행 중 인터럽트로 커널모드의 다른 루틴 수행 시)

Race condition 1 - OS에서 Interrupt handler vs kernel

• kernel 명령 수행 중, interrupt 차단
• 커널모드 running 중 interrupt가 발생하여 인터럽트 처리 루틴이 수행
  • 양쪽 다 커널 코드이므로, kernel address space 공유

Race condition 2 - 프로세스가 시스템 콜을 하여 커널 모드로 수행 중인데, context switch가 일어나는 경우

• u : user mode / k : kernel mode
• 해결책 : 커널 모드에서 수행 중일 때는 CPU를 선점(preempt)하지 않고, 사용자 모드로 돌아갈 때 선점

Race condition 3 - Multiprocessor에서 shared memory 내의 kernel data

• 방법 1) 한 번에 하나의 CPU만이 커널에 들어갈 수 있게 하는 방법 (커널 전체에 대해 lock / unlock) → 비효율
• 방법 2) 커널 내부에 있는 각 공유 데이터에 접근할 때마다 그 데이터에 대해 lock / unlock을 하는 방법

Process Synchronizatino 문제

• 공유 데이터의 동시 접근(Concurrent access)은 데이터의 불일치 문제(Inconsistency) 발생 가능성
• 일관성(Consistency) 유지를 위해 협력 프로세스 간 실행 순서 정해주는 메커니즘 필요
• Race condition
  • 여러 프로세스들이 동시에 공유 데이터를 접근하는 상황
  • Race condition을 막기 위해 → Concurrent process는 동기화(Synchronize)되어야 한다.

The Critical-Section Problem

• Critical-Section : 공유 데이터를 접근하는 코드
• n개의 프로세스가 공유 데이터를 동시에 사용하기 원하는 경우
• 각 프로세스의 code segment에는 공유 데이터를 접근하는 코드인 critical-section이 존재
• Problem : 하나의 프로세스가 critical section에 있을 때, 다른 모든 프로세스는 critical section에 들어갈 수 없어야 한다

Critical-Section 문제를 해결하기 위한 초기의 시도

• 아래는 프로세스들의 일반적인 구조

do {
    entry section
    critical section
    exit section
    remainder section
} while (1);

• 프로세스들은 Synchronize를 위해 몇몇 변수를 공유할 수 있다 → Synchronization variable

아래에서 문제 해결을 알아보자

프로그램적 해결법의 충족 조건

• Mutual Exclusion (상호 배제)
  • 한 프로세스가 Critical-section 부분을 수행 주이면, 다른 모든 프로세스들은 각자의 Critical-section에 들어가면 안 된다.
• Progress
  • 아무도 Critical-section에 있지 않은 상태에서 critical section에 들어가고자 하는 프로세스가 있다면 들어가게 해주어야 한다.
• Bounded Waiting (유한 대기)
  • 프로세스가 critical section에 들어가려고 요청한 후부터 허용될 때까지, 다른 프로세스들이 critical section에 들어가는 횟수에는 한계가 있어야 한다.

** 두 개의 프로세스 P1, P2가 있다고 가정

Algorithm 1

• Synchronization variable : turn 사용
• P0 프로세스의 코드

int turn = 0; // => Pi는 turn == i일 때 critical section에 들어갈 수 있음

do {
    while (turn != 0); // 자기 차례가 아니면 while문에서 대기
    critical section
    turn = 1;
    remainder section
} while (1);

→ Bounded waiting을 지키지 못함

Algorithm 2

• Synchronization variables
  • boolean flag[2];
  • initially flag[all] = false;
  • flag[i] == trun → Pi가 CS에 들어갈 준비가 되었다.
• Process Pi

do {
    flag[i] = true;
    while (flag[j]) ; // Pj가 CS에 있으면 while문에서 대기;
    critical section
    flag[i] = false // CS에서 나갈 때 flag를 false로
    remainder section
} while (1);

• Mutual Exclusion을 만족하지만, Progress를 만족하지 않음
• 두 프로세스가 모두 2행까지 수행 후, 끊임 없이 양보하는 상황이 발생할 수 있음

Algorithm 3 (Peterson’s Algorithm)

• Algorithm 1, 2의 synchronization variables를 합친 알고리즘
• Process Pi

do {
    flag[i] = true;
    turn = j;
    while (flag[j] && turn == j); // 상대가 CS에 들어가려하고, 상대 턴이면 대기
    critical section // 상대가 CS에 들어갈 의사가 없거나, 의사는 있지만 상대 차례가 아니면 진입
    flag[i] = false;
    remainder section
} while (1);

• 3가지 충족 조건을 모두 만족; 2개의 프로세스에 대한 Critical-Section 문제를 해결
• Problem : Busy Waiting!(=Spin lock) (계속 CPU와 Memory를 쓰면서 wait)
  • while문을 계속 돌면서 lock을 건다.

Synchronization Hardware

• 하드웨어적으로 Test & modify를 atomic하게 수행할 수 있도록 지원한다면, 앞의 문제는 간단히 해결

• 읽기와 쓰기가 하나의 Instruction으로 실행 → 도중에 CPU를 뺏기지 않음
• a가 0이면 → 0을 읽어오고 1로 수정
• a가 1이면 → 1을 읽어오고 1로 수정
• Mutual Exclusion with Test & Set

// Synchronization variable:
boolean lock = false;

// Process Pi
do {
    while (test_and_set(lock));
    // lock이 0이면 -> 아무도 CS에 있지 않음 -> while문을 통과하고 1로 수정
    // lock이 1이면 -> while문에서 대기
    critical section
    lock = false;
    remainder section
} while (1);

• 여전히 Busy waiting 문제 발생

Semaphores

• 앞의 방식들을 추상화시킴
  • 추상 자료형을 사용 → 컴퓨터 내부에 구현된 실제 자료구조와 별개로, Object와 연산을 가지고 있는 자료형
• Semaphore S
  • Integer variable
  • 아래의 두 가지 atomic 연산에 의해서만 접근 가능
    • P(S) → 공유 데이터를 획득하는 과정
      • while(S≤0) do no-op; → wait / 여전히 busy waiting
      • S—;
    • V(S) → 사용 후 반납하는 과정
      • S++;
• Critical Section of n Processes

// Synchronization variable;
Semaphore mutex; // initially 1: 1개가 CS에 들어갈 수 있다

// Process Pi
do {
    P(mutex); // 양수면 감소시키고 CS 진입, 아니면 wait
    critical section
    V(mutex); // Semaphore 증가
    remainder section
} while (1);

Block / Wakeup Implementation

• CS 진입 차례가 아닌 프로세스를 block해 Busy waiting 문제 해결
• Semaphore를 아래와 같이 정의
• typedef struct { int value; // semaphore struct process *L; // process wait queue } semaphore;
• block : 호출한 프로세스를 suspend 시키고, 해당 프로세스의 PCB를 semaphore에 대한 wait queue에 넣음
• wakeup(P) : 블록된 프로세스 P를 wakeup / 해당 프로세스의 PCB를 Ready queue로 옮김

• P(S)
• S.value--; // prepare to enter if (S.value < 0) // 음수면 block { add this process to S.L // block(); }
• V(S)
• S.value++; if (S.value <= 0) { remove a process P from S.L; wakeup(P); }
• 추상 자료형에서 S는 자원의 개수를 나타냈지만, 지금 S.value는 기다리는 프로세스의 개수를 나타내는 값(음수로)

Busy-wait vs Block/Wakeup

• Critical section의 길이가 긴 경우 Block/Wakeup이 적당
• Critical section의 길이가 매우 짧은 경우 → Block/Wakeup 오버헤드가 Busy-wait 오버헤드보다 더 커질 수 있음
• 일반적으로는 Block/Wakeup 방식이 더 좋음

Semaphore의 종류

• Counting Semaphore
  • 도메인이 0 이상인 임의의 정수값
  • 주로 자원이 여러 개일 때, Resource counting에 사용
• Binary Semaphore (=mutex)
• 0 또는 1 → 자원이 1개
• 주로 Mutual exclusion(lock/unlock)에 사용

Deadlock and Starvation

• Deadlock(교착 상태) : 둘 이상의 프로세스가, 서로 상대방의 의해 충족될 수 있는 event를 무한히 기다리는 현상
  • S, Q가 1로 초기화된 Semaphore라 하자
   

• Starvation
  • 프로세스가 suspend된 이유에 해당하는 Semaphore 큐에서 빠져나갈 수 없는 현상

Bounded-Buffer Problem

• mutex, empty, full 은 각각의 Semaphore
• mutex는 전체 lock/unlock을 관장

Readers-Writers Problem

• 한 프로세스가 DB에 write 중일 때, 다른 프로세스가 접근하면 안됨
• Read는 여럿이 동시에 해도 됨
• readcount(Shared data) : 현재 DB에 접근 중인 Reader의 수
• mutex(Synchronization variable) : readcount 접근(critical section)의 mutual exclusion 보장을 위해 사용
• db : Reader와 Writer가 공유 DB 자체를 올바르게 접근하게 하는 역할
• 처음 읽을 때 db에 P, 다 읽고 나갈 때 더이상 Reader가 없다면 V(db)
• Reader가 다 빠져나가야만 Writer가 DB에 접근 가능
  • → Starvation 발생 가능!

Dining-Philosophers Problem

• Philosopher의 행동
  • 밥 먹기 (양쪽 젓가락을 잡고)
  • 생각하기 (양쪽 젓가락을 놓고)
• 위의 Solution의 문제점 : Deadlock의 가능성이 있음
  • 모두가 왼쪽 젓가락을 잡게 되면 → 오른쪽 젓가락을 잡는 코드를 모두가 기다리게 됨
  • 해결 방안
    1. n-1명의 철학자만 테이블에 동시에 앉을 수 있도록 한다.
    2. 젓가락을 두 개 모두 집을 수 있을 때만 젓가락을 집게 한다.
    3. 비대칭 : 짝수 철학자는 왼쪽, 홀수 철학자는 오른쪽 젓가락부터 집도록
• 2번 해결 방안에 대한 코드

Semaphore의 문제점

• 코딩하기 힘들다
• 정확성의 입증이 어렵다
• 자발적 협력이 필요하다
• 한 번의 실수가 모든 시스템에 치명적 영향

→ Monitor 도입

Monitor

• 프로그래밍 언어 레벨에서 제공하는 High-level synchronization construct
• 동시 수행 중인 프로세스 사이에서 Abstract data type의 안전한 공유를 보장
• 내부의 프로시저를 통해서만 공유 데이터에 접근할 수 있게 만듦

• Monitor는 그 자체가 하나의 프로세스만 접근할 수 있음 (lock을 따로 걸 필요가 없다)
• Synchronization 제약 조건을 명시적으로 코딩할 필요 없음
• 프로세스가 모니터 안에서 기다릴 수 있도록 Condition variable 사용
  • condition x, y;

Problems solved by Monitor

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

[운영체제

운영체제는 컴퓨터 하드웨어 바로 위에 설치되는 소프트웨어 계층으로서 모든 컴퓨터 시스템의 필수적인 부분이다. 본 강좌에서는 이와 같은 운영체제의 개념과 역할, 운영체제를 구성하는 각

www.kocw.net](http://www.kocw.net/home/cview.do?cid=3646706b4347ef09)

프로그램은 CPU burst와 I/O burst가 번갈아서 진행된다.

Burst : 연속적으로 실행하고 있는 단계

• I/O bound job : I/O burst가 잦은 프로그램
  • 짧은 CPU burst가 많은 수로 존재
• CPU bound job : CPU burst 지속시간이 긴 프로그램
  • 긴 CPU burst가 적은 수로 존재
• 여러 종류의 Job(=process)이 섞여 있기 때문에 CPU 스케줄링이 필요하다
• Interactive job에게 적절한 response 제공 요망
• CPU와 I/O 장치 등 시스템 자원을 골고루 효율적으로 사용
• 공평하게보다는 효율적으로 CPU 자원을 분배할 필요성 (사람과의 상호작용 고려)

CPU Scheduler & Dispatcher

• CPU Scheduler
  • Ready 상태의 프로세스 중에서 CPU를 넘겨줄 프로세스를 고른다
  • 운영체제 안의 코드로 존재
• Dispatcher
  • CPU의 제어권을 넘기는 역할
    • 이 과정을 Context switch(문맥 교환)라고 한다.
  • 운영체제 안의 코드로 존재
• CPU 스케쥴링이 필요한 경우는 다음과 같은 상태 변화가 있는 경우이다.
  1. Running → Blocked(eg: I/O 요청하는 시스템 콜)
  2. Running → Ready(eg: 할당시간 만료로 Timer interrupt)
  3. Blocked → Ready(eg: I/O 완료 후 인터럽트)
  4. Terminate2, 3 등 그 외 모든 스케줄링 → Preemptive (강제로 빼앗음)
  5. 1, 4 → Nonpreemptive (자진 반납)

성능 척도 (Scheduling Criteria)

• CPU 입장에서
  • CPU utilization (이용률)
    • CPU가 가능한 바쁘게 유지하기
  • Throughput(처리량)
    • 단위 시간 당 완료하는 실행
• 프로세스 입장에서
  • Turnaround time (소요시간, 반환시간)
    • 특정 프로세스를 실행하는 데에 걸린 시간 (Ready queue에 들어와서 실행을 마치고 나가기까지)
  • Waiting time (대기 시간)
    • 순수하게 기다린 시간(in ready queue)
    • CPU burst 동안에 생기는 대기까지 모두 포함
  • Response time (응답 시간)
    • Ready queue에 들어와서 처음 CPU를 얻기까지 걸린 시간
• 위 얘기들은 프로세스가 실행되어 종료되기까지를 얘기하는 것이 아니라
• → 한 번의 CPU burst에 있어서를 얘기하는 것!

FCFS (First-Come First-Served)

• 프로세스 도착 순서대로 CPU 할당

• P1 = 0 / P2 = 24 / P3 = 27 (Waiting time)
• Average : 17

• P2 = 0 / P3 = 3 / P1 = 6 (Waiting time)
• Average : 3
• 앞에 도착한 프로세스의 사용시간이 긴 경우 → 평균 Waiting time이 길어짐 (Convoy effect라고 함)
• → 좋은 알고리즘이 아님

SJF (Shortest-Job-First)

• 각 프로세스의 다음번 CPU burst time을 가지고 스케줄링에 활용
• CPU burst time이 가장 짧은 프로세스를 제일 먼저 스케줄
• Two schemes
  • Nonpreemptive : 일단 CPU를 잡으면, CPU burst 완료 시까지 CPU를 선점(preemption) 당하지 않음
  • Preemptive : 현재 수행 중인 프로세스의 남은 burst time보다 더 짧은 CPU burst time을 가지는 새로운 프로세스 도착 시 → CPU를 빼앗김 (SRTF : Shortest-Remaining-Time-First)
• SJF is optimal for Waiting time
  • 주어진 프로세스들에 대해 Minimum average waiting time을 보장 (SRTF)

Nonpreemptive SJF 예제

• P1 도착 후 바로 실행 → 나머지 모두 도착했으니, Burst가 짧은 P3 실행
• Average waiting time = (0 + 6 + 3 + 7(순서대로)) / 4 = 4

Preemptive SJF(SRTF) 예제

• 도착한 프로세스의 Burst time과 실행 중인 프로세스의 Remaining burst time을 비교
• Average waiting time = 3
  • P1 = 9
  • P2 = 3
  • P3 = 0
  • P4 = 2

SJF의 문제점

1. Starvation(기아 현상)
   
   1. → CPU burst time이 긴 프로세서는 너무 오래 실행되지 않을 가능성이 있음
2. CPU Burst time 예측이 불가능함
   1. branch, user input 등이 있기 때문 
   2. 추정만이 가능 → 과거의 CPU burst time을 이용해서 추청 (exponential averaging)

Priority Scheduling

• 각 프로세스에 우선 순위가 할당됨
  • 높은 우선 순위(작은 Integer)의 프로세스에게 CPU 할당
  • Preemptive와 Nonpreemptive
• SJF는 일종의 Priority scheduling이다.
  • 우선 순위 → 다음 CPU burst time의 예측값이 낮은 순
• 문제점 : Starvation(기아 현상) → Low priority 프로세스가 실행되지 않을 수 있다.
  • 해결 : Aging(노화) ㅍ 시간이 지남에 따라 Priority를 높인다.

Round Robin (RR)

• 현대 운영체제 스케줄링은 RR에 기반
• 각 프로세스는 동일한 크기의 할당 시간(time quantum)을 가짐
  • 일반적으로 10~100ms
• 할당 시간이 지나면 프로세스는 선점(preempted)당하고 ready queue의 제일 뒤에 가서 다시 줄을 선다
• n개의 프로세스가 ready queue에 있고 할당 시간이 q time unit인 경우, 각 프로세스는 최대 q time unit 단위로 CPU 시간의 1/n을 얻는다.
• → 어떤 프로세스도 (n-1)q time unit 이상 기다리지 않는다.
• Performance
  • q large → FCFS(First-Come First-Served)
  • q small → Context switch 오버헤드가 커진다

• 일반적으로 SJF보다 Average turnaround time이 길지만, response time은 더 짧다.

Multilevel Queue

• Ready queue를 여러 개로 분할
  • 각 큐는 독립적인 스케줄링 알고리즘을 가짐
  • Foreground (interactive) : RR
  • Background (batch - no human interaction) : FCFS
• 큐에 대한 스케줄링이 필요
  1. Fixed priority scheduling
     • Foreground 먼저 제공하고 Background 제공
     • Starvation 가능성
  2. Time slice
     • 각 큐에 CPU time을 적절한 비율로 할당
     • Eg., 80% to foreground in RR, 20% to background in FCFS

Multilevel feedback queue

• 프로세스가 다른 큐로 이동 가능

Multiple-Processor Scheduling

• CPU가 여러 개인 경우 스케줄링은 더욱 복잡해짐
• Homogeneous processor인 경우 (균일한 프로세서)
  • Queue에 한 줄로 세워서 각 프로세서가 꺼내가게 할 수 있음
  • 특정 프로세서에서만 수행되어야 하는 프로세스가 있는 경우 → 문제가 복잡해짐
• Load sharing
  • 일부 프로세서에 job이 몰리지 않도록 부하를 적절히 공유하는 메커니즘이 필요
  • 별개의 큐를 두는 방법 vs 공동 큐를 사용하는 방법
• Symmetirc Multiprocessing (대등한, 대칭 CPU)
  • 각 프로세서가 각자 알아서 스케줄링 결정
• Asymmetric Multiprocessing (비대칭 CPU)
  • 하나의 프로세서가 시스템 데이터 접근, 공유를 전담
  • 나머지 프로세스는 거기에 따름

Real-Time scheduling

• Hard real-time systems : Task를 정해진 시간 안에 반드시 끝내도록 스케줄링
• Soft real-time systems: 해당 Task의 Priority를 일반 프로세스에 비해 높게 설정

Thread Scheduling

• Local Scheduling
  • User level thread의 경우 사용자 수준의 thread library에 의해 어떤 thread를 스케줄할지 결정
• Global Scheduling
  • Kernel level thread의 경우 일반 프로세스와 마찬가지로 커널의 단기 스케줄러가 어떤 thread를 스케줄할지 결정

Algorithm Evaluation

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

프로세스 생성 (Process Creation)

• 부모 프로세스가 자식 프로세스를 생성
• 프로세스의 트리 형성(계층 구조)
• 프로세스에게 필요한 자원
  • 운영체제로부터 받는다
  • 부모와 공유한다
• 자원의 공유 방식 → 가능하면 공유하다가 COW(Copy-on-Write)
  • 부모와 자식이 모든 자원 공유하는 모델
  • 일부를 공유하는 모델
  • 전혀 공유하지 않는 모델
• 수행(Execution)
  • 부모와 자식이 공존하며 수행되는 모델
  • 자식이 종료(Terminate)될 때까지 부모가 기다리는 모델
• 주소 공간(Address space)
  • 자식은 부모의 공간을 복사함(+ OS data)
  • 그 공간에 새로운 프로그램을 올림
• 유닉스의 예
  • fork() 시스템 콜이 새로운 프로세스를 생성
    • 부모를 그대로 복사
    • 주소 공간 할당
  • fork 다음에 이어지는 exec() 시스템 콜을 통해 새로운 프로그램을 메모리에 올림

프로세스 종료 (Process Termination)

• 프로세스가 마지막 명령을 수행한 후 운영체제에게 이를 알려주는 경우(exit 시스템 콜)
  • 자식이 부모에게 output data를 보냄 (via wait)
  • 프로세스의 각종 자원들이 운영체제에게 반납됨
• 부모 프로세스가 자식의 수행을 종료시키는 경우(abort 시스템 콜)
  • 자식이 할당 자원의 한계치를 넘어섬
  • 자식에게 할당된 Task가 더이상 필요하지 않음
  • 부모가 종료(exit)하는 경우
    • 운영체제는 부모 프로세스가 종료하는 경우 자식이 더이상 수행되도록 두지 않는다
    • 단계적인 종료

fork() 시스템 콜

• 프로세스는 fork() 시스템 콜에 의해 생성된다
  • 생성된 새로운 주소 공간은, caller의 복제이다.

int main() {
    int pid;
    pid = fork();
    if(pid == 0) printf("\n Hello, I am child!\n");
    else if(pid > 0) printf("\n Hello, I am parent!\n");
}

• fork() 메서드가 실행되면, 새로운 프로세스가 생성된다.
  • 이때, 생성된 프로세스는 부모 프로세스의 문맥을 그대로 이어 받아, fork() 메서드 실행 이후의 코드부터 실행한다.

exec() 시스템 콜

• 프로세스는 exec() 시스템 콜을 통해 다른 프로그램을 실행한다.
  • 새로운 프로그램으로 caller의 메모리 이미지를 대체한다.

int main() {
    int pid;
    pid = fork();

    if(pid == 0) {
        printf("\n Hello, I am child!\n");
        execlp("/bin/date", "/bin/date", (char *) 0);
    }

    else if(pid > 0) {
        printf("\n Hello, I am parent!\n");
    }
}

/* date */
int main() {
    ...
}

• fork()를 통해 복제된 자식 프로세스라면(if pid == 0) → execlp() 함수를 실행한다.

wait() 시스템 콜

• 프로세스 A가 wait() 시스템 콜을 호출하면
  • 커널은 child가 종료될 때까지 프로세스 A를 sleep 시킨다(blocked 상태)
  • Child process가 종료되면 커널은 프로세스 A를 깨운다 (ready 상태)

int main {
    int childPID;
    S1;

    childPID = fork();

    if(childPID == 0)
        ...
    else {
        wait();
    }

    S2;
}

exit() 시스템 콜

• 프로세스의 종료
  • 자발적 종료
    • 마지막 문장 수행 후(혹은 exit() 시스템 콜이 명시되어 있을 때) exit() 시스템 콜을 통해 이루어짐
    • main 함수 리턴 위치에 묵시적으로 컴파일러가 넣어줌
  • 비자발적 종료
    • 부모 프로세스가 자식 프로세스를 강제 종료시킴
      • 자식 프로세스가 한계치를 넘어서는 자워 ㄴ요청
      • 자식에게 할당된 태스크가 더이상 필요하지 않을 때
    • 키보드로 kill, break 등을 친 경우
    • 부모가 종료하는 경우
      • 부모 종료 전에 자식들이 먼저 종료됨

프로세스 간 협력

• 독립적 프로세스 : 프로세스는 각자의 주소 공간을 가지고 수행되므로, 원칙적으로 다른 하나의 프로세스는 다른 프로세스의 수행에 영향을 미치지 못함
• 협력 프로세스 : 프로세스 협력 메커니즘을 통해 영향을 미칠 수 있음
• 프로세스 간 협력 메커니즘(IPC: InterProcess Communication)
  • 메시지 전달(Message passing) : 커널을 통해 메시지 전달
  • 주소 공간 공유(Shared memory) : 서로 다른 프로세스 간에도 일부 주소 공간 공유
  • ** Thread는 사실상 하나의 프로세스이므로 프로세스 간 협력으로 보기 어렵지만, 동일한 Process를 구성하는 Thread들 간에는 주소 공간을 공유하므로 협력이 가능

Message Passing

• 프로세스 사이에 공유 변수를 일체 사용하지 않고 통신하는 시스템
• Direct Communication : 통신하려는 프로세스의 이름을 명시적으로 표시

• Indirect Communication : Mailbox(또는 Port)를 통해 메시지를 간접 전달

** KOCW에서 반효경 교수님의 운영체제(2014년) 강의를 수강한 내용을 정리한 글입니다.

프로세스의 개념

• “Process is a program in execution”
• 프로세스의 문맥
  • 현재 프로세스를 규정하는 모든 정보
  1. 하드웨어 문맥
     • Program Counter
     • Register가 어떤 값을 가지고 있었는가
  2. 프로세스의 주소 공간
     • Code, Data, Stack
  3. 프로세스 관련 커널 자료 구조
     • PCB(Process Control Block)
     • Kernel stack

프로세스의 상태(Process State)

→ 프로세스는 상태가 변경되며 수행된다

• Running
  • CPU를 잡고 Instruction을 수행 중인 상태
• Ready
  • CPU를 기다리는 상태
  • 메모리 등 다른 조건은 모두 만족한 상태여야 함
• Blocked(wait, sleep)
  • CPU를 주어도 당장 Instruction을 수행할 수 없는 상태
  • Process 자신이 요청한 event(예: I/O)의 수행을 기다리는 상태
    • 예) 디스크에서 file을 읽어와야 하는 경우 / 물리적 메모리에 주소 공간이 올라오지 않은 경우
• New : 프로세스가 생성 중인 상태
• Terminated : 수행(Execution)이 끝난 상태

Process Control Block(PCB)

• 운영체제가 각 프로세스를 관리하기 위해 프로세스마다 가지고 있는 정보
• 구성 요소는 아래와 같다(구조체로 유지)
  1. OS가 사용하는 정보
     • 프로세스 상태, 프로세스 ID
     • 스케쥴링 정보, 우선순위
  2. CPU 수행 관련 하드웨어 값
     • PC, Registers
  3. 메모리 관련
     • Code, Data, Stack의 위치 정보
  4. 파일 관련
     • 오픈하고 있는 파일들이 어떤 것인지

문맥 교환(Context Switch)

• CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정
• CPU가 다른 프로세스에게 넘어갈 때
  • CPU를 내어주는 프로세스의 상태를 해당 프로세스의 PCB에 저장
  • CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 읽어옴

• 시스템 콜이나 인터럽트 발생 시, 반드시 문맥 교환이 일어나는 것은 아님

• (1)의 경우에서 CPU 수행 정보 등 Context 일부를 PCB에 저장해야 하지만, 문맥 교환을 하는 (2)의 경우 부담이 훨씬 크다 (eg. Cache memory flush)

스케쥴러(Scheduler)

• 숏텀 스케쥴러(CPU Scheduler)
  • 어떤 프로세스에 CPU를 줄지(어떤 프로세스를 다음번에 running시킬지) 결정
  • 충분히 빨라야 함(ms 단위)
• 롱텀 스케쥴러(Job Scheculer)
  • 프로세스에 Memory(및 각종 자원)를 주는 문제
  • 시작 프로세스 중 어떤 것들을 Ready queue로 보낼지 결정
  • Degree of Multiprogrammimng을 제어(메모리에 올라가 있는 프로세스 수를 제어)
  • 우리가 사용하는 Time sharing system에서는 보통 롱텀 스케쥴러가 없음 (무조건 Ready)
    • 그럼 Degree of Multiprogramming을 어떻게 제어? → 미디엄텀 스케쥴러
• 미디엄텀 스케쥴러(Swapper)
  • 여유 공간 마련을 위해 일부 프로세스를 통째로 메모리에서 디스크로 쫓아냄
  • 프로세스에게서 Memory를 뺏는 문제
  • Degree of Multiprogramming을 제어
    • 그럼 Swap된 프로세스는 Ready, Running, Blocked 중 어떤 상태인가?
  • → 새로운 상태 Suspended(stopped)

Suspended vs Blocked

• Suspended(stopped)
  • 외부적인 이유로 프로세스의 수행이 정지된 상태
  • 프로세스 통째로 디스크에 Swap out 된다
  • 예시)
    • 사용자가 프로그램을 일시 정지
    • 시스템이 여러 이유(메모리가 가득참 등 → 미디엄텀 스케쥴러)로 프로세스를 잠시 중단
• Blocked : 자신이 요청한 event가 만족되면 Ready
• Suspended : 외부에서 resume해주어야 Active(Running, Ready, Blocked의 상태)

• 시스템 콜이 있으면 → OS가 Running이라고 표현하지 않는다
  • 프로세스가 스스로의 코드를 동작하고 있으면 user mode
  • 프로세스가 시스템 콜을 하면 monitor mode(커널 모드) 상태라고 한다.

Thread(쓰레드)

• Thread는 CPU 동작의 가장 기초가 되는 단위이다.
• 프로세스의 하위 개념으로, 동일한 동작을 하는 프로세스를 하나로 묶어놓은 것
• Thread의 독자적인 구성 → 실행을 위한 것들
  • Program Counter
  • Register Set
  • Stack Space
• Thread가 동료 Thread와 공유하는 부분 (= Task)
  • Code section
  • Data section
  • OS resources
• 전통적인 개념의 프로세스(Heavyweight process)는 하나의 Thread(Lightweight process)를 가지고 있는 Task로 볼 수 있다

Thread의 장점

• 하나의 Thread가 blocked 상태인 동안에도, 동일한 Task 내의 다른 Thread(동료 Thread)가 running되어 빠른 처리를 할 수 있다.
  • eg) Multi-threaded Web : 웹 페이지 → HTML 받아오고 → HTML 안에 렌더링할 이미지를 받아오는 동안(별도의 Thread) + 텍스트라도 먼저 Display(별도의 Thread)
• 메모리 공간을 절약할 수 있다.
  • Binary code, Data, Resource of the process를 공유할 수 있음
• 경제성(빠른 속도)
  • 프로세스를 만드는 것보다 Thread를 추가하는 것, 프로세스 문맥 교환보다 Thread 스위칭이 훨씬 빠름
  • Solaris의 경우 두 가지 Overhead가 각각 30배, 5배
• 병렬성을 높일 수 있다. (CPU가 여러 개라면 → 각 CPU에 다른 Thread를 할당!)

커널 쓰레드, 유저 쓰레드

• Kernel Threads → 커널이 쓰레드의 존재를 알고 직접 관리
• User Threads → 커널은 쓰레드의 존재를 모르고, 프로세스 본인이 내부에서 쓰레드를 생성하고 관리
  • 제약이 있음