1.1 여러분이 프로그래밍 언어를 발명한다면?

CPU는 개폐(on-off)만 이해하는 매우 원시적인 기계.

• 저수준 언어: 천공카드 -> 어셈블리어

• 고급 프로그래밍 언어: 명령의 규칙과 패턴을 statement(문)으로 -> 중첩된 statement를 syntax(구문)으로 -> syntax를 컴퓨터가 이해할 수 있도록 syntax tree(구문트리)로 준비 -> compiler가 리프노드부터 재귀적으로 기계명령어로 번역

• 해석형 언어: CPU 형식 별로 다른 기계어를 쓰는 문제가 있음. 마치 영어가 국제 통용어로 사용되듯이 CPU 형식과 무관한 표준 명령어 집합을 만들어 사용하고, CPU의 기계 명령어 실행 과정을 모방하는 프로그램을 따로 준비해서 실행하는 것으로 해결. '모방'한다고 표현한 것은, 표준 명령어로만 실행해도 각 CPU의 특성에 맞는 기계명령어가 실행되는 맥락을 의미한 것. 이러한 CPU 시뮬레이션 프로그램을 가상머신(virtual machie) 혹은 인터프리터(interpreter) 라고 부름.

1.2 컴파일러는 어떻게 작동하는 것일까?

컴파일러는 고수준 언어를 저수준 언어로 번역하는 "프로그램"의 일종.
소스코드를 입력하면 실행 파일을 반환한다. 텍스트 처리 프로그램 이라고 볼 수도 있다.

1. 소스코드에서 어휘 분석(lexical analysis)을 통해 토큰(token)을 추출한다.

    int a = 1;
    int b = 2;
    
    while (a < b)
    {
    	b = b - 1;
    }

	⬇️

    T_Keyword		int
    T_Identifier 	a
    T_Assign		=
    ...
    (각 행이 하나의 토큰을 의미)

2. 코드가 작성된 구문 문법에 따라 토큰을 해석(parsing)한다. 이 과정에서 문법 오류(syntax error)를 검사한다.
   • 예를 들어, while 구문으로 작성된 코드가 있다면 while 키워드의 토큰을 찾으면 다음 토큰은 ( 여야 한다는 전제 하에 해석을 진행.
3. 해석해낸 구조를 토대로 구문 트리를 생성한다. 이렇게 트리를 생성하는 전체 과정을 구문 분석이라고 한다.
4. 생성된 구문트리에 이상이 없는지를 확인하기 위해 의미분석(semantic analysis)을 실행한다. 이 과정에서 컴파일 오류를 검사한다.
   • 예를 들어, 정수와 문자열을 더할 수 없고 비교 좌우에 있는 자료형이 다르면 안된다.
5. 구문트리를 탐색한 결과로 중간코드(IR Code)를 생성하고, 이를 어셈블리어 -> 기계 명령어 의 순서로 변환한다.
   (Intermediate Representation Code)

이것은 실제로는 매우 복잡한 과정.

이후에는, 소스코드가 소스파일에 있듯 기계명령어는 대상파일(object file)에 저장되는데, 여러 개의 대상파일을 묶기 위해 링크(link) 라는 작업이 필요.

1.3 링커의 말할 수 없는 비밀

링커는 컴파일러가 생성한 대상 파일 여러개를 하나로 묶어 하나의 최종 실행 파일을 생성하는 프로그램의 일종.
여러 개의 대상 파일을 하나로 묶는 행위는 주로 '외부 코드'를 사용해서 프로그래밍 하기 위함.
외부 코드는 '정적 라이브러리' 혹은 '동적 라이브러리'로 제공될 수 있음.

링크 과정은 심벌 해석(symbol resolution) / 실행 파일 생성 / 재배치(relocation) 등으로 구성.

1. 심벌 해석(symbol resolution)
   1. 컴파일 된 각 대상파일은 기계 명령어가 저장되는 코드 영역과 전역 변수가 저장되는 데이터 영역으로 나눌 수 있음.
   2. 컴파일 과정에서는 데이터 영역에서 참조하고 있는 전역 변수들이 실제로 외부에 존재하는지 확인하지 않음.
   3. 이는 링커가 심벌 해석 과정을 통해 확인.

• 심벌(symbol): 전역 변수와 함수의 이름을 포함하는 모든 변수 이름을 의미.
• 심벌을 수요와 공급으로 이해할 수 있다.
  • 공급 - 내가 정의한 심벌, 즉 다른 모듈에서 사용할 수 있는 심벌
  • 수요 - 내가 참조하는 외부 심벌
• 컴파일러는 링커를 위해 각 대상 파일에 심벌들의 수요와 공급을 기록해 두는데 그것이 심벌 테이블(symbol table).
• 결국, 심벌 해석이란 각 대상 파일에서 사용할 외부 심벌에 대해 심벌 테이블에서 유일한 정의를 발견할 수 있는지를 확인하는 작업.
• 공급이 수요를 초과할 수는 있으나, 수요가 공급을 초과하면 오류.

2. 실행 파일 생성
   정적 라이브러리와 동적 라이브러리는 둘 다 미리 컴파일 되어 있다.

• 정적 라이브러리 (static library) - .lib (win) / .a (linux)
  • 미리 컴파일이 완료된 내용이 실행 파일에 통째로 복제됨 (정적 링크 - static linking)
  • 외부 코드를 함께 매번 컴파일 하지 않아도 되어서 속도 빠름
  • 단, 통째로 복사하기 때문에 메모리와 디스크 낭비
• 동적 라이브러리 (dynamic library) - dll (win) / lib*.so (linux)
  • 미리 컴파일이 완료된 내용 중, 필수 정보만 실행 파일에 저장됨
    (참조된 동적 라이브러리 이름, 심벌 테이블, 재배치 정보 등)
  • 동적 링크는 두 가지 종류.
    • 실행 파일을 적재(load)할 때
      • 동적 링커(dynamic linker)라는 별도의 프로세스가 실행 됨.
    • 실행 파일이 실행(runtime)될 때
      • 실행 파일을 생성하는 과정에서 실행 파일 내부에 동적 라이브러리 정보가 저장되지 않음.
      • 프로그래머가 코드에 특정 API를 사용해 직접 동적으로 적재.
  • 링크는 결국 실행파일을 생성하는 것이긴 하지만, 동적 라이브러리의 사용 특성 상 실행파일이 '생성'되는 시점에 '동적 링크'가 이루어 진다고 보기는 어려울 듯.
• 동적 라이브러리의 장/단점
  장점
  • 메모리, 디스크 리소스 절약
  • 동적 라이브러리 코드 수정 시, 동적 라이브러리만 다시 컴파일 하면 됨. (실행 파일에는 필수 정보만 저장되어 있기 때문)
  • 플러그인(plug-in)을 구현하는 방법 중 하나.
  • 성능을 위해 프로젝트의 특정 부분을 다른 언어로 개발하고 동적 라이브러리 형태로 사용할 수 있음.
  단점
  • 적재/실행 시간에 링크되기 때문에 성능이 약간 떨어짐
  • 해당 동적 라이브러리를 여러 프로세스가 공유하기 때문에 임의의 메모리 절대 주소로 참조 불가
  • 종속된 동적 라이브러리를 사용할 수 없는 경우(제공x 혹은 버전 호환x) 프로그램 실행 불가.

3. 재배치(relocation)
   실행 파일을 생성하는 과정에 포함.

• 컴파일러가 생성하는 기계 명령어에는 주소값만이 사용되는데, 외부 심벌처럼 컴파일 시점에 주소값을 확정할 수 없는 변수에 대하여 컴파일러는 .relo.text와 .relo.data에 기록해 두고 해당 심벌에 임의의 주소값을 부여.
• 재배치: 각 대상파일을 결합하는 링커가 이 기록을 참고해서 심벌의 메모리 주소를 수정하는 과정.

1.4 컴퓨터 과학에서 추상화가 중요한 이유

추상화는 표현력을 향상해 의사소통의 효율을 높이고, 세부 사항을 감춰 내용을 보호하게 해줌.

• 프로그래밍과 추상화
  모듈 기반의 설계에서는 API라는 추상화가 존재.
  프로그래밍 언어는 추상화를 지원하기 위한 자신만의 mechanism 을 제공. (e.g. OOP의 다형성)

• 시스템 설계와 추상화
  CPU - 명령어 집합
  기계 명령어 - 고급 프로그래밍 언어
  입출력 - 파일
  실행중인 프로그램 - 프로세스
  물리 메모리와 파일 - 가상 메모리
  네트워크 프로그래밍 - 소켓
  프로세스와 프로세스에 종속적인 실행 환경 - 컨테이너
  CPU, 운영 체제, 응용 프로그램 - 가상 머신

추상화 계층은 편리하지만, 고급 프로그래머가 되기 위해선 저수준 계층에 대한 이해가 필요하다.

2.1 운영 체제, 프로세스, 스레드의 근본 이해하기

운영체제

• 프로그램 실행을 위해서는,

  • 프로그램 실행 파일을 적재할 수 있는 적절한 크기의 메모리 영역을 찾고
  • CPU 레지스터를 초기화 하고 함수의 entry point를 찾아 PC 레지스터를 설정해주어야 함.

• 더불어, 여러 프로그램을 동시에 실행 시키기 위해서는 실행 중인 프로그램의 context 정보를 담을 구조체가 필요한데 이를 프로세스(process)라고 함.

이를 사람이 항상 수동으로 하기에는 매우 번거로우므로,

• 프로그램을 자동으로 적재하고 실행 준비를 해주는 도구와
• 여러 프로그램을 동시에 실행(하는 것 처럼) 해줄 수 있는 도구

등을 모아둔 프로그램이 '운영 체제'(operating system).
운영 체제야 말로 코드 재사용성이라는 단어에 가장 적합.

프로세스와 스레드

1. 프로세스는 가상메모리 덕분에 메모리 전체를 독점하는 것 같이 동작하는데, 프로세스 내부에서 메모리 사용을 다음과 같은 부분으로 나눌 수 있음.

   • 코드 영역(code segment) - 기계명령어
   • 데이터 영역(data segment) - 데이터 영역
   • 힙 영역(heap segment) - malloc 사용분
   • 스택 영역(stack segment) - 함수의 런타임 스택

2. 프로세스의 단점은 진입 함수(entry function)가 main 하나로 고정되어 있어 기계명령어를 한 번에 하나의 CPU에서 밖에 실행하지 못한다는 것.

   여러 개의 CPU가 동일한 프로세스의 기계 명령어를 실행하게 할 수는 없을까.

   • 하나의 프로세스에 여러 개의 실행 흐름을 가지도록 할 수 있음.
     각 실행 흐름에 해당하는 entry point를 여러 개의 CPU PC 레지스터에 나누어 지정하면 됨.
     그 실행 흐름 하나를 스레드(thread)라고 함.

   • CPU가 한 개(단일 코어)라도 실행흐름을 교체하면서 마치 동시에 실행되는 것 처럼 동작시킬 수 있음. 스레드는 운영 체제 계층에서 구현되고 코어의 개수와는 무관하기 때문.

   • 여러개의 스레드는 하나의 프로세스에 속하기 때문에 프로세스 메모리 공간을 공유한다는 이점이 있음.
     단, 공유 리소스에 접근할 때 발생할 수 있는 오류를 상호 배제(mutual exclustion)와 동기화(synchronization)을 통해 해결해야 함.

3. 각 스레드 -> 실행 흐름 -> 진입 함수는 함수를 실행하기 위한 각자의 스택 프레임이 필요함.
   즉 스레드가 여러 개라면 스택 프레임도 여러개 필요. 이는 오버헤드로 작용.

   • 스레드가 처리하는 작업은, 수명 주기 관점에서 볼 때 long task 와 short task 가 있음

     • long task: 프로세스의 수명주기와 거의 함께하는 작업. (e.g. Word 프로세스의 디스크 기록 스레드)
     • short task: 요청이 있을 때 마다 짧게 처리하는 작업. 작업 수가 매우 많고 작업 처리 시간이 매우 짧다.

   • long task의 경우 전용 스레드를 생성해 충분히 대응할 수 있지만,
     short task는 스레드 개수가 많아져서 스레드 생성 종료 작업, 각 스레드가 필요한 스택 영역 크기, 스레드 간 전환 부담 등의 부담이 매우 커짐.

   • 그래서 다음과 같은 스레드 관리 전략이 존재.

     • thread-per-request : long task에서 매우 잘 동작
     • thread pool: short task에 적합. 여러 개의 스레드를 미리 생성해 두고, 처리해야할 작업이 생기면 가용한 스레드에 처리 요청.

   • 스레드 풀을 활용하는 방법은 고전적인 producer-consumer 패턴.
     스레드 풀 내의 스레드는 크게 producer-thread 와 consumer-thread로 나뉘어 작업
     작업 자체는 다음과 같은 구조체의 내용.

     	struct task
     	{
     		void* data;
        	handler handle;
     	}

     producer-thread가 처리할 작업을 구조체 형태로 queue에 넣고 ->
     queue에 블로킹 상태로 대기하던 consumer-thread가 이를 처리.

     다수의 스레드가 queue에 접근하기 때문에 당연히 동기화가 필요.
     

   • 스레드 풀의 적절한 스레드 수는 처리하는 작업의 성격에 따라 달라질 수 있는데,
     1. CPU 집약적인 작업: '연산'이 주를 이루는 작업.
     스레드 수와 CPU 코어의 수가 기본적으로 동일하다면 리소스를 충분히 활용 가능
     2. 입출력 집약적인 작업: 연산은 적고 입출력에 시간을 많이 쓰는 작업.
     N개의 코어에 대해 WT(waiting time), CT(computation time) 이라고 하면 N * (1 + WT/CT) 라는 공식.

     하지만 절대 공식은 없다. 상황에 따라 다를 수 있음.

2.2 스레드 간 공유되는 프로세스 리소스

프로세스 리소스는 스레드 간 공유된다.
그렇다면 스레드 전용 리소스는 무엇이 있을까?

• 스레드 전용 리소스 (thread-private resource)

  스레드는 사실 '함수 실행' 이다.
  CPU는 진입 함수에서 실행을 시작해서 하나의 실행 흐름을 생성하는데, 이것이 다름 아닌 스레드.

  결국 스레드 전용 리소스는 함수 실행에 필요한
  스택 영역, 프로그램 카운터, 스택 포인터, 함수 실행 시 사용되는 레지스터 정보
  가 될 수 있고, 이를 스레드 상황 정보 (thread context) 라고 한다.

이 전용 리소스를 제외한 나머지는 모두 스레드 간에 공유되는 리소스.
즉, 프로세스 주소 공간에서 '스택 영역'을 제외한 나머지 영역을 모두 공유한다. (개념적으로는 그렇다)
아래는 모두 공유 리소스.

• 코드 영역
  컴파일 후 생성된 기계명령어가 저장되는 영역.
  코드 영역은 모든 스레드가 공유한다.
  따라서 어떤 함수든지 모두 스레드에 적재하여 실행할 수 있다.
  코드 영역은 read-only 이기 때문에 스레드 안전 문제(thread safety issue)가 발생하지 않는다.
• 데이터 영역
  전역 변수가 저장되는 영역.
  마찬가지로 데이터 영역은 모든 스레드가 공유한다.
  프로그램이 실행되는 동안 전역 변수의 인스턴스는 하나만 존재하기 때문에 변경 사항이 스레드간 공유된다.
• 힙 영역
  런타임에 요청된 메모리가 할당되는 영역.
  어떤 스레드가 할당 받아 사용하더라도 포인터만 얻을 수 있다면 다른 모든 스레드가 해당 영역에 접근할 수 있으므로 공유 리소스이다.
• 스택 영역
  스레드의 각 스택 영역이 자신의 전용 공간이긴 하지만, 엄밀히 말하면 다른 스레드에서 접근이 불가능 한 것은 아니다.
  프로세스의 주소공간은 가상메모리를 통해 서로 격리/보호 되어있다. 하지만 스레드는 이런 작동 방식이 없다.
  어떤 스레드가 다른 스레드의 스택 프레임에서 포인터만 가져올 수 있다면 직접 읽고 쓸 수 있다.
  즉, 하나의 프로세스에 속하는 경우 스레드 간 스택 영역의 데이터를 모두 읽고 쓸 수 있다.
• 동적 링크 라이브러리와 파일
  • 동적 라이브러리의 코드와 데이터는 프로그램을 시작할 때 / 실행 중일 때 프로세스 주소 공간에 저장된다.
    그리고 그것들이 저장되는 공간은 모든 스레드가 공유한다.
  • 프로그램 실행 중 열린 파일에 대한 정보도 프로세스 주소 공간에 저장된다.
    그 공간도 모든 스레드가 공유한다.

마지막으로 특수한 스레드 전용 데이터가 있다. 스레드 전용 저장소 (thread local storage).

• 이 영역에 저장된 변수는 모든 스레드에서 접근 할 수 있지만,
• 스레드 별로 해당 변수들의 인스턴스를 따로 가지고 있어 변수의 변경 사항이 공유되지는 않는다.

__thread int a = 1; // 스레드 전용 저장소

그래서 각각의 스레드에서 독점적으로 변수를 사용할 수 있다.

2.3 스레드 안전 코드는 도대체 어떻게 작성해야 할까?

스레드 안전 (thread safe) 이란 무엇인가

다중 스레드에서 스레드의 개수와 호출 순서에 무관하게 항상 올바른 결과가 출력되는 코드.

어떻게 해야 '스레드 안전'한가?

스레드 공유 리소스의 사용을 유의해야 한다.

즉, 스레드 전용 리소스와 스레드 공유 리소스를 '파악'한 후,

• 전용 리소스는 그 자체로 스레드 안전하기 때문에 사용하고
• 공유 리소스는 상황에 맞게 해결책을 '처방'해 사용한다.

파악

해당 리소스의 '정의'보다는 '사용'을 통해 전용 리소스인지 공유 리소스인지 파악한다.

• 스레드 전용 리소스

  • 함수의 지역 변수, 스레드의 스택 영역, 스레드 전용 저장소

  • 단, 함수 지역 변수라고 해서 무조건 전용 리소스가 아닐 수 있다.

    • 함수 매개변수로 포인터를 받거나, 반환 값으로 정적 지역 변수(static local variable)를 반환하면 사용하는 변수가 데이터 영역이나 힙 영역에 속할 수 있고, 이 상황에서 해당 변수는 공유 리소스가 된다.

• 스레드 공유 리소스

  • 스레드 전용 리소스가 아닌 것. (코드 영역, 데이터 영역, 힙 영역)
  • 코드 영역은 읽기 전용이므로, 스레드 공유 리소스는 힙 영역과 데이터 영역으로 구성된다고 할 수 있다.

처방

가장 먼저, 스레드 간에 어떤 리소스를 공유해야 하는지 고려해보고,
가능한 리소스를 최대한 공유하지 않는 것이 원칙.

공유 리소스를 어쩔 수 없이 사용해야 한다면,

1. 해당 변수를 스레드 전용 저장소 혹은 읽기 전용으로 선언한다.
2. 해당 변수를 변경해야 한다면, 원자성 연산 (atomic operation)을 활용해 리소스 접근 순서를 명시적으로 관리하는 것을 피한다.
3. 그것 마저 어렵다면, 동기화 시 상호 배제 (mutual exclustion in synchronization)을 사용한다.
   • 뮤텍스(mutex), 스핀락(spin lock), 세마포어(semaphore) 등이 존재한다.

2.4 프로그래머는 코루틴을 어떻게 이해해야할까?

코루틴(coroutine)이란

코루틴은 사용자 상태(user mode) 스레드.
자신의 이전 실행 상태를 기억하고 있다가, 다시 실행될 때 이전에 일시 중지되었던 지점(연결 시작 지점)에서 계속 실행이 가능한 함수.

즉, 커널 스레드를 사용하지 않고도 하나의 프로세스에서 여러개의 실행 흐름을 가질 수 있는 방법.

코루틴의 역사

커널 스레드가 없던 시절, 동시성을 가지는 프로그램을 작성하기 위해 고안된 꽤 오래된 기술.

코루틴이 구현되는 방법

스레드의 구현과 본질적으로 차이가 없다.

일시 중지 될때의 상태 정보에는 두 가지

1. CPU의 레지스터 정보
2. 함수 실행 시 상태 정보

일반 함수의 상태 정보는 프로세스 주소 공간 중 '스택 영역' 안 해당 함수의 스택 프레임에 저장되고,
코루틴의 상태 정보는 '힙 영역' 안 해당 코루틴의 스택 프레임에 저장한다.

코루틴의 장점

• 코루틴 간 전환/스케줄링은 전적으로 사용자 상태에서 일어나기 때문에, 운영 체제의 개입이 불필요.
• 코루틴 간 전환 시 저장, 복구 되는 정보 또한 커널 스레드 보다 가볍기 때문에 효율적.
• 동기 방식으로 비동기 프로그래밍을 할 수 있게 해줌 (-> 2.8절)

2.5 콜백 함수를 철저하게 이해한다

콜백 함수 (callback function) 란

다른 코드에 매개변수로 전달되는 실행 가능한 코드.
쉽게 말해, 변수처럼 전달할 수 있는 함수.

콜백 함수가 필요한 이유

// 변수 미사용
int _sum = 10;
_some_func(10);
int _b = 10 + 1;

// 변수 a 사용
int a = 10;
int sum = a;
some_func(a);
int b = a + 1;

코드를 작성할 때, 변수를 사용하면 수정이 용이하다.
만약 변수를 사용하지 않은 부분에서 10을 다른 숫자로 바꾸고 싶을 때, 숫자 10이 사용된 부분을 전부 바꿔야 하지만,
변수 a를 사용한 부분에서는 a의 값만 다른 숫자로 바꿔주면 된다.

함수의 경우도 마찬가지.
함수를 변수처럼 전달할 수 있다면(-> 콜백 함수), 수정을 위해 전달해주는 함수의 내용만 바꿔주면 된다.
또한 콜백을 전달 받는 함수는, 여러 종류의 콜백을 관리할 필요 없이 단순히 전달 받은 콜백을 실행해 주기만 하면 된다.

// 콜백 미사용 (변수 미사용)
void make_donut()
{
	...
    if (TeamA) { form_A();}
    else if (TeamB) { form_B();}
    else if (TeamC) { form_C();}
    ...
}

// 콜백 사용 (변수 사용)
void make_donut(f)
{
	...
    f();
    ...
}

void formed_C() { ... }

make_donut(formed_C);

콜백 함수의 종류

동기 콜백

• 블로킹 콜백 (blocking callback)
• 콜백을 전달한 함수가 콜백 함수 실행 완료를 기다림.
• 하나의 실행흐름에서 콜백 전달, 콜백 실행이 모두 수행됨.

비동기 콜백

• 지연 콜백 (deferred callback)
• 콜백을 전달한 함수(주 프로그램)와 콜백 함수가 동시에 실행될 수 있음.
• 즉, 콜백이 다른 실행 흐름(다른 스레드/프로세스/시스템)에서 실행됨. -> 다중 코어 리소스를 더 잘 활용.

비동기 콜백을 통한 새로운 프로그래밍 사고방식

함수 호출의 기본은,

1. 함수를 호출하고 결과를 획득(request) 한다.
2. 획득한 결과를 처리(handle) 한다.

동기 호출은 그냥 1, 2번을 순차적으로 실행.

res = request();
handle(res);

비동기 호출은 '처리'를 다른 실행 흐름에서 수행한다.
즉, 실제로 결과를 받아 처리하는 과정을 다른 스레드/프로세스/시스템 에서 완료할 수 있다.

request(handle)

문장으로 설명하면,
"우리는 어떤 일을 해야 하는지 알고, 외부 모듈은 언제 해야 하는지 아는 상황에서 사용할 수 있는 것"이 콜백이다.

이는 서드 파티 라이브러리를 사용할 때 유용하다.
서드 파티 라이브러리 작성자는, 특정 시기에 어떤 작업을 수행해야 하는지 알 수 없기 때문.

주로 네트워크 데이터 수신이나 파일 전송 완료와 같은 어떤 이벤트(event)가 발생하는 그 시기만을 알고,
이를 처리하는 코드(handler)가 필요할 때 콜백이 잘 쓰인다.
-> 콜백 함수는 이벤트 중심 프로그래밍(event-driven programming) 에 적합하다.

비동기 콜백의 문제

콜백 지옥(callback hell)

// 동기 콜백
service_a = GetServiceA();
service_b = GetServiceB(service_a);
service_c = GetServiceC(service_b);
service_d = GetServiceD(service_c);

// 비동기 콜백
GetServiceA(function(service_a) {
	GetServiceB(service_a, function(service_b) {
    	GetServiceC(service_b, function(service_c) {
        	GetServiceD(service_c, function(service_d) {
            	...
            });
        });
    });
});

비동기 콜백의 효율성, 동기 콜백의 코드 단순성과 가동성을 동시에 누릴 수 있는 방법? -> 코루틴 (2.8절에서 계속)

2.6 동기와 비동기를 철저하게 이해한다

동기

• 함수의 호출자가 수신자의 실행 결과를 기다려서 결과를 획득하고, 그 이후에 획득한 결과를 처리함.
• 같은 호출자와 수신자가 같은 스레드에서 실행 중인지와는 무관.
  (e.g. 시스템 콜: 호출 스레드가 일시 중지된 후 커널 모드 진입 시 다른 스레드 일 수 있음.)
• 모든 상황에서 실행 결과를 기다리진 않음 (?)

* 전화 통화 - A가 말하면 B가 듣고, B가 다 들으면 A가 다시 말한다.

비동기

• 함수의 호출자가 수신자를 호출한 후 결과를 획득하지 않고 바로 다음 작업을 이어감.
• 수신자의 실행 결과를 처리하는 방법은 크게 두가지
  • 호출자가 실행 결과를 신경쓰지 않을 때 -> 수신자에게 콜백 전달해 수신자가 콜백 실행함으로써 처리
  • 호출자가 실행 결과를 알아야 할 때 -> 수신자가 호출자에게 통지. 통지를 받은 호출자가 처리
• 호출자의 유휴 시간이 줄어들어 효율적.
• 호출자와 수신자가 서로 다른 스레드를 사용하는 것이 일반적.
• 주로 시간이 많이 걸리는 입출력 작업을 백그라운드 형태로 실행.
  (디스크의 파일 읽고 쓰기, 네트워크 데이터 송수신, 데이터베이스 작업 등)

* 이메일 - A가 작성하는 동안 B는 다른 일을 하고, B가 회신하는 동안 A는 다른 일을 한다.

2.7 아 맞다! 블로킹과 논블로킹도 있다

동기 / 비동기

함수 호출 결과의 획득과 처리의 문제.
동기 호출은 획득과 처리에 대하여 '강하게 결합' 되어 있고 '의존적'인 반면, 이런 제약이 없는 것이 비동기 호출.
동기/비동기를 언급할 때는 반드시 두 가지 대상 (caller 와 callee) 양쪽을 모두 의미.

블로킹 / 논블로킹 (blocking / non-blocking)

스레드/프로세스가 함수 호출 시 CPU 제어권을 상실하느냐의 문제.

함수 호출 시 caller 의 스레드/프로세스가 일시 중지 되면 -> 블로킹
그렇지 안고, callee 가 바로 반환되어 caller 스레드/프로세스가 작업을 이어나가면 -> 논블로킹

블로킹

입출력과 밀접한 연관.
입출력은 매우 오래걸리는데, 이 시간이 CPU시점에서는 엄청난 양의 연산을 처리할 수 있는 시간.

따라서 입출력 함수 호출 시

• 결과 획득을 위해 기다리겠다(동기) 라고 하면,
• caller 스레드를 일시정지 시키고 CPU의 제어권을 다른 스레드에 넘겨 CPU 유휴시간을 줄임.

즉, CPU 제어권을 상실했다가 되찾는 시간 동안 스레드/프로세스는 블로킹 되는 것.

운영체제 입장에서 동기 입출력 호출에는 무조건 블로킹으로 대응하는 것이 효율적.
단, 아래와 같은 동기 일반함수 호출에 블로킹으로 대응할 필요는 없음.

int sum(int a, int b)
{
	return a + b;
}

void func()
{
	int r = sum(1, 1);
}

따라서 동기 호출이 무조건 블로킹은 아니지만,
블로킹이면 반드시 동기 호출이라고 할 수 있다.

논블로킹

마찬가지로 입출력 함수 호출 시

• 결과 획득을 위해 기다리지 않겠다(비동기) 라고 하면,

• callee 는 즉시 반환하고 caller 스레드는 CPU 제어권을 유지한 채 기존 작업을 계속 진행함.
  이 때 입출력 과정이 다른 스레드(주로 커널)에서 병행됨으로 효율적.

• 결과 처리를 세 가지 방법이 있는데

  • 입출력 함수와 같이 제공되는, '결과를 확인하는 함수'를 통해 데이터가 들어왔는지를 확인하고 caller 스레드가 처리함.
  • 데이터가 들어왔는지를 알림 작동방식을 통해 caller 스레드에 전달. 전달 받은 caller 스레드가 처리.
  • 입출력 함수 호출 시 콜백 함수를 넘김. callee 스레드가 처리.

이런 유형의 입출력 작업을 비동기 입출력 (asynchronous I/O) 이라고 함.

단, CPU 제어권을 유지(논블로킹) 했다고 해도, 데이터 획득을 위해 caller 스레드가 기다리고 있다면,
이는 논블로킹이더라도 동기 호출임.

즉, 논블로킹이라고 모두 비동기 호출은 아님.
* 비동기 호출이면 논블로킹일 가능성이 매우 높을 듯.

고성능 서버를 위한 기술

[프로세스, 스레드, 코루틴] + [동기, 비동기, 블로킹, 논블로킹] = 고성능 서버

2.8 높은 동시성과 고성능을 갖춘 서버 구현

수천 개 ~ 수만 개의 사용차 요청을 동시에 처리하는 서버의 비밀.

다중 프로세스

process-per-connection

간단하고, 주소공간과 종료에 대해 서로 독립적이고, 다중 코어 리소스 충분히 활용 가능.

하지만, 프로세스간 통신에 비용이 들고, 생성과 종료가 시스템에게 부담.

다중 스레드

thread-per-connection

생성 종료가 가볍고, 주소 공간을 공유해서 통신 비용이 없다.

하지만, 경쟁 상태를 해결하기 위해 프로그래밍 복잡도가 매우 증가하고, 하나의 스레드에 문제가 생겨 종료되면 전체 프로세스가 종료될 수 있는 위험도 있음.

일반적으로는 다중 스레드가 훨씬 더 유리한 경우가 많음.
하지만, 매우 큰 규모의 요청 (C10K 문제 등)에 대해서는 다중 스레드로도 부족. 스레드가 가볍긴 해도 그 수가 매우 많아진다면 마찬가지로 부담이 되기 때문.

이벤트 기반 프로그래밍

'병행' 처리를 위해서 프로세스/스레드에만 의존해야 하는 것은 아니다.
이벤트 기반 프로그래밍 (event-driven programming) 도 사용할 수 있음.
주로 GUI 프로그래밍, 서버 프로그래밍에 널리 사용됨.

이벤트 기반 프로그래밍의 두 가지 필수 요소

1. 이벤트 (event) - 말그대로 이벤트. 서버의 관점에서는 주로 입출력. (데이터 수신 여부, 파일의 read/write 가능 여부 등)
2. 이벤트 핸들러 (event handler) - 이벤트를 처리하는 함수.

계속해서 발생하는 이벤트를 반복(loop)를 통해 계속 수신하고 처리(handle)해야함.
이 반복을 이벤트 루프(event loop) 라고 함.

while (true)
{
	event = getEvent();	// 이벤트 수신 대기
    
    handler(event);		// 이벤트 처리
}

파생되는 두 가지 문제.

1. 이벤트 소스
   getEvent() 하나로 어떻게 여러 이벤트를 가져올 수 있는가.

   • 입출력 다중화 (I/O multiplexing)
     • 모든 입출력은 'file'. 모든 입출력 작업은 file descriptor를 통해. 소켓도 마찬가지.
     • 다수의 소켓에 대해서, file descriptor 를 순차적으로 듣거나, 여러 프로세스/스레드가 하나씩 듣고 있는 것은 비효율적.
     • 여러 개의 소켓 즉 file descriptor 를 대신 듣고 있다가 데이터가 수신되면 반환하는 방식이 입출력 다중화.
     • 이벤트 루프의 '엔진' 역할을 하는 것.
     • 리눅스 세계에서는 epoll 이 대표적.

2. 이벤트 처리
   handler 함수가 꼭 같은 스레드에서 실행되어야 하는가.

   • 리액터 패턴 (reactor pattern)
     • 만약 handler 함수의 동작이 입출력이 없는 매우 짧은 작업이라면, 이벤트 루프와 동일한 스레드에서 실행해도 무방함.
     • 하지만 handler 함수의 동작에 시간이 많이 든다면, 반응성을 위해 다중 스레드를 활용.
     • 이벤트 루프가 실행되는 스레드 하나와 여러 개의 작업자 스레드를 두어서,
       이벤트 수신 시 이벤트 루프 스레드에서 간단한 처리 후 작업자 스레드에 처리 작업을 분배.
     • 스레드 풀 형태로 구현할 수 있음
     • 이런 설계 방법을 리액터 패턴 (reactor pattern)이라고 함.
     • 만약 처리 과정에 블로킹 입출력이 있다면 반드시 해당 작업은 작업자 스레드에 전달해야함.

입출력 다중화와 리액터 패턴을 활용한 프레임워크를 확정하고 나면,
프로그래머는 이벤트 처리 함수 (handler) 구현에 집중하면 됨.

이벤트 처리 함수 구현 시 유의 사항.

handler 함수 하나에 여러 개의 입출력 작업이 필요한 경우가 있음.

예를 들어, 비즈니스에 필요한 기능을 여러 부분으로 나누어 별도의 서버에 배치하는 구조에서, 사용자 요청을 처리하기 위한 handler 함수에 여러 개의 원격 프로시저 호출(remote procedure call: RPC)가 동시에 사용되야 할 수 있음.

이때, 원격 프로시저 호출을 블로킹 호출 또는 비동기 호출을 이용해 호출하게 되면,
CPU 컴퓨팅 리소스를 낭비하거나 코드의 복잡도가 매우 증가하는 부작용이 발생.

비동기 프로그래밍의 효율성과 동기(여기서는 블로킹) 호출의 단순성을 결합할 수 있는 기술
-> 코루틴

코루틴은 본질적으로, 현재 커널 스레드에 할당된 CPU 시간을 사용자 상태에서 2차 할당 하는 것.
즉, "사용자 상태 스레드"이다.
(그리고 사용자 상태 스레드는 커널 스레드보다 가볍고 운영체제의 개입 없이 스케줄링할 수 있다.)

이러한 "사용자 상태 스레드" 하나에다가 실행 흐름으로 handler 함수 하나를 지정한다.
즉, 여러개의 handler 함수를 각각 코루틴으로 실행한다.
구체적인 방법은 아래와 같다.

1. handler 에 RPC 요청들을 단순하게 동기로 작성하되,
2. RPC 호출함수를 약간 수정하여 각 호출에 '연결 시작 시점'을 만들어 둠으로써 RPC 통신이 시작되고 바로 CPU 제어권을 반환할 수 있게 한다.
3. 이렇게 반환된 제어권은 다른 준비된 코루틴을 실행하는데 사용된다.

이렇게 하면 동기 방식으로 구현해 복잡성은 피하고, CPU 컴퓨팅 시간을 낭비하지 않는 비동기 방식의 효율성을 얻을 수 있다.

2.9 컴퓨터 시스템 여행: 데이터, 코드, 콜백, 클로저에서 컨테이너, 가상 머신까지

• 변수: 데이터를 지칭하는 것.

• 함수: 일련의 명령어를 지칭하는 것.

• 일급 객체 함수 (first-class function): 특정 언어에서 코드를 일반 변수처럼 다룰 수 있을 때 이 언어의 함수.

• 콜백 함수: 함수가 다른 함수에 매개변수로 전달될 때. (인자든 반환이든)

• 클로저: 일부 데이터와 콜백 함수를 묶어 변수로 취급한 것.

  • 콜백 함수는 함수를 정의하는 곳과 호출하는 곳이 서로 다름.
  • 호출 할 때, 정의한 곳에서의 데이터를 사용해야 한다면 클로저를 사용하면 됨.

  def add():
  	b = 10	# 콜백을 정의한 곳의 데이터.
    
    def add_inner(x):	# 콜백
    	return x+b
    
    return add_inner
    
  f = add()
  print(f(2))

• 컨테이너: 프로그램과 프로그램이 의존하는 실행 환경을 함께 묶어둔 것.

  • 운영체제를 가상화.
  • 운영 체제 계층 수준에서 소프트웨어 리소스를 가상화.
  • 컨테이너에 포함된 프로세스가 운영체제를 독점하고 있다고 간주하게 함.

• 가상 머신: 가상 머신 감시자에서 실행되는 운영체제.

  • 가상 머신 감시자(하이퍼바이저): 하드웨어 리소스를 추상화 해주는 소프트웨어
  • 가상 머신(운영체제)은 자신이 하드웨어 리소스를 독점한다고 간주함.

3.1 메모리의 본질, 포인터와 참조

변수

변수는 특정 메모리 주소 공간의 별칭.

a = 100

100 이라는 데이터가 '어떤 메모리 주소 공간'에 있을 텐데, 그 공간의 별칭을 a라고 한 것.

만약,

b = a

라고 하면, 100 이라는 데이터를 '다른 메모리 주소 공간' 에 복제하고, 바로 그 공간의 별칭을 b라고 하는 것.

포인터

'메모리 주소 값'을 '어떤 메모리 주소 공간'에 지니고 있으면서, 그 공간의 별칭을 갖고 있는 변수.

참조

어떤 변수가 나타내고 있는 데이터를, 복제하지 않고도 나타낼 수 있는 변수.
포인터는 '메모리 주소 값'을 직접적으로 나타내지만, 참조를 통해서는 메모리 주소 값을 알 수 없음. 그 주소에 담겨있는 데이터만 나타낼 수 있음.

3.2 프로세스는 메모리 안에서 어떤 모습을 하고 있을까?

프로세스의 주소 공간 구조.

• 코드 영역 - 실행 파일 초기화 시에 명령어가 저장되는 곳
• 데이터 영역 - 실행 파일 초기화 시에 데이터가 저장되는 곳
• 힙 영역 - 동적으로 할당된 메모리를 위한 공간
• 스택 영역 - 함수 호출에 사용되는 공간

가상메모리

프로세스가 사용하는 메모리 주소는 실제 물리 메모리 주소와 다르다.
-> 프로세스는 '가상 메모리'를 사용한다.

실제 물리 메모리는 '조각(chunk)' 단위로 관리 되며, 각 조각은 프로세스의 주소 공간 구조 속 영역들의 조각들과 '사상(mapping)' 관계를 지니고 있음. 이 mapping 관계를 저장하는 곳이 페이지 테이블 (page table).

가상 메모리를 통해서 메모리에 접근/조작 하려고 하면, 페이지 테이블을 통해서 가상 메모리가 물리 메모리로 변환되는 과정이 선행되어야 함.

3.3 스택 영역: 함수 호출은 어떻게 구현될까?

함수는 가장 기초적이고 간단한 코드 재사용 방식.
함수 호출은 '호출 안에 또 다른 호출'이 생길 수 있는데, 이 함수 호출 활동을 추적하기 위해 '후입선출(LIFO)'이 가능한 스택(stack) 이라는 자료구조를 사용.

어떤 함수가 실행될 때 사용되는 여러가지 정보를 담아두는 곳을 '스택 프레임(stack frame)' 이라고 함. 이 스택 프레임들이 모여있는 곳이 프로세스의 '스택 영역'.

스택 영역에서 스택 프레임들은 위에서 아래로 자란다.

스택 프레임

어떤 함수를 실행하고 있다는 것은 그 함수가 CPU 제어권을 가지고 있다는 말과 같음.
그래서 어떤 함수의 실행 중에 다른 함수를 호출하게 되면, CPU 제어권이 이전되어야 함.
CPU 제어권이 이전되고, 원래 실행 중이던 함수로 되돌아 오기 위해서 두 가지 정보가 필요함.

1. 반환(return): 어디에서 왔는지에 대한 정보
   • 다른 함수의 호출 시, 기존에 실행되고 있던 함수에서 호출이 발생한 위치를 저장해둔다. 그래야 다른 함수의 호출이 끝나고 원래 명령어로 복귀할 수 있기 때문.
     실행 중이던 함수의 스택 프레임의 가장 끝에 저장해둔다. (스택의 최상단, 메모리 공간에서는 최하단)
2. 점프(jump): 어디로 가는지에 대한 정보
   • 또 다른 함수를 호출 할때, 그 함수 명령어가(구체적으로는 명령어의 시작이) 어디에 있는지 대한 정보.
     호출 시 call 명령어의 인자로, 기존 실행 중이던 함수 명령어에 이미 작성되어있다.

매개변수, 반환값, 지역변수 들은 지정된 레지스터에 저장하거나, 레지스터의 개수가 모자라면 실행 중인 함수의 스택 프레임에 저장해둔다.
심지어는 실행 중인 함수가 사용 중이던 레지스터 값들이 다른 함수의 호출로 덮어씌워지지 않도록, 기존 실행 함수의 레지스터 초기값들은 그 함수의 스택 프레임 최하단 (메모리 공간에서는 최상단)에 저장해 둔다.

최종적으로 한 함수의 스택프레임은 하단->상단의 순서로 아래와 같이 저장된다.
레지스터 초기값 | 지역 변수 | 추가 매개변수들 | 반환 주소

3.4 힙 영역: 메모리의 동적 할당은 어떻게 구현될까?

스택 프레임에 저장된 정보는, 해당 함수의 호출이 완료되면 무효화(invalidation) 됨.
따라서 함수 반환 이후에는 그 스택 프레임에 저장되었던 정보를 사용하면 안됨.

만약 특정 데이터를 여러 함수에 거쳐서 사용하고 싶다면?
-> 메모리의 수명 주기가 스택 프레임에 따라 결정되는 것이 아니라,
프로그래머에 의해 결정되는 메모리 영역 인 힙 영역(heap segment) 을 사용.

이 힙 영역에 메모리를 할당하고 해제해 주는 작은 프로그램이 C/C++ 에서는 malloc 메모리 할당자.
링크 과정에서 자동으로 링크되는 C 표준 라이브러리에 포함되어 있음.

나만의 메모리 할당자

원리의 이해를 위해 나만의 malloc 메모리 할당자를 구현해보자.

다음의 두 가지 함수를 구현하면 된다.

1. malloc: 메모리 할당 요청. 사용자가 메모리 할당을 요청하면 힙 영역에서 가능한 메모리를 찾아 반환해줌.
2. free: 메모리 해제 요청. 사용자가 메모리의 사용을 완료하고 메모리 영역을 반환했을 때.

그리고 다음의 두 가지가 메모리 할당자의 성능에 대한 지표.

1. 속도: 요청된 크기의 메모리 영역을 얼마나 빨리 힙 영역에서 찾아서 반환해줄 수 있는지
2. 활용도: 정해진 힙 영역의 한도 내에서 얼마나 많은 메모리 할당 요청을 만족할 수 있는지

구현을 할 때는 아래의 4가지 문제에 대한 답을 찾아 나가면 된다.

1. 힙 영역에서 현재 어떤 메모리 조각이 할당 가능한 상태인가?
   • 힙 영역을 어떻게든 '구조화' 해야 어떤 영역이 가용한 상태인지를 추적할 수 있다.
2. 할당 가능한 메모리 조각이 여러개라면, 어떤 조각에 할당해야 할까?
3. 요청받은 크기의 메모리를 메모리 조각에 할당 후, 그 메모리 조각에 남은 잉여 부분은 어떻게 해야할까?
4. 사용자로 부터 반환된 메모리를 어떻게 처리해야 할까?

1번 : 메모리 조각의 할당 상태 추적

연결리스트(linked list)를 활용한다.
단, 연결리스트를 따로 관리하는 것은 또 다른 메모리 공간이 필요하다는 뜻이므로,
힙 영역 자체가 하나의 커다란 연결리스트가 될 수 있도록 관리한다. 각 메모리 조각이 연결리스트의 각 노드가 된다.

각 메모리 조각에 헤더(header) 정보를 두어서,

• 메모리 조각의 크기가 얼마인지
• 할당이 된 상태인지

를 저장해두면, 할당 상태도 알 수 있고 크기를 통해 다음 메모리 조각의 헤더에도 접근할 수 있다.
이런 식으로 힙 영역 전체를 하나의 연결리스트로 구조화해 메모리 조각들의 할당 상태를 추적한다.

2번 : 할당 전략

1. first-fit: 연결리스트의 앞 부분부터 차례로 할당 할 수 있는 메모리 조각이 있는지 확인.
   • 시간이 지날 수록 앞 부분에 작은 조각들이 남게됨. 그래서 탐색 시간이 증가될 수 있음.
2. next-fit: 바로 직전에 할당된 조각의 위치부터 시작해 할당 가능한 메모리 조각이 있는지 확인.
   • 이론적으로 탐색 시간이 빠르다고 하지만, 메모리 사용률은 first-fit에 미치지 못한 다는 것이 밝혀짐.
3. best-fit: 모든 메모리 조각을 확인해서 요청에 적합한 가장 작은 메모리 조각에 할당.
   • 탐색 시간이 가장 오래 걸림. 메모리 사용률은 가장 좋음.

상황에 맞게 비교/선택 해서 사용해야 함. 정답은 없다.

3번 : 여유 메모리 조각 처리

할당 시, 요청에 적합한 대부분의 메모리 조각이 요청 받은 크기보다 크기 때문에 여유 부분이 생김. 잉여 부분을 무시한다면 이는 내부 단편화(fragmentation)가 발생.

그래서 보통 여유 메모리를 또다른 메모리 조각으로 만들어서 활용함.

4번 : 반환받은 메모리 처리

free 요청을 받은 메모리는 헤더 정보를 수정하고, '병합' 해야 함.
병합하지 않으면 작은 메모리 조각을 계속 분리되어 그것보다 큰 메모리 요청에 대응할 수 없음.

단, 병합 시기를 '반환 즉시' 또는 '필요 시(요청에 적합한 메모리 조각이 없을 때)' 둘 중 하나로 선택 가능. 반환 즉시 병합은 구현이 매우 단순하지만, 실제의 메모리 할당자는 대부분 필요 시 병합할 수 있도록 일종의 연기 전략을 가지고 있음.

또한 힙 영역을 헤더 정보로만 관리하여 단방향 연결 리스트로 구조화 하면, 병합 시 해당 메모리 조각의 앞에 있는 메모리 조각과 병합하기가 어려움. 따라서 메모리 조각에 footer 를 두고 헤더와 같은 정보를 저장해 둠으로써, 암시적인 양방향 연결 리스트(doubly linked list)로 힙 영역을 관리하도록 함.

👉 여기까지 메모리 할당자의 가장 기본적인 원리를 구현한 메모리 할당자 구현 시뮬레이션.
실제로는 최적화 할 곳이 매우 많으며 스레드 안전 문제도 있다는 사실을 잊으면 안된다.

3.5 메모리를 할당할 때 저수준 계층에서 일어나는 일

x86 CPU는 네 가지의 privilege level을 제공함: 0, 1, 2, 3 (숫자가 작을 수록 privilege가 커짐)
동심원 모양으로 표현되는 경우가 많아 protect ring 이라고 불리고, 0단계를 보통 ring 0 라고 함.

일반적으로 시스템은 CPU 0단계와 3단계 만을 사용. (1, 2 단계는 시동 준비 프로그램 실행 시 사용)
0단계 (ring 0) 는 커널 모드(kernel mode), 3단계는 유저 모드(user mode) 라고 부른다.

• 커널 모드는 CPU가 운영 체제 코드를 실행 할 때의 상태이다.
  모든 주소공간에 접근 가능하고, 모든 하드웨어에 접근 가능하다.

• 유저 모드는 CPU가 사용자 프로그램을 실행 할 때의 상태이다.
  크게 생각해서 운영 체제 이외의 모든 코드가 유저 상태에서 실행된 다고 보아도 무방하다.

  • 특정 주소 공간 (주로 커널 주소 공간)에 접근 불가능하다. 접근 시 segmentation fault.
  • 특정 명령어를 사용할 수 없다. 즉, ring 0 상태에서만 사용 가능한 기계 명령어를 사용할 수 없다.

그래서 사용자 프로그램이 파일 입출력, 네트워크 입출력과 같은 운영체제의 서비스를 사용해야 할 때
시스템 콜(system call) 이라는 작동 방식을 활용한다.
운영 체제가 프로그래머를 위해서, 운영 체제에 어떤 서비스를 요청할 수 있는 코드를 미리 제공해 주는 것이다.

이런 시스템 콜은 당연히 운영 체제와 매우 밀접한 연관이 있고, 운영 체제 별로 그 인터페이스가 다 다르다.
이 차이를 감추고 추상화하기 위해 프로그래밍 언어의 표준 라이브러리(standard library)가 존재한다.
시스템 콜을 사용할 수 있는 코드를 운영체제 별로 미리 작성해두어서 제공하는 것.

결국 전체 시스템 모습은 다음과 같은 구조가 된다.
응용 프로그램 - 표준 라이브러리 - 운영 체제 - 하드 웨어
malloc 과 같은 메모리 할당자도 사실 표준 라이브러리에 속해 있는 코드이다.

힙 영역의 증가

malloc 과 같은 요청 시 힙 영역의 남은 메모리가 부족하다면, brk 라는 시스템 호출을 통해 추가 메모리를 요구해야 한다. brk는 힙 영역의 최상단을 의미하는 프로세스가 가진 변수이면서, 힙 영역 증가를 요청하는 시스템 호출의 이름이기도 하다.

실제로 이렇게 추가 메모리가 할당되더라도 바로 물리 메모리가 할당되는 것이 아닌, 가상 메모리로서만 할당된다.
그렇게 할당된 가상메모리를 프로세스가 실제로 사용하려고 하면 물리 메모리가 할당 되어 있지 않기 때문에 page fault가 발생하는데, 이 때가 되서야 운영 체제는 해당 가상 메모리와 실제 물리 메모리와의 사상 관계를 설정함으로써 물리 메모리를 할당한다.

3.6 고성능 서버의 메모리 풀은 어떻게 구현될까?

malloc 은 매우 범용적인 메모리 할당 방법으로서 모든 상황에 사용할 수 있는 대신 시스템 성능에 영향을 줄 수 있다.
범용성이 매우 떨어지지만 즉, 특정 상황에 대해서만 사용할 수 있게 구현되었지만 높은 성능을 발휘할 수 있는 메모리 할당 방법이 있을까? -> 메모리 풀 (memory pool)

메모리 풀

한 번에 큰 메모리 조각을 요청한 후, 그것을 pool로 관리하면서 메모리 할당과 해제를 하는 방식.

• 서버 요청에서 단 한 종류의 객체만 사용한다면, 메모리 풀에 그 객체를 여러개 만들어 두고 하나씩 꺼내 쓰고 반환하는 방식도 가능.
• 여러 종류의 객체 즉, 여러 크기의 메모리 할당 요청에 대응해야 한다면, 메모리 풀 내의 메모리 조각들을 연결리스트로 관리해 여유 메모리 조각을 추적할 필요가 있다.
  • 가장 처음에 받은 큰 메모리 조각을 쪼개서 사용한다. 포인터를 사용해 현재 여유 메모리 조각의 위치를 기억한다.
  • 이렇게 사용하다가 부족하다면, malloc을 통해 새로운 메모리 조각을 할당 받아 이전 조각과 링크로 연결한다. 즉 새로 받은 큰 메모리 조각을 연결리스트(메모리 풀)에 추가한다. 단, 새로운 조각은 이전 조각의 크기의 2배로 요청한다. malloc 을 너무 빈번하게 요청하지 않기 위함이다.
• 스레드 안전 문제에 대해서는 각 스레드가 각자의 메모리 풀을 관리하도록 한다.
  스레드 전용 저장소(thread local storage)를 활용한다.

3.7 대표적인 메모리 관련 버그

1. 지역 변수의 포인터 반환하기
   • 당연히 문제가 된다. 스택 프레임은 함수가 반환되면 다른 값으로 덮어씌워질 수 있기 때문.
2. 포인터 연산의 잘못된 이해
   • 포인터 연산은 1을 더하면 자동으로 해당 자료형 크기 만큼의 다음 주소로 이동한다. 일부러 자료형 크기 만큼을 더해줄 필요가 없다.
3. 문제 있는 포인터 역참조 하기
   • int a; scanf("%d", a); 라고 하면 잘못된 사용. scanf함수는 두번째 인자로 주소 값을 받는다.
4. 초기화되지 않은 메모리 읽기
   • malloc 으로 할당 받은 메모리가 무조건 0으로 초기화 되어있지는 않음. 이미 한 번 사용되고 반환된 주소에는 쓰레기값이 남아 있을 수 있기 때문에 수동으로 초기화 해주어야 함.
5. 이미 해제된 메모리 참조
   • 당연히 문제가 된다. 해당 주소가 다른 값으로 덮어씌워질 수 있음.
6. 배열의 인덱스는 0부터 시작.
   • int* arr = (int*)malloc(n * sizeof(int)) 라고 할당 받았을 때 가능한 인덱싱은 arr[0] 부터 arr[n-1]까지임. arr[n] 에 쓰게되면 문제가 될 수 있음.
7. stack overflow
   • C언어의 gets 함수는 인자로 전달받은 버퍼의 크기를 모르기 때문에, 해당 버퍼의 시작 주소부터 임의의 크기의 메모리를 사용하게 될 수도 있음. 버퍼가 지역변수라면 스택프레임에 위치하고 그 버퍼의 크기가 스택 프레임을 넘어서면 문제 발생. 버퍼가 스택 프레임 내에서 사용 가능한 크기를 넘어 스택 프레임의 반환 주소를 건드리도록 하여 악성 코드를 실행 시키는 공격 방식도 있음.
   • 즉, 지역변수가 스택 프레임의 크기를 초과하면서 사용되면 문제가 발생할 수 있음.
8. memory leak
   • int p = malloc(); return; 해버리면 해당 메모리는 프로세스 종료까지 해제할 방법이 없음.
   • 이런 식의 누수가 누적되서 힙 영역이 점점 늘어나게 되고 운영체제가 프로세스를 강제 종료시킬 수도 있음.
   • 사용 중인 언어나 메모리 할당자를 대상으로 하는 메모리 분석기를 활용하면 메모리 누수를 방지할 수 있다.
     • 첫 번째 메모리 분석기의 종류는 malloc 과 free 의 사용을 추적하는 방식. 하지만 프로그램 실행 속도를 저하시키기도 하고, 디버그 모드로 다시 컴파일 해야 하는 불편함.
     • 두 번째 종류는 page fault 의 빈도를 추적하는 것. page fault는 아직 가상-물리 간의 mapping이 이루어지지 않았을 때도 발생하지만, 실제로는 메모리가 부족해 swap이 많이 일어나는 상황에서 많이 발생함. 그래서 리눅스의 perf 같은 도구를 활용해 이 page fault에 대응하는 시스템 이벤트를 발생시킨 함수 호출 스택 정보를 추적해 볼 수 있음.

3.8 왜 SSD는 메모리로 사용할 수 없을까?

0. 속도
   SSD(Solid State Drive)의 스펙을 확인해보면 sequential reading speed 가 최대 7.5GB/s.
   이것도 매우 빠르지만 메모리는 더 빠름 -> 60GB/s.

1. 메모리 읽기/쓰기 와 디스크 읽기/쓰기의 차이
   바이트 vs 블록
   메모리의 주소 지정 단위는 바이트. 각 바이트 마다 메모리 주소가 부여되어 있고, CPU는 이 주소로 직접 접근 가능.
   디스크의 블록(block) 단위로 데이터를 관리. CPU가 특정 바이트에 직접 접근이 불가하고 그에 따라 디스크로 직접 프로그램 실행이 불가.

2. 가상메모리의 제한
   32비트 시스템의 최대 주소 범위는 4GB. 1TB 크기의 SSD를 메모리로 쓰더라도 프로세스는 4GB 이상은 사용 불가.
   단 64비트 시스템은 이 제한에 대해 예외이긴 함.

3. SSD 사용 수명 문제
   SSD는 수명이 존재. 마치 자동차의 주행거리와 같은 지표가 SSD에서는 TBW(TeraBytes Written).
   일반적으로 흔히 사용되는 SSD의 TBW는 대략 수백 TB 수준.
   SSD를 메모리로 사용한다면 CPU는 대량의 메모리 읽기 쓰기작업을 실행하기 때문에 수명 문제 생길 수 있음.
   SSD를 디스크와 같이 일반적으로 사용한다면 빈번하게 대량의 데이터를 쓸 일이 많지 않으므로 수명 문제는 거의 없음.

종합적으로 봤을 때, 저장장치 제조 기술의 한계로, 하드웨어 소프트웨어 부문 둘 다 SSD를 메모리로 사용하는 상황을 고려하지 않고 있음.

4.1 이 작은 장난감을 CPU라고 부른다

CPU는 결국 수십억 개의 스위치(개폐장치)로 이루어진 장치.
트랜지스터가 바로 그 스위치 역할.

논리 회로

위에서 언급한 트랜지스터를 가지고 다음의 세 가지 회로를 만들 수 있음.

1. 논리곱 게이트(AND gate): 두 개의 스위치가 모두 켜져야 전류가 흐름.

2. 논리합 게이트(OR gate): 두 스위치 중 하나라도 켜져있으면 전류가 흐름.

3. 논리부정 게이트(NOT gate): 스위치가 켜져있으면 전류가 흐르지 않고, 꺼져있으면 전류가 흐름.

그리고 이 세가지 회로를 가지고 있으면 어떤 논리 함수도 구현이 가능하다. -> 논리적 완전성

이 논리적 완전성을 토대로 3가지의 기본 회로를 조합하여 회로를 만들었을 때, 회로는 아래 두 가지의 기능을 지닐 수 있다.

연산 능력

결과와 자리 올림수를 계산할 수 있는 회로 조합을 만들면 된다.

결과는 배타적 논리합(XOR) 게이트를 사용하고, 자리 올림수는 논리곱(AND) 게이트를 사용하면 된다.

논리적 완전성이 있기 때문에 다른 연산을 위한 회로 또한 유사한 원리로 만들어 낼 수 있다.

CPU에서 이런 산술연산을 처리할 수 있는 회로를 가진 모듈이 바로 ALU(Arithmetic Logic Unit) 이다.

저장 능력

되먹임(feedback) 회로를 이용해서, 회로에 어떤 action을 가해주면 해당 action에 대응되는 출력이 계속 유지되도록 할 수 있다.
즉, 한 번 action을 가해주면 그 action이 유지되지 않더라도 출력이 회로에 저장된 것처럼 유지된다.

S-R Flip Flop (혹은 latch)

Set-Reset Flip Flop. latch는 걸쇠, 자물쇠 라는 뜻.
(https://www.youtube.com/watch?v=Hi7rK0hZnfc -> 3분 55초부터 책의 예시와 동일)

Set 회로에 action을 가해주면 1 출력이 유지된다.
그리고 Reset 회로에 action을 가해주면, 0 출력이 유지된다.

action을 가한다는 것은 입력으로 0 또는 1을 넣는 다는 뜻이다.
이는 Active-Low 인지 Active-High 인지에 따라 다른데, 여기에서 active는 action이 가해졌을 때의 상태.

• Active-Low 이면 action이 0에 해당한다는 뜻. 즉 no-action은 1, 전류가 흐르는 상태이다.
• Active-High 이면 action이 1에 해당한다는 뜻. 즉 no-action은 0, 전류가 흐르지 않는 상태이다.

책의 예시는 Active-Low 인 S-R Flip Flop이다.
Active-High 인 S-R Flip Flop 은 배타적 논리합(XOR) 게이트로 구성되고,
Active-Low 인 S-R Flip Flop 은 부정 논리곱(NAND) 게이트로 구성된다.

어쨌든 이러한 원리로 회로에 정보를 '저장'해둘 수 있다.
그리고 이 회로 구성 여러개를 조합해서 레지스터를 만들 수 있고,
거기에 8비트에 1바이트라는 단위를 붙여 각 단위에 주소를 지정하면 메모리를 만들 수 있다.

이 회로에 저장된 정보는 전류가 끊기면 사라진다.
전원이 끊긴 후 S-R 각 회로가 non-Active한 상태로 돌아오는 시점에서의 출력은 0 또는 1로 확정될 수 없기 때문이다. (invalid)

하드웨어와 소프트웨어의 접점

이러한 논리 연산은 하드웨어의 기능이다. 즉, 하드웨어의 기능은 고정되어 있다.
변할 수 있는 것은 소프트웨어. '어떤 것을 연산'할 것인가를 소프트웨어가 정하면 된다.

즉, CPU는 '연산 능력'을 제공하고, 프로그래머가 '피연산자'를 제공하면 된다.

이 둘의 인터페이스는 '명령어 집합'이 담당한다.
명령어 집합(instruction set)은 CPU가 실행할 수 있는 명령어(opcode)와 명령어에 필요한 피연산자(operand)를 묶은 것. 서로 다른 종류의 CPU는 서로 다른 명령어 집합을 가진다.

예를 들어 다음의 16비트 짜리 기계 명령어가 있다고 하면,

15 14 13 12 | 11 10 09 | 08 07 06 | 05 04 03 | 02 01 00
0  0  0  1  | 1  1  0  |  0  1  0 |  0  0  0 |  1  1  0
    ADD     |    R6    |    R2    |          |    R6

처음 4비트가 명령어 집합에 속하는 영역이다.
즉, 이 예시에서는 명령어 집합이 2^4=16 개의 기계 명령를 포함하고 있을 것이다.

고급 프로그래밍 언어가 컴파일 되면, 이렇게 해당 CPU가 가지는 명령어 집합으로 이루어진 기계 명령어가 되는 것이다.

CPU: central processing unit

회로의 연산 능력, 저장 능력, 그리고 그 회로에 어떤 연산을 수행해야 하는지 알려줄 수 있는 명령어 집합.
하지만 각 회로가 함께 작업할 수 있게 조정/동기화 할 수 있는 기능이 있어야 정상적으로 동작 할 수 있다.
이것이 바로 CPU의 clock signal 이다.

클럭 신호가 전압을 변경할 때 마다 전체 회로의 각 레지스터, 즉 전체 회로 상태가 갱신된다.
이렇게 전체 회로를 동기화 한 후에 작업을 실행하기를 반복한다.

클럭 주파수(clock rate)는 이 클럭 신호가 1초에 몇 번 발생하는지를 의미한다.
클럭 주파수가 높을 수록 CPU가 1초에 더 작업을 수행할 수 있는 것이다.

이렇게 해서,

• 산술 논리 장치 (연산)
• 레지스터 (저장)
• 클럭 신호 (제어)

를 한 데 갖춘 장비를 중앙 처리 장치: CPU 라고 부른다.

4.2 CPU는 유휴 상태일 때 무엇을 할까?

실제 컴퓨터의 CPU 사용량은 생각보다 높지 않다.

운영 체제는 여러 프로세스를 스케줄링 하기 위해 각 프로세스에 우선 순위를 매기고 대기열을 통해 관리하는데, 이 대기열이 비어있을 때, 즉 CPU를 사용할 프로세스가 없을 때를 유휴 상태라고 한다.

설계의 편의를 위해 이 '유휴 상태를 수행하는' 프로세스가 하나 존재한다. 이를 유휴 작업이라고 하자. 이 유휴 작업은 언제나 준비상태로, 그리고 가장 낮은 우선순위로 대기열에 항상 존재한다.
즉, 스케줄러는 대기열에 스케줄링할 다른 프로세스가 없을 때 이 유휴 프로세스를 스케줄하게 된다.

halt

결국 이 유휴 작업은 halt 라는 기계 명령어를 루프안에서 계속 실행하는 작업과 같다.

halt는 CPU를 절전 상태로 전환해주는 기계 명령어로, 특권 명령어이기 때문에 커널 상태에서만 실행 가능하다.
sleep 과 같이 해당 프로세스만을 일시중지(suspend) 하는 명령어와는 다르다. halt는 더 이상 CPU가 실행할 준비 완료된 프로세스가 없을 때 실행된다.

실제로 컴퓨터 입장에서 가장 많이 실행하는 명령어는 halt 명령어일 것이다.

인터럽트

위와 같이 halt가 루프 안에서 계속 실행될 때, 어떻게 빠져나올 수 있을까.

컴퓨터에서 일정 시간마다 타이머 인터럽트(timer interrupt)가 발생하는데, 이를 처리하는 과정에서 빠져나올 수 있다. 루프에서 빠져나올 기회를 지속적으로 주는 것이다.

타이머 인터럽트를 CPU가 인식하고, CPU는 운영체제 내부에 등록된 인터럽트 처리 함수를 실행한다. 이 함수는 지금 준비 완료된 프로세스가 있는지 확인해서 있다면 준비 완료된 프로세스를 실행하고, 아니라면 유휴 프로세스를 계속 실행한다.

4.3 CPU는 숫자를 어떻게 인식할까?

2진법을 사용한다.
CPU는 트랜지스터, 즉 켜고 끄는 스위치로 구성되어 있기 때문.

• unsigned integer
  • 부호가 없는 0과 양의 정수들. 8개의 비트로 표현 가능한 unsigned integer는 0 ~ 255.
• signed integer
  • 부호가 있는 0과 정수들. 표현 가능한 경우의 수를 반으로 나누어 양수와 음수에 배분한다.
    4개의 비트가 있다면, 총 표현 가능한 16개의 경우의 수를 1 ~ 7, -1 ~ -7, 0, -0 로 나누는 식.
    (혹은 1 ~ 7, -1 ~ -8, 0)
  • 최상위 비트(most significant bit)에 부호를 표시한다.
    0***** 양수
1***** 음수
  • 음수에 대하여 최상위 비트를 제외하고 다른 비트를 어떻게 표현할 것인가에 대한 문제가 남음. 3가지 방법이 존재.

<용어>

보수(補數)는 보충을 해주는 수를 의미한다.
이를테면 1에 대한 10의 보수는 9, 4에 대한 15의 보수는 11의 개념이다. 1에 대한 2의 보수는 1이다.

1의 보수는 영어로 ones' complement 이다. 여러개의 1에 대한 보수라는 의미.
2의 보수는 2의 거듭 제곱에 대한 보수라는 의미.

sign-magnitude

부호 비트만 붙이고 나머지는 양수와 동일한 비트로 표현하는 것.

예를 들면,
0010 이 2 이고,
1010 이 -2 인 것.

하지만 0에 대해 -0 이 생기는 문제. (0000, 1000)

1의 보수 (ones' complement)

양수 표현에서 모든 비트를 반전 시키는 것.
즉 비트의 개수 만큼 채워진 1에 대한 보수. (11111111에 대한 보수)

예를 들면,
0010 이 2 이고,
1101 이 -2 이다.

하지만 마찬가지로 0에 대해 -0이 생기는 문제. (0000, 1111)

2의 보수 (two's complement)

• 부호 비트만 붙이거나 1의 보수를 사용하는 방법은 다음과 같은 문제점이 있다.

  • 0이 2개 생기는 복잡성
  • (1의 보수) 덧셈 시 오버플로우 발생하면 추가로 1을 더해주어야 함 (end-around-carry)
    • -0 + 1 = 1 이어야 하지만
      1111 + 0001 = 0000, 즉 0이 된다.

• 결국, 양수와 음수의 관계라는 것은

  $A + -A = 0$

  를 만족하는 관계라고 볼 수 있기 때문에,
  이를 만족하면서도 0 을 표현하는 방법은 0000 하나인 표현 방법을 찾아야 하는 것.

  방법은 양수에 음수를 더했을 때 딱맞게 오버플로우가 발생하도록 하면 된다.
  비트가 4개라고 하면 0001 + 1111 = (1)0000가 "딱맞게 오버플로우"가 발생하는 상황이고, 결과는 0이다.

  • 000 (0)
  • 001 (1)+ 111 (-1) = (1)000 = 0
  • 010 (2) + 110 (-2) = (1)000 = 0
  • 011 (3) + 101 (-3) = (1)000 = 0
  • 100 (-4)
    (000 과 100 은 자기 자신을 제외하고는 딱맞는 오버플로우 (1)000 를 만들 상대가 없다.)

이렇게 자리 올림수만 무시하면 가산기가 부호에 전혀 신경 쓰지않고 계산을 수행할 수 있다.

• 2의 보수를 구하는 직접적인 방법은 다음과 같다. (4개의 비트를 사용하는 상황을 가정한다.)
  {x + x에대한2의보수} = {10000} 을 만족하면 된다.
  그런데,
  {(x + x에대한1의보수) + 1} = {(1111) + 1}
  {x + (x에대한1의보수 + 1)} = {10000} 이다.

  결론적으로 2의 보수를 구하는 방법은, 1의 보수를 구하고 그 결과에 1을 더하면 된다.
  (1의 보수는 x의 모든 비트를 반전시킨 결과와 동일하다.)

• 현대 컴퓨터가 2의 보수 표현 방식을 사용하는 근본적인 이유는,
  이것이 사람에게 직관적이지 않을 수는 있어도 "회로 설계를 단순화"할 수 있게하기 때문.

  2(0010)와 -2(1110)를 더할 때 가산기는 이들이 양수인지 음수인지 전혀 신경쓰지 않는다.
  근본적으로 0010과 1110 이라는 표현/상태/숫자나열 이 어떤 의미를 갖는지 조차 이해하지 못한다. 그저 두 비트의 배타적 논리합(XOR) 연산이 덧셈의 결과이고, 논리곱(AND)이 자리 올림수라는 것만 알고 수행할 뿐이다.

  이는 지극히 단순한 연산작업만을 계속해서 수행하는 하드웨어의 동작이다.
  해석하고 의미를 부여하는 것은 "소프트웨어"의 영역이다.

4.4 CPU가 if문을 만났을 때

파이프라인 (pipeline)

작업의 처리 과정을 순서가 있는 여러 단계로 나눈 다음,

• 각 단계에서 다음 단계로 넘어가는 흐름과
• 지속적인 입력

을 통해 전체적인 처리 능력을 높이는 것. 단, 작업 단위 당 처리시간은 동일하다.

예를 들어, 자동차 공장에서 자동차 한 대가 완성되는 데에 80분이 걸린다고 하자. 생산 과정을 단 하나의 팀이 맡아서 처리한다고 하면 여전히 80분에 1대가 생산되지만, 생산 과정을 4단계로 나누어 각 단계에서 처리한 결과를 다음 단계로 쉬지않고 넘기면 결과적으로 20분에 1대가 생산될 수 있으므로 80분에 4대를 생산해낼 수 있다. 하지만 자동차 '한 대'가 완성되는 데에 걸리는 시간은 여전히 80분이다.

CPU가 사용하는 파이프라인

CPU 또한 파이프라인을 이용해서 기계 명령어의 처리 능력을 높인다.

하나의 기계 명령어 처리를 위해서 다음의 4단계가 존재한다.

1. 명령어 인출 (instruction fetch: IF)
2. 명령어 해독 (instruction decode: ID)
3. 실행 (execute: EX)
4. 다시 쓰기 (write back: WB)

각 단계는 별도의 하드웨어로 처리된다.

if 가 파이프라인을 만나면

if 문은 일반적으로 컴파일러가 '조건부 점프 명령어'로 변환한다.
조건이 참이면 점프하고, 거짓이라면 순차적으로 실행된다.

그런데 문제는 이 '조건부 점프 명령어'가 '실행' 되어야 점프 여부를 결정할 수 있고, 파이프라인에 어떤 명령어를 넣을지를 결정할 수 있다는 것이다. 만약 조건부 점프 명령어가 실행될 때 까지 파이프라인에 명령어를 넣지 않는다면 프로세서의 리소스를 낭비하는 꼴이 된다.

그래서 조건부 점프 명령어의 실행 결과를 알기 전, 파이프라인에 어떤 명령어를 넣어주어야 할지를 결정하기 위해 CPU는 분기 예측 (branch prediction) 을 한다. 이 예측을 통해 분기 결과 도출 전 파이프라인에 예상 명령어를 미리 넣어두고, 예상이 맞았다면 그대로 실행을, 틀렸다면 잘못된 분기 명령어를 모두 무효화 한다. 결국 분기 예측에 실패하면 성능 저하가 발생하는 것.

현대의 CPU 분기 예측은 굉장히 발달되어 있긴 하나, 높은 성능을 요구하는 코드에 if문이 있다면 CPU가 분기 예측에 성공할 확률이 높도록 코드를 작성해야 할 필요가 있다. C++의 likely/unlikely 매크로는 이런 이유에서 존재 하며, 컴파일러에 가능성이 더 높은 분기를 알려준다.

CPU의 구현 원리를 이해하는 것으로 CPU를 더 잘 활용하는 코드를 짤 수 있다.

4.5 CPU 코어 수와 스레드 수 사이의 관계는 무엇일까?

CPU 코어 수와 스레드 수 사이에는 어떤 필연 관계도 없다.

하드웨어는 지극히 단순한 연산작업만을 계속해서 수행할 뿐이다.
해석하고 의미를 부여하는 것은 "소프트웨어"의 영역이다.

• CPU는 하드웨어로, PC카운터 주소에 따라 메모리에 있는 명령어를 꺼내 실행할 뿐이다. 스레드의 존재를 알지 못하고 알 필요도 없다.
• 스레드는 소프트웨어이고, 정확하게는 "실행 흐름"이자 "작업"이다. 프로그래머가 소프트웨어적으로 의미를 부여하고 해석한 결과로서 존재한다. 추상적인 작업의 단위이고, 이를 관리하는 것은 더 큰 소프트웨어인 운영체제이다.

단일 코어든 다중 코어든 프로그램의 필요에 따라 스레드를 얼마든지 많이 만들어서 사용할 수 있다.
다만,

• 스레드들의 작업이 입출력/동기화 같은 작업이 필요하지 않은 '순수한 계산' 위주라면
  -> 코어당 스레드 하나가 가장 좋은 선택이고,
• 스레드에 블로킹 입출력이 존재한다면
  -> 그 작업을 분할하여 스케줄링 한다는 의미로 스레드를 더 만들어 사용하는 것이 좋을 것이다.

스레드의 수가 너무 많아질 경우 스레드 간 전환하는 부담이 증가하는 것을 유의해야 한다.

코어당 스레드의 개수는 단순히 수치화 하기가 어렵고 실제로 프로그램을 사용하여 상황에 따라 지속적으로 테스트해야 한다.

4.6/4.7/4.8 CPU 진화론

복잡 명령어 집합의 탄생

CPU가 하는 일은 메모리에서 명령어를 읽어 실행하는 것 뿐.
그렇다면 CPU의 '능력 범위'는 결국 '어떤 명령어를 실행할 수 있는지'와 같다고 볼 수 있음.
이를 명령어 집합(instruction set)이라고 부른다.

명령어 집합에 대해 기억해야할 사실.

• 명령어 집합은 결국 프로그래머가 프로그래밍 할 때 사용되었음.
  • 최초의 프로그램은 CPU에 대응하는 어셈블리어로 작성됨.
• 서로 다른 형태의 CPU는 서로 다른 유형의 명령어 집합을 가지고 있음.
  • 명령어 집합의 형태와 CPU 하드웨어의 설계는 아주 밀접하게 연관되어있기 때문.

가장 처음으로 등장한 CISC(Complex Instruction Set Computer)부터 살펴보자.
(x86 구조는 이 CISC에 기초를 두고있다)

CISC

"복잡 명령어 집합", 즉 CISC의 탄생이 필연적이었던 이유.

1. 프로그램 작성의 편리함을 위해
   • 1970년까지는 컴파일러가 성숙하지 못해, 프로그래머가 어셈블리어로 프로그램을 작성하는 경우가 많았다.
   • 이는 명령어 집합이 풍부하고, 명령어 자체 기능이 강력해야 한다는 생각으로 이어졌다.
     • 명령어 집합이 '매우 적거나', 명령어 자체 기능이 '단순'한 것과 반대.
   • 이를 컴퓨터 과학자들은 '의미상 간격(semantic gap)'을 이어주는 것이라고 말했다.
     • 함수 호출, 순환 제어 등의 고급 프로그래밍 언어의 개념과 이에 직접 대응하는 기계 명령어가 있어야 한다는 것.
   • 즉, 명령어 집합이 고급 프로그래밍 언어처럼 '추상화된' 형태로 존재해야할 필요가 있었다.
   • 즉, 프로그래밍의 단순함을 위해 명령어 집합의 구현이 '복잡(complex)'할 필요가 있었다.
2. 코드의 저장공간 절약을 위해
   • '폰 노이만 구조' 에서는 "실행 파일이 기계 명령어와 데이터를 모두 포함"하고 있고, 이는 디스크에 저장되었다가 메모리에 적재되어 실행된다. 즉, 기계 명령어가 메모리의 공간을 차지한다.
   • 1970년대에는 메모리의 크기가 수KB ~ 수십KB 에 불과했다.
   • 그래서 기계 명령어를 반드시 매우 세밀하게 설계해서 프로그램이 차지하는 저장공간을 줄여야 했고, 이는 다음과 같은 특성으로 이어졌다.
     • 단일 명령어 : 하나의 기계 명령어로 더 많은 작업을 완료할 수 있음.
     • 가변 길이 명령어: 기계 명령어 길이가 고정되어 있지 않음. 공간의 낭비를 줄일 수 있음.
     • 고도로 인코딩된 명령어: 공간을 절약할 수 있음.

더불어, 마이크로코드(microcode) 라는 소프트웨어를 CPU 설계에 도입했다.

이 시기 CPU 명령어 집합은 모두 'hardwired' 되어 있었다. IF, ID, EX 등 각 단계가 특정 조합 회로로 직접 제어되는 것.
이는 명령어 실행에는 매우 효율적이나 유연성이 매우 떨어져 명령어 수정에는 대응하기 힘들었음.

그래서, 명령어 집합의 공통되는 연산을 정의해둔 작은 프로그램을 정의해서 이를 CPU에 저장해둠으로써 모든 기계 명령어에 대해 전용 회로 설계를 하지 않도록 함.
복잡한 하드웨어 변경 대신, 비교적 쉬운 소프트웨어 변경을 통해 명령어 집합의 변경에 대응하도록 한 것.

하지만 이러한 마이크로코드는,

• 버그 수정이 프로그램의 버그 수정보다 훨씬 어려웠고,
• 트랜지스터를 매우 많이 소모했다.

-> 새로운 설계에 대한 필요가 대두되었음.

축소 명령어 집합의 탄생

CISC 는 한정된 자원의 시대에 적응한 결과로 탄생한 것.
시간이 지나면서 메모리와 컴파일러 기술이 발전했고, 복잡 명령어의 내부의 복잡성(명령어가 실제로 수행하는 작업의 복잡성)의 비효율 그리고 마이크로코드의 비효율이 점차 부각됨.

RISC

"축소 명령어 집합"의 탄생. 그것이 가지는 특성

1. 명령어의 복잡성을 줄임

• 여기서 계속 말하는 명령어의 복잡성은 명령어 뒷단에서 이루어지는 작업의 복잡성을 의미함.
• 복잡한 명령어 하나 대신, 간단한 명령어 여러 개로 같은 작업을 수행하겠다는 것.
• 하나의 명령어당 들여야 하는 연산이 더 간단하다는 의미.

2. 컴파일러

• 복잡 명령어 집합에서는 마이크로코드의 정보를 컴파일러가 인지하지 못함.
• 축소 명령어 집합에서는 마이크로코드 없이 CPU의 세부사항을 컴파일러에 제공함으로써,
• 컴파일러가 CPU에 대해 더 강력한 제어권을 가지고 최적화를 할 수 있음.

3. LOAD / STORE 구조

• 복잡 명령어 집합에서는 하나의 명령어로 메모리 접근과 함께 IF, EX, WB 단계를 모두 수행할 수 있었음.
• 축소 명령어 집합에서는 기본적으로 명령어는 레지스터 내의 데이터만 처리할 수 있고,
• LOAD / STORE 같은 전용 기계 명령어만 메모리의 읽기 쓰기를 담당함.

예를 들어 각각 메모리 주소 A, B에 저장된 두 숫자를 곱하는 작업을 해야 한다고 하면,

복잡 명령어 집합은

MULT A B

하나로 메모리 접근부터 연산까지 모두 수행할 수 있다.

반면, 축소 명령어 집합은

LOAD RA, A
LOAD RB, B
PROD RA, RB
STORE A, RA

이런 식으로 메모리 접근과 연산의 단계를 간단한 명령어들을 사용하여 단계별로 작성해주어야 한다.

복잡 명령어 집합은 명령어 사이에 비교적 차이가 커서 실행 시간이 고르지 않다. -> 파이프라인 방식 활용 어려움.
하지만 축소 명령어 집합처럼 간단한 명령어 여러개를 사용해서 작업을 풀어쓰면, 각 명령어가 매우 간단하기 때문에 실행 시간이 모두 거의 동일해질 수 있다. -> 파이프라인 기술을 도입하기 아주 좋음.

개선된 복잡 명령어 집합

CISC 진영에서 단점을 개선.

1. 마이크로 명령어 (micro-operation)

• CISC의 명령어를 인터페이스로 활용해, CPU 내부에서 명령어를 RISC 명령어 변환. 잘게 쪼개는 것.
• 이렇게하면 쪼개진 명령어들이 RISC처럼 간단해지고, 각 명령어의 실행 시간이 고르게 되고, 파이프라인 기술 활용할 수 있음.

2. 하이퍼스레딩 (hyper-threading)

• CPU가 제공하는 스레드. 하드웨어 스레드.
• 물리 CPU 코어가 하나라고 해도, 운영 체제는 논리적으로 CPU 코어가 여러개 있는 것으로 인식할 수 있다.
• 실제 파이프라인 기술은 명령어간 종속성으로 인해 항상 완벽하게 채워진 상태일 수는 없다. 필연적으로 빈 공간이 발생하고, 이 틈에 새로운 명령어 흐름(스레드)을 끼워넣어 실행함으로써 리소스를 활용하는 것.
• 잊지 말아야 할 점은, 소프트웨어 스레드의 관리 주체는 운영 체제이고, 하드웨어 스레드(하이퍼스레딩)은 CPU 하드웨어의 기능으로 운영 체제와 무관.

두 진영은 서로 장점은 취하고 약점은 보완하면서 끊임 없이 발전 중.
CISC는 점점 RISC 명령어에 가까워 지고 있고, 일부 고성능 RISC도 마이크로명령어를 채택하고 있음.
다만 아직도 분명한 차이가 존재하는데,

1. RISC에서 컴파일러는 아직도 중요한 역할. 명령어의 길이가 정해져있는 RISC는 가변 길이인 CISC에 비해 컴파일러 최적화에 이점이 있음.
2. 메모리 접근 시 아직도 RISC는 LOAD / STORE 구조이고, CISC는 이런 구조가 없음.

지금까지는 기술적 관점. 상업적 관점에서의 두 진영의 대결 또한 존재.

• x86으로 대표되는 CISC의 대표주자는 intel과 AMD.
  • 기술적으로는 RISC가 우세했더라도, CISC는 소프트웨어 생태계라는 훌륭한 기반을 가지고 있었음. 이미 많은 수의 훌륭한 소프트웨어가 x86 플랫폼에서 동작하고 있었기 때문.
  • 동시에 RISC에서 여러 가지 우수한 사상들을 흡수하여 발전했음.
  • 윈텔(윈도우 + 인텔)이 이를 번영시켜 데스크탑, 서버 시장 점령에 성공.
• RISC의 대표주자는 ARM.
  • 아이폰 출시와 함께 본격적인 모바일 시대.
  • 오랫동안 독점적인 위치를 가진 윈텔 진영은 변화에 반응하는 데에 너무 큰 관성이 발생.
  • ARM이 기회를 얻어 스마트폰 프로세서는 RISC의 진영이 독점하게 됨.
  • 애플은 자체 개발한 모바일 프로세서 설계 능력과 이를 통해 얻은 데스크탑 프로세서 설계 능력으로 M1 칩을 개발하기에 이르는데, 이 칩이 RISC의 ARM을 기반으로 하고 있음.
• 두 기술은 아직도 공존, 경쟁, 발전 중.

4.9 CPU, 스택과 함수 호출, 시스템 호출, 스레드 전환, 인터럽트 처리 통달하기

context

레지스터는 속도가 매우 빠름. 대신 제조 비용이 비싸서 용량에 한계가 있음.
프로그램 실행 시 필요한 모든 정보를 메모리에 저장하되 CPU가 사용할 때만 레지스터에 임시로 데이터를 보관.
프로그램 실행 시, 특정 시점에서 레지스터에 저장된 모든 정보를 일반적으로 '상황 정보'(context) 라고 함.

아래는 프로그램 실행을 위해 사용되는 대표적인 레지스터들 -> 즉 context

1. 스택 포인터

• 함수 실행 시 스택 프레임들이 쌓이는 런타임 스택의 상단의 주소가 저장됨.
• 스택 프레임: 함수 실행 시 함수에 정의된 지역 변수와 전달된 매개변수 등을 저장하는 독립적인 메모리 공간.

2. 프로그램 카운터

• PC: program counter 혹은 x86에서 IP: instruction pointer 라고 부름.
• CPU가 지금 당장 실행할 명령어의 주소가 PC에 저장됨. 프로그램이 실행되면 첫 번째로 실행할 명령어의 주소가 PC에 저장되는 것.
• 명령어가 순차적으로 적혀있기에 PC또한 순차적으로 증가하지만, 분기 점프(if문), 함수 호출과 반환 같은 명령어 실행 시 새로운 명령어 주소가 PC에 저장됨.

3. 상태 레지스터 (status register)

• x86 에서는 FLAGS 레지스터, ARM 에서는 application program status register 라고 부름.
• 산술 연산 시 발생하는 carry(자리 올림수) 혹은 오버플로우 발생 정보를 저장.
• CPU의 user mode, kernel mode 상태를 표시하는 비트를 저장. 이를 변경하면 CPU의 동작 상태가 변경됨.

이러한 context 를 가지고 있으면 프로그램 실행을 일시 정지하고 재개하는 것이 가능함.
CPU는 다음과 같은 4가지 상황에서 불가피하게 '순차적인 흐름' 에서 벗어나게 되고, 이 때 context의 저장과 복원이 필요함.

• 함수 실행
• 시스템 콜
• 인터럽트 처리
• 스레드 전환

저장과 복원

위 4가지 상황의 구현은 CPU context의 저장/복원이 필수적이고 이는 스택과 같은 구조로 완성된다.

중첩 구조에는 스택 (stack)이 가장 적합하다.
└ (A를 실행하는 과정에서 B를 실행해야 하는 상황)
스택은 일종의 매커니즘일 뿐이므로, 이를 소프트웨어로 구현하든 하드웨어로 구현하든 상관 없음.

그렇다면 각 기능은 어떻게 context를 저장/복원 하고 있을까.

1. 함수 실행

   • 함수 실행을 위해선
     1. 호출된 함수의 첫 번째 명령어로 "점프" 해야 하고,
     2. 호출된 함수의 실행이 완료되면 다시 원래 위치로 "점프"해야 함을 기억.
   • 결국 이는 기존에 실행하던 함수의 context를 저장/복원 해야 한다는 의미.
   • 스택 프레임이라는 곳에 context 로서 반환 주소, 사용한 레지스터 정보 등을 저장하고 나중에 이를 이용해 context를 복원한다.
   • 이 스택 프레임들이 쌓여서 런타임 스택을 만든다.
   • 즉, 함수 호출을 위해서는 런타임 스택이 필요하다.

   정리하면,

   1. 함수가 호출될 때,
   2. CPU의 user mode 혹은 kernel mode의 변화 없이,
   3. 실행 중인 런타임 스택에 (구체적으로는 런타임 스택 안 현재 실행 함수의 스택 프레임에), 반환 주소, 사용한 레지스터 정보 등의 context를 저장하고,
   4. 실행 중인 런타임 스택을 사용해 호출 함수를 실행한 후,
   5. 호출 함수가 실행 완료되면 context를 복원하여 이전 함수 실행이 재개된다.

2. 시스템 콜

   • 시스템 콜 처리를 완료하기 위해서는 운영체제 또한 이 요청을 처리하는 '함수를 호출' 해야 함을 기억.
   • 함수를 호출을 위해서는 런타임 스택이 필요하다. -> 커널 스택

   정리하면,

   1. 유저 프로그램이 시스템 콜을 호출할 때 (대응 되는 명령어, x86 에서는 INT 가 실행될 때),
   2. CPU가 user mode에서 kernel mode 로 전환되고,
   3. 사용자 프로그램에 대응하는 커널 스레드의 커널 스택에, 사용자 프로그램이 사용하고 있던 레지스터 정보와 같은 context를 저장하고,
   4. 커널 스택을 사용해 시스템 호출 처리 함수를 실행한 후,
   5. 함수 실행이 완료되면 context를 복원하여 user mode 복귀, 사용자 프로그램이 재개된다.

3. 인터럽트 처리

   • 인터럽트는 시스템 콜과 달리 외부 장치로 실행되기 때문에, CPU가 사용자 상태에서 명령어 수행 시 언제든지 인터럽트가 발생할 수 있음을 기억.
   • 인터럽트 또한 운영 체제가 이를 처리할 수 있는 함수를 실행해야 한다.
     인터럽트 처리 함수에 interrupt service routine(ISR) 스택이라는 자체 런타임 스택이 있는 경우가 있는데, 이 경우 인터럽트 처리 함수는 ISR 스택에서 실행됨. 아니라면 커널 스택에서.

   정리하면, (커널 스택 사용 시)

   1. 언제든 인터럽트가 발생할 때,
   2. CPU가 user mode에서 kernel mode로 전환되고,
   3. 사용자 프로그램에 대응하는 커널 스레드의 커널 스택에 context를 저장하고,
   4. 커널 스택을 사용해 인터럽트 처리 함수를 실행한 후,
   5. 함수 실행이 완료되면 context를 복원하여 user mode 복귀, 사용자 프로그램이 재개된다.

4. 스레드 전환

   • 스레드 전환은 시스템 내부의 타이머가 발생시키는 인터럽트로 이루어짐을 기억.
   • 인터럽트 발생 시, 커널 안의 타이머 인터럽트 처리 프로그램을 실행해서 현재 실행 중인 스레드가 가진 시간이 남았는지를 확인하고 남은 시간이 없다면 다른 스레드로 전환하게 됨.
   • 스레드 전환에는 1) 주소 공간을 전환하는 것, 2) CPU의 작업을 전환하는 것: context를 교체하는 것. 이 포함된다.
   • 모든 리눅스 스레드에는 process descriptor 로 task_struct가 존재하고, 그 안에 thread_struct가 해당 스레드의 CPU context를 저장하는 역할.

   정리하면,

   1. 타이머 인터럽트가 발생할 때,
   2. CPU가 user mode에서 kernel mode로 전환되고,
   3. 사용자 프로그램에 대응하는 커널 스레드의 커널 스택에 사용자 프로그램의 현재 context를 저장하고,
   4. 커널 스택을 사용해 타이머 인터럽트 처리 프로그램을 실행해 스레드 전환이 필요하다면,
   5. 커널 스레드의 task_struct -> thread_struct 에 context를 저장하고,
   6. 전환할 스레드의 context를 task_struct -> thread_struct 에서 읽어 CPU에 복원하고,
   7. user mode로 복귀해 전환된 스레드에 해당하는 사용자 프로그램이 재개된다.

5.1 캐시, 어디에나 존재하는 것

CPU ~ 메모리

폰 노이만 구조에서, CPU가 실행하는 기계 명령어와 그 명령어가 사용하는 데이터가 모두 메모리에 저장되어있어야 한다.
다시 말해, CPU는 빈번하게 메모리에 접근해 명령어와 데이터를 가져와야 하고, 실행 결과를 메모리에 기록해야 한다.

문제는 속도.
CPU의 연산속도보다 메모리의 접근 속도가 훨씬 느리다. 이러면 CPU의 빠른 연산을 충분히 활용할 수 없다.

해결은 CPU가 직접 메모리를 읽고 쓰지 않도록 하는 것. 중간에 캐시 계층을 둔다.

• 캐시는 CPU가 사용가능할 만큼 속도가 매우 빠르지만 용량이 제한되어 있다.
• 캐시 안에는 최근에 메모리에서 얻은 데이터가 저장된다.
• CPU는 명령어/데이터를 꺼내와야 할 때 캐시를 먼저 조회해서 적중하면 메모리에 접근하지 않는다.
• 이렇게 CPU는 메모리에 직접 읽고 쓰지 않음으로써 메모리와의 속도 차이를 보완한다.

x86 아키텍처에서는 L1, L2, L3 의 캐시 계층이 있다.

• 왼쪽부터 용량이 작은 순서 그리고 CPU와 가까운 순서이다.
• L1은 4클럭, L2는 10클럭, L3는 50클럭 정도의 주기가 소요된다.
• L1, L2, L3 그리고 CPU 코어는 레지스터 칩 내에 묶여 패키징되어있다.
• 오늘날 CPU 칩에서 상당 부분의 공간을 캐시가 차지한다.

이렇게 캐시 계층을 두면 데이터 조회 성능이 개선되지만, 데이터 기록 시에는 갱신 문제가 발생한다.

1. 캐시의 데이터와 메모리의 데이터가 inconsistent(불일치)하는 경우가 생기는 것이다.
   해결 방식은 동기식 설계와 비동기식 설계가 있다.

   • 동기식 - write-through : 캐시를 갱신할 때 메모리도 갱신하는 방법. 불필요한 대기시간 발생.
   • 비동기식 - write-back : 일단 캐시만 갱신하고, 용량 부족으로 캐시가 해제될 때가 되면 그 캐시에 발생했던 수정사항을 메모리에 갱신.

2. 다중 코어의 경우, 캐시-메모리 간의 갱신 뿐만 아니라 각 프로세서 캐시들 간의 일관성도 유지되어야 한다.
   최신 CPU에는 고전적인 MESI protocol 같은 것으로 다중 코어의 캐시 일관성을 유지한다. 물론 규칙 적용을 위해서는 성능에 대가가 따른다.

메모리 ~ 디스크

메모리와 디스크 간의 속도 차이도 존재한다. 메모리 접근 속도는 디스크 탐색 속도보다 10만배 가량 빠르다.

따라서 메모리 자체를 디스크의 캐시로 사용한다.
(따로 계층을 추가하지 않는 이유는 메모리의 용량이 캐시로 작용하기에 충분하기 때문)

일반적으로 메모리의 사용률은 100%에 도달하지 않기 때문에, 여유 공간을 디스크를 위한 캐시로 활용한다. 이것이 리눅스에서 '페이지 캐시'의 기본 원리.

여기에도 당연히 '갱신 문제' 즉 inconsistency 문제가 발생한다. 이를 위해 여러 입출력 라이브러리들은 sync, flush 같은 함수를 제공함으로써 inconsistency가 발생하기 전에 미리 데이터를 갱신할 방법을 제공한다.

메모리의 가격이 저렴해지면서, 서버에서는 메모리가 디스크를 대체하는 흐름이 있다.
(AWS 에서 2TB 짜리 메모리를 제공하는 instance를 제공)
하지만 이는 "용량 때문에 디스크에 의존해야 했던 상황"을 해결한 것이고, 영속성에 대한 의존은 남아있기 때문에 완전한 대체는 불가능하다.

가상메모리에서 swap-in/out 은 디스크를 일종의 '창고'처럼 활용하는 방법.

결국 CPU가 메모리에서 데이터를 읽는 방법은 아래와 같이 정리가 가능하다.

1. 가상 메모리 주소를 실제 물리 주소로 변환.
2. L1, L2, L3 캐시를 검색해서 찾았다면 바로 반환.
3. 못찾았다면 메모리에서 찾아서 반환.
4. 메모리에서도 못찾고 디스크로 swap-out 된 상태이면 디스크에 접근해서 다시 메모리로 적재. 그걸 반환.

디스크 ~ 분산 파일 시스템

분산 파일 시스템 (distributed file system)
대용량 데이터 저장 문제를 해결하는 방법 중 하나로, 데이터를 여러 장치에 나누어 저장하는 것.

원격으로 저장되는 경우에, 원격 분산 파일 시스템에서 전송된 데이터를 로컬 디스크가 저장함.
이때 로컬 디스크를 '원격 분산 파일 시스템의 캐시'로 볼 수 있음.

더불어, 원격 분산 파일 시스템의 데이터를 data stream 의 형태로 로컬 컴퓨터의 메모리에 끌어올 수도 있음. (apache kafka)
이때는 메모리가 '원격 분산 파일 시스템의 캐시'로 간주됨.

결론: 컴퓨터의 저장 체계의 각 계층이 다음 계층에 대한 캐시 역할을 한다.
단, 각 계층의 저장 용량은 다음 계층의 저장 용량보다 작아야 한다.
(그렇지 않으면 그 계층으로 다음 계층을 대체하면 되기 때문)

이러한 결론을 토대로, 컴퓨터 전체 저장 체계가 최대의 성능을 발휘하기 위해선 캐시 친화적인 프로그램을 작성하는 것이 매우 중요.

5.2 어떻게 캐시 친화적인 프로그램을 작성할까?

어떤 프로그램이 캐시 친화적이라는 것은, 그 프로그램의 캐시의 적중률이 높다는 것이다.

locality (지역성)

( locality of reference / principle of locality )

프로그램이 "매우 규칙적으로" 메모리에 접근하는 경향성이 있다는 것.

• temporal locality : 특정 메모리 조각을 여러번 참조하는 경향. (시간적 지역성)
• spatial locality : 참조한 메모리에 인접한 메모리를 참조하는 경향. (공간적 지역성)

이러한 경향성은 캐시 친화적이다. 왜냐하면,

• 한번 참조해서 캐시에 남아있는 데이터는 계속 적중될 수 있고, -> temporal locality
• 일반적으로 요청한 메모리의 인접 데이터도 함께 캐시에 저장되기 때문. -> spatial locality

즉, 컴퓨터 프로그램 자체는 어느 정도 기본적으로 캐시 친화적이다.
그래서 이런 지역성이 극대화될 수 있도록 프로그램을 작성하는 것이 곧 캐시 친화적인 프로그램을 작성하는 것이다.
이를 토대로, 캐시 친화적인 프로그래밍 원칙 몇 가지.

1. 메모리 풀 사용.

   • malloc과 달리, 메모리 풀은 커다란 메모리 조각을 한 번에 할당받아서 나눠쓴다. 결국 그 커다란 메모리 조각을 할당 받는 것이 곧 연속적인 메모리 공간을 할당 받는 것.
   • spatial locality가 우수하다.

2. struct 구조체 최적화.

   • 같이 빈번하게 사용되는 멤버들을 서로 인접하게 배치하는 것으로 spatial locality를 높일 수 있다.
   • 빈번하게 접근하는 데이터를 'hot data', 거의 접근하지 않는 데이터를 'cold data'라고 할 때
     • hot data와 cold data를 서로 분리하면 더 나은 지역성을 얻을 수 있다.
     • 예를 들어, 구조체 멤버로 잘 접근하지 않는 큰 배열이 있다면 포인터만 멤버로 갖고 배열 자체는 구조체와 분리하는 것.

3. 데이터 구조

   • 순전히 지역성의 관점에서 보면, 배열이 연결 리스트보다 낫다.
   • 배열은 하나의 연속된 공간에 할당되는 반면, 연결 리스트는 일반적으로 각 노드들이 메모리에 흩어져있을 가능성이 높기 때문.
   • 연결 리스트를 직접 정의한 메모리 풀에서 구성한다면 단점 보완 가능.

4. 코드 탐색 패턴

   • 다차원 배열이 있을 때 '행 우선 방식'으로 데이터가 메모리에 저장된다면,
     (첫 번째 행의 모든 데이터를 쭉 저장하고 그 다음 두 번째 행의 모든 데이터를 저장하는 형식)
   • 이중 반복문에서 바깥 반복문이 '행 순회', 안쪽 반복문이 '열 순회' 일때 캐시 적중률이 높을 것.
     (순회 기준이 반대라면 캐시 적중률이 매우 떨어질 것.)
   • 캐시의 용량은 한정되어 있고, 인접한 메모리를 캐시에 저장하게 될 것이기 때문.
   • 결론은 코드 탐색 패턴의 약간의 차이만 생겨도 캐시 적중률의 차이가 현저할 수 있다.

이 원칙을 적용할 때 중요한 점은,
캐시 적중률로 인한 병목이 있을 때만 이런 최적화를 진행하라는 것.

5.3 다중 스레드 성능 방해자

프로그램이 가지는 spatial locality 에 따라,
접근하고자 하는 데이터와 인접한 데이터까지 '묶음'으로 캐시에 저장하는 것이 캐시 친화적이다. 이 '묶음'을 캐시 라인(cache line) 이라고 한다.

캐시 라인의 크기는 일반적으로 64바이트이며, 캐시가 적중하지 못할 경우 그 데이터가 속한 캐시 라인이 캐시에 저장된다.

하지만 캐시 라인 단위의 상호작용은 다중 스레드에서 성능을 방해하는 요인이 되기도 한다.

1. 일단 캐시 라인과 무관하게,
   다중 코어를 사용하는 다중 스레드가 하나의 데이터를 공유한다면, 코어 별로 캐시를 가지고 있으므로 캐시 일관성을 위해 한 쪽이 데이터를 변경할 때 다른 한 쪽의 캐시를 무효화(invalidation)해야 한다.
   이는 결국 서로가 서로의 캐시를 끊임없이 무효화 하는 현상으로 이어지고, 이러한 현상을 일컬어 "cache line bouncing" 또는 "cache ping-pong" 이라고 한다. 이 현상이 발생하면 캐시 본연의 기능을 활용하지 못하고 전체 흐름이 방해되면서 프로그램 성능이 크게 저하된다.

2. 특히, 다중 코어를 사용하는 다중 스레드가, 같은 데이터가 아니라 "서로 다르지만 같은 캐시 라인에 있는 데이터"에 각각 쓰기를 하려고 하더라도 cache line bouncing 현상이 발생한다.
   즉, 데이터를 공유하지 않더라도 캐시 라인을 공유하면 문제가 된다. 왜냐하면 캐시 일관성을 유지하는 입장에서 캐시 안에 다른 코어와 공유하고 있는 데이터가 있고, (해당 코어가 사용하지 않는 데이터라고 하더라도) 그 데이터에 수정이 발생했다면 동기화 해주는 것이 안전하기 때문. 이는 "false sharing"이라고 하고, 이 또한 cache line bouncing 문제를 야기한다.
   해결법은 false sharing 하고 있는 데이터들이 같은 캐시 라인(64Bytes)에 속하지 않도록 데이터에 padding을 주는 것. 구조체를 예로 들면 멤버 순서를 바꾸거나 중간에 배열을 끼워넣는 식.

결국 다중 스레드 프로그램에 병목이 발생했을 때,
생각해 보아야 할 것이 이 cache line bouncing 현상.

여러 스레드가 같은 데이터를 공유하는 상황(1번)은 캐시 일관성으로 인한 성능 저하가 발생할 가능성이 자명해보이는 반면, 캐시 라인을 공유하는 상황(2번)은 예상하기 힘들 수 있다. 그래서 조심해야 한다.

1. 일단 스레드 간의 데이터 공유를 최대한 피하고
2. 그럼에도 false share 문제가 남아있는지 확인해야 한다.

5.4 봉화희제후와 메모리 장벽

어떤 CPU 설계에서는 성능 향상을 위해, 명령어가 항상 순서대로 실행되지 않기도 한다.
이를 "비순차적 명령어 실행: OoOE(Out of Order Execution)" 이라고 한다.

크게 세 가지 경우가 있는데,

1. 컴파일러가 최적화를 위해 명령어 순서를 변경하는 것
2. 명령어 실행 시 CPU가 명령어 파이프 라인의 빈공간(slot)을 메우기 위해 명령어 실행 순서를 변경하는 것
   • 명령어가 의존하는 피연산자를 기다리는 동안(예를 들어 메모리에서 레지스터로 가져오기) 파이프 라인이 비어있을 수 있음. 이 공간을 이미 준비 완료된 명령어로 먼저 채우는 것.
3. 캐시 일관성 문제 때문에 어떤 코어의 명령어가 다른 코어에서 봤을 때 순서대로 실행되어 보이지 않는 것
   • CPU와 캐시 사이에 store buffer 가 존재하는 설계가 있음.

CPU 설계는 허술하지 않기 때문에, 당연히 명령어가 실행되는 해당 스레드 내부에서는 이런 비순차적 실행이 보이지 않는다. 하지만 자신 이외에 또 다른 스레드(코어)가 자신과 공유하고 있는 데이터에 접근할 때는, 이 비순차적 실행 과정이 드러날 수 있다.

물론, lock 을 획득하여 동기화를 하면 문제 없다. 다만 "lock-free programming"을 시도할 때가 문제가 된다.
lock-free programming 이란 다중 스레드의 공유 리소스 사용 시 실제로는 lock 없이도 처리가 가능하긴 하기 때문에 특정 원리(e.g. 원자성 작업)를 활용해서 lock 사용을 회피하는 것이다.

이렇게 lock 이 없는 상황에서 OoOE 문제를 해결하기 위해 사용하는 것이 바로 메모리 장벽, 즉 memory barrier 이다.

memory barrier 는 구체적인 기계 명령어를 의미하는 것으로, 4가지가 있다.
메모리 관련 작업에는 LOAD 와 STORE 가 있는데, 각 memory barrier 이름에 명시된 명령어의 순서를 해치지 말라고 명시해두는 기계 명령어이다.
좀 더 쉽게 말하면 ****???? 라는 형태의 memory barrier 가 있을 때, 이 memory barrier를 기준으로 앞에 존재하는 ****명령어들과 뒤에 존재하는 ????명령어들이 이 memory barrier를 넘어서 서로 재정렬 되지 않도록 명시해 두는 것이다.

1. LOADLOAD
2. STORESTORE
3. LOADSTORE
   • 비교적 오래 걸리는 STORE가 LOAD보다 먼저 실행될 경우가 있을까 싶지만, 캐시 미스 시에 가능하다고 한다.
4. STORELOAD
   • 네 가지 memory barrier 중 가장 '무겁다'. 문자 그대로 "이 memory barrier 이전에 존재하는 쓰기가 완료되기 전까지 memory barrier 이후의 읽기를 하지 못한다"는 의미이기 때문이다.

예를 들어 3번 LOADSTORE 명령어의 사용 예는 다음과 같다.

bool flag;	// 스레드 간 공유되는 전역 변수

void some_thread()
{
    int important;
    
	if (flag)
    {
    	LOADSTORE_FENCE();
        
    	important = 100;
    }
}

이렇게 하면, flag 가 반드시 true 가 된 시점 이후에만 important 에 100 이 STORE 되도록 보장할 수 있다. (memory barrier 없다면 비순차적 실행으로 인해 먼저 STORE 될 수도 있다는 뜻.)

이러한 memory barrier 들은 LOAD와 STORE 명령어를 특정해 순서를 보장하고 있어서, 각 memory barrier를 '조합'해 사용해야 할 경우가 많다. (e.g. LOAD 명령어 뒤에 있는 LOAD 와 STORE 명령어의 비순차적 실행을 방지하기 위해선 LOADLOAD 와 LOADSTORE 를 동시에 사용해야 함)
-> 이를 해소하기 위해 "acquire-release semantics" 를 사용.

acquire-release semantics

공식적으로 존재하는 개념은 아님.
memory barrier의 조합.

1. acquire
   • 읽기 작업 관련 (LOAD)
   • barrier에 해당하는 LOAD 명령어 이후에 있는 모든 메모리 명령어가 barrier 이전으로 재정렬 되지 않도록.
   • 'LOAD'STORE + 'LOAD'LOAD 조합.
   • "이 LOAD가 완료되고 난 후 실행해야 하는 모든 메모리 작업"
2. release
   • 쓰기 작업 관련 (STORE)
   • barrier에 해당하는 STORE 명령어 이전에 있는 모든 메모리 명령어가 barrier 이후로 재정렬 되지 않도록.
   • LOAD'STORE' + STORE'STORE' 조합.
   • "이 STORE를 완료하기 전 실행해야 하는 모든 메모리 작업"

CPU 별로 발생 가능한 재정렬의 종류가 천차만별이기 때문에 프로그램 언어 수준에서 제공하는 acquire-release semantics 인터페이스가 존재. (e.g. C++의 atomic 원자 라이브러리에서 제공)

• 모든 유형의 명령어 재정렬이 가능한 CPU 플랫폼을 약한 메모리 모델(weak memory model)이라고 하고,
• 자체적으로 acquire-release semantics 을 내재하고 있는 플랫폼을 강한 메모리 모델(strong memory model) 이라고 한다. (e.g. x86은 STORELOAD 재정렬만 가능)

앞서 언급했듯이, 결국 이러한 memory barrier 는
"lock 없이" "리소스를 공유"하는 "다중 스레드" 환경에서 필요한 기술.

그렇다면 대체 왜 lock 없이 멀티 스레드 리소스 공유를 하는가?
lock은 아주 좋은 공유 리소스 관리 도구. mutual exclusion 혹은 spin lock 이 있음. 다만 lock을 사용하면 lock을 얻지 못한/얻고자 하는 스레드가 블로킹 됨. lock-free 는 바로 이 블로킹 없이 스레드가 항상 어떤 일을 하도록 하는 것에 가치를 둠. 성능 향상이 목적이 아님. 심지어 구현도 매우 까다로움.

어쨋든 기억할 것.

1. CPU는 성능 향상을 위해 명령어를 꼭 순서대로 실행하지 않기도 한다.
2. 단일 스레드 환경에서는 명령어 재정렬을 걱정할 필요가 없다. (비순차적 명령어 실행은 '다른 스레드의 시선' 에서만 보인다)
3. 나아가 멀티 스레드 환경에서 lock-free 프로그래밍이 필요한게 아니라면 역시 명령어 재정렬을 걱정할 필요가 없다.

캐시 마무리

폰노이만 구조를 구현하는 입장에서, 이론적으로 캐시는 불필요한 것이다.
하지만 CPU 속도가 매우 빠른 최신 컴퓨터 장치에서 캐시는 성능 향상에 매우 중요한 역할을 한다.

1. 캐시의 용량은 제한적이므로, 프로그램이 꼭 필요한 데이터에 "집중"해야 한다.
2. 멀티 스레드에서 캐시 일관성을 지키기 위해 발생하는 cache bouncing 문제를 신경써야 한다.
   (특히나 같은 데이터를 공유하지 않더라도 같은 캐시 라인을 공유해서 cache bouncing이 발생하는 "false sharing" 문제가 있음을 알아야 한다.)
3. 항상 분석을 통해 캐시가 병목임을 확인하고 나서 최적화를 진행해야 한다. 섣부른 최적화는 만악의 근원.

6.1 CPU는 어떻게 입출력 작업을 처리할까?

인간이 컴퓨터를 사용하기 위해선 컴퓨터가 입력과 출력 기능을 갖춰야 한다.

장치(device)

입출력 장치(device)는 레지스터로 구성되어 있어, CPU가 이 레지스터를 참조해 입출력 작업을 처리한다.
즉, CPU의 입장에서 장치는 다음과 같은 종류의 저수준 계층 레지스터를 한데 묶어놓은 것에 불과하다.

• 데이터를 저장하는 레지스터
  • 장치가 입력받은 데이터가 저장되어 있는곳
• 제어정보 / 상태정보를 저장하는 레지스터
  • CPU가 이 레지스터를 읽고 씀으로써 장치 제어, 상태확인이 가능한 곳

CPU는 장치에 어떻게 접근하나: how

그리고 이 레지스터를 읽고 쓰는 방법은 다름 아니라 기계 명령어이다.
그 구체적인 방법에는 두 가지가 있다.

1. 입출력 기계 명령어
   • 입출력 장치의 레지스터에 접근하기 위한 특정한 기계 명령어 (e.g. x86의 IN, OUT)
   • 장치마다 고유한 주소를 부여해서 접근할 수 있도록 한다.
2. 메모리 사상 입출력
   • 메모리 주소 공간의 일부분을 장치에 할당해서, LOAD / STORE 명령어로 장치 레지스터에 접근할 수 있도록 한다.

CPU는 장치에 언제 접근하나: when

1. 폴링(polling) : 장치 상태 레지스터를 지속적으로 검사해서 처리할 데이터가 있는지 확인. 동기적
2. 인터럽트 구동식 : 장치가 보내는 인터럽트 신호가 발생했을 때만 데이터를 처리하는 것. 비동기적
   • 하드웨어의 인터럽트 감지를 위해, CPU 명령어 실행 단계 (IF, ID, EX, WB) 에 인터럽트 신호를 감지하는 단계가 추가되어야 한다.
   • 인터럽트 발생 시,
     • 현재 context 를 커널 스택에 저장하고,
     • 현재 실행 중인 작업과 인터럽트 처리의 우선순위를 비교해서,
     • 인터럽트 처리가 우선되어야 한다면 인터럽트를 처리하고,
     • 저장해두었던 context를 복구해 실행흐름을 재개한다.

6.2 디스크가 입출력을 처리할 때 CPU가 하는 일은 무엇일까?

결론은 "없다".
(결과 처리 제외)디스크 입출력과 CPU의 활동(다른 스레드 실행, 커널 작업, 유휴 상태)는 병행 가능하다.

어떻게 가능할까?

1. 장치 제어기 (device controller)
   • 디스크에서 물리적 기계 장치(e.g. 헤드, 실린더)를 제외한 전자 장치 부분을 장치 제어기라고 부른다.
   • 최신 컴퓨터 시스템에서 장치 제어기는 별도의 프로세서와 펌웨어, 특히 자신만의 버퍼와 레지스터를 갖는 하나의 마이크로 컴퓨터 시스템이다.
   • 따라서 CPU의 개입 없이 디스크에서 요청받은 데이터를 읽어오거나 쓸 수 있다.
     (메모리에 접근하는 것은 아님. 디스크 내부에서 데이터를 준비해오거나 저장하는 역할)
   • '장치 드라이버'와는 다른 개념. 드라이버는 OS가 관리하는 소프트웨어이고, 장치 제어기는 실제 하드디스크와 드라이버를 연결하는 다리 정도의 개념.

2. 직접 메모리 접근 (direct memory access)
   • 장치 제어기가 준비한 데이터를 메모리에 올리거나, 메모리의 데이터를 저장하기 위해 장치 제어기에게 전달하는 과정 또한 CPU가 직접 하지 않는다.
   • DMA(Direct Memory Access)는 일반적으로 입출력 장치와 메모리 사이에 데이터를 전송하는 주체.
   • CPU가 데이터 전송을 직접하지 않고 DMA에게 명령하여 대신 수행하게 한다.
   • 폴링과 인터럽트(when)에 이어서 메모리와 장치 사이에 데이터를 전송하는 방법 중 하나이다. (DMA: when + how)
   • "가상 메모리 문제"와 "캐시 일관성 문제"가 발생할 수 있는데,
     • 가상 메모리 문제는 DMA를 위해 메모리 사상 정보를 CPU가 제공하면 해결할 수 있다.
     • 캐시 문제는 동기적인 write-through 방식으로 해결할 수 있다.
3. 인터럽트
   • 그리고 입출력 과정이 완료된 결과를 가지고 처리(handle)해야 하는 시점은 인터럽트 로 CPU에게 전달된다.
   • DMA가 데이터 전송을 완료하면 인터럽트를 발생시켜 CPU에게 입출력 작업이 완료되었음을 알리고, CPU는 실행 중인 스레드를 일시 정지한 후 입출력 작업을 위해 블로킹 되었던 스레드의 실행을 재개한다.

프로그래머에게 시사하는 것

비동기, 독립, 무의존성, 분리(decoupling) 가 시스템의 리소스를 효율적으로 사용하는 것에 가까운 방법이다.

6.3 파일을 읽을 때 프로그램에는 어떤 일이 발생할까?

메모리 관점에서 입출력은 단지 "메모리의 복사(copy)"일 뿐이다.

• 외부장치에서 메모리로 데이터가 복사되면 -> 입력(input)
• 메모리에서 외부장치로 데이터가 복사되면 -> 출력(output)

두 가지를 합쳐 흔히 I/O 라고 표현한다.

그렇다면 프로세스가 디스크에서 파일을 읽는(input) 과정은 어떻게 설명할 수 있을까.
마찬가지로 외부장치(디스크)에서 메모리로 데이터를 복사해오는 것.

프로세스에서 read 계열의 시스템콜을 호출

-> 스레드 블로킹(입출력 블로킹 대기열에 추가)
   & 시스템 콜에서 디스크에 명령하여 디스크의 입출력 작업 실행(DMA 작동을 포함한다고 하자)

-> 입출력 작업이 진행되는 동안 다른 준비된 스레드 스케줄링

-> 입출력 작업 완료(메모리에 데이터 복사 완료)되면 디스크가 인터럽트를 발생시킴

-> 스레드를 입출력 블로킹 대기열에서 준비 완료 대기열로 이동.

-> 이후의 운영체제의 스케줄링에 따라 스레드가 실행되면 입출력 결과를 가지고 다시 실행흐름을 재개.

기억해둘만한 것 몇 가지.

• 프로세스에서 데이터를 복사 해올 만한 공간을 프로세스 주소 공간에 마련한다.
  이것이 버퍼(buffer).
• 입출력 블로킹 대기열과 준비 완료 대기열은 구분된다. 준비 완료 대기열은 말그대로 실행할 준비가 된 스레드가 대기하는 큐. 입출력 블로킹 대기열에 있는 스레드도 입출력이 완료되는 시점에 준비 완료 대기열로 이동된다.
• 실제에서는 일반적으로 입출력 데이터는 먼저 운영 체제 내부로 복사되고, 이후 운영 체제가 프로세스 주소 공간으로 다시 복사한다. (DMA 의 목표 주소가 커널 주소 공간에 있다는 뜻인듯)

6.4 높은 동시성의 비결: 입출력 다중화

프로그래머 입장에서 모든 입출력 장치는 파일(file)로 추상화 되어있다.

• (유닉스/리눅스 세계에서) 파일은 "N 바이트의 수열"로 이해하면 된다.
• 디스크, 네트워크 데이터, 터미널, 프로세스간 통신 모두가 파일이 제공하는 일련의 인터페이스(open, read, write, seek, close)를 사용해 읽고 쓸 수 있다.

파일을 열면(open) 커널은 파일별로 유일한 숫자 하나를 반환해주는데, 이것이 바로 파일 식별자(file descriptor)이다.
프로그램은 이 숫자만 알고 있으면 파일에 관한 다른 정보를 알 필요 없이 원하는 파일 작업을 수행할 수 있다.

char buff[LEN];
fd = open(file_name);

read(fd, buff);

입출력 다중화 (multiplexing)

1. 서버가 높은 동시성을 가진다는 것은, 동시에 많은 사용자 요청을 처리할 수 있다는 것이다.
2. 하나의 연결 소켓은 동시에 하나의 사용자 요청에만 대응할 수 있다.
   • 데이터가 도착하지 않은 상태에서 read를 하면 블로킹 되어 해당 스레드의 실행이 일시 중지 된다.
3. 그렇다고 다중 스레드를 사용해 여러 개의 소켓을 활용하자니 스레드가 많아지면서 그로 인한 부담이 발생한다.
4. 그래서 커널이 제공하는 기능을 통해 하나의 소켓을 사용하지만 마치 여러개의 소켓을 사용하는 것처럼 구현하여 서버의 동시성을 높일 수 있는데, 여기서 사용하는 기능이 바로 입출력 다중화(multiplexing)이다.
   • 소켓도 결국 입출력 작업을 위한 것이고, 그로 인해 파일로 처리되기 때문에 '입출력' 다중화 기능을 활용할 수 있는 것. 입출력 다중화는 모든 입출력을 위한 기능이다.

문제 해결의 시작은 블로킹을 해소하는 것으로부터.
블로킹이 된다는 것은, 파일이 읽을 준비가 되지 않은 상태에서 읽기를 시도했기 때문에 대기하라는 것.
이는 파일이 현재 읽을 준비가 되었는지 미리 알 수 있는 방법이 없다는 것.
그렇다면 그냥 커널이 파일이 읽을 준비가 되었을 때 응용프로그램에게 '통지'하게 하자.
이왕이면 여러 파일들 중에서 읽을 준비가 된 파일들을 한 번에 알려주는 것. -> 입출력 다중화

리눅스 세계에서 이 입출력 다중화 기술을 구현한 3가지의 함수: select, poll, epoll
3가지 모두 '동기' 입출력 다중화 기술. 감시해야 하는 파일들 중에서 읽기 가능 혹은 쓰기 가능 같은 관심 이벤트가 발생할 때까지 해당 함수를 호출한 스레드가 블로킹.

• select 는 감시할 수 있는 파일의 개수도 한정적이고 관심 이벤트 발생 시 블로킹에서 해제만 될 뿐 어떤 파일에서 이벤트가 발생했는지 알 수 없음. 결국 스레드 재개 시 파일을 전부 다시 확인해 보아야 하기 때문에 감시하는 파일의 개수가 늘어날 수록 성능이 크게 저하됨.
• poll은 감시 가능한 파일의 개수 제한만 해결.
• epoll은 어떤 파일에서 이벤트가 발생했는지 몰랐던 문제까지 해결. epoll은 입출력 다중화 구현을 위해서 커널에 데이터 구조를 생성하는데, 이 안에 '준비 완료된 파일 서술자 목록'이 존재함. 실제로 리눅스에서 epoll은 기본적으로 높은 동시성의 대명사.

6.5 mmap: 메모리 읽기와 쓰기 방식으로 파일 처리하기

파일을 읽고 쓰는 작업은 매우 번거로운 일이다.
메모리 접근에 비해, 파일을 위해서 프로그래머와 운영체제 둘 다 처리해주어야 하는 작업이 훨씬 많기 때문이다.

추가적인 처리의 근본적인 이유는,

1. 주소 지정 방식이 다름
   • 메모리는 바이트 단위로 주소를 직접 지정할 수 있지만, 디스크에 저장된 파일은 block 밀도에 따라 주소가 지정된다.
2. CPU와 입출력 장치간의 속도 차이가 존재
   • 속도 차이 때문에 디스크에 데이터를 직접 주고/받는 것이 아니라, 데이터를 메모리에 일단 저장해두고 사용해야 함.

그렇다면 프로그래머 입장에서 만이라도 메모리처럼 간단한 방식으로 파일에 읽고 쓸 수는 없을까?

mmap

파일은 "개념적으로" 연속된 디스크 공간에 저장되어 있다고 생각할 수 있기 때문에, 그 개념적으로 연속된 디스크 공간을 개념적으로 연속된 프로세스 주소 공간에 사상할 수 있다. 그리고 실제로는 운영체제가 뒤에서 대신 디스크에 읽고 써줌.

전통적인 read/write 함수에 비해 mmap은

1. 코드 설계를 간단하게 해준다.
   • 파일의 임의의 위치에 읽거나 써야할 때 유용하다.
2. 큰 파일을 읽고 쓰는데 유리하다.
   • 실제 물리 메모리 크기 + 디스크의 swap 영역의 크기 를 넘지 않는 파일은 프로세스 주소 공간에 한 번에 사상할 수 있음.
3. 성능적으로 우수할 가능성이 있다.
   • read/write 함수는 시스템 호출이기 때문에 수반되는 부담이 있음 (e.g. 문맥 교환)
   • 또한 read/write 함수는 사용자 버퍼에 데이터를 써주거나 읽어올 때 커널 버퍼에 한 번 복사해야 하는 부담이 있음
   • -> 하지만 mmap도 커널이 프로세스 주소공간과 디스크 공간을 사상하기 위한 특정 데이터 구조를 사용해야 함
   • -> 그리고 페이지폴트 시 (당연하지만) 실제로 디스크에서 메모리로 데이터를 적재해야 함

결국 실제 상황에서 반드시 테스트 해보고 어느 것이 좋은지 판단해야 한다.

동적 링크 라이브러리 또한 이 mmap을 사용해서 프로그램에게 제공된다.

• 해당 라이브러리를 사용하는 모든 프로세스의 주소공간에 (라이브러리 파일이 위치하는) 동일한 디스크 공간을 사상해주되, 실제 사상에 사용되는 물리 주소 공간을 공유할 수 있도록 해주는 것.
• 리눅스에서 동적 링크 라이브러리를 사용하는 프로그램이 실행 되기 전에 운영 체제가 mmap을 통해 이런식으로 라이브러리를 제공해 준다.

6.6 컴퓨터 시스템의 각 부분에서 얼만큼 지연이 일어날까?

컴퓨터 시스템의 여러 가지 주요 작업에서 발생하는 지연 시간. (2012년 기준)
시스템을 구축하는 방법을 설계하고 성능을 평가하는 데 중요한 참고 자료.

볼만한 지점.

1. 캐시와 메모리
   • 메모리 접근 시간은 L2 캐시보다 20배, L1 캐시보다 200배 더 느리다.
   • CPU 속도에 비해 메모리 접근이 매우 느리다는 사실을 알 수 있다.
2. 분기 예측 실패
   • 파이프라인의 명령어가 무효화 되는 경우를 의미.
   • 몇 ns 수준으로 그렇게 크지 않음.
3. SSD, disk
   • SSD 접근 시간은 메모리보다 4배 느리다.
   • 디스크 접근 시간은 SSD 보다 20배, 메모리보다 80배 느리다.
   • 디스크 탐색(seek) 시간은 ms 단위이므로 매우 느리다. (random read에서 주로 발생)

재밌는 지점.
(L1 캐시의 접근 지연이 1초라고 가정했을 때,)

1. sequential하게 1MB 데이터를 읽기 위해
   • 메모리는 3분
   • SSD는 20분
   • 디스크는 최대 1년
2. 컴퓨터를 재부팅 하는데 걸리는 실제 시간 2분
   • CPU의 관점에서는 5600년.
     동아시아 문명이 탄생한 지 5000년 이므로, CPU의 입장에서 재부팅은 문명 탄생 수준의 기간.

입출력 마무리

• 폰 노이만 구조에서 CPU가 수행하는 명령어와 그 명령어가 연산하는 데이터는 모두 메모리에 있어야 하고, 프로그램이 실행 될 때 항상 모든 데이터가 메모리에 있으리라는 보장이 없기 때문에 입출력 작업이 필수적.
• CPU가 실행하는 기계 명령어는 외부 장치의 데이터와 '비동기'이고 속도 차이도 존재. 인터럽트, DMA 등에 운영체제의 스케줄링 능력을 결합해 이를 해결할 수 있음.