# process vs thread

## 컨텍스트 스위칭이 발생하는 경우
- 인터럽트 (HW)
- 외부에서 유발되어 발생, 비동기
- 종류
- 클럭 인터럽트
- 시간 할당량을 모두 사용했는지 여부. 시간 할당량을 모두 소진 시 대기 상태로 변경
- 입출력 인터럽트
- 입출력이 완료되었을때 발생. 이 인터럽트가 발생 시,발생한 입출력을 기다리고 있던 프로세스를 준비 상태로 변경
- 트랩 (SW) - 오류나 예외 상황 처리, 동기
- 현재 수행되고 있는 프로세스에서 생성되는 오류나 예외 조건때문에 발생
- 내부적으로 발생
- 메모리 폴트
- 슈퍼바이저 호출(system call)
- 시스템 함수

## 컨텍스트 스위칭의 비용이 많이 드는 이유
- 프로세스 VS 쓰레드
- 프로세스
- 프로세스의 컨텍스트 스위칭 시 TLB와 CPU 캐시의 데이터들은 기존 프로세스를 위한 데이터이기 때문에 초기화시켜야 한다. 그러면 기존의 캐시 데이터를 사용하지 못하고 물리 메모리를 참조해야하므로 비용이 많이 든다. 쓰레드의 컨텍스트 스위칭은 기존 TLB와 캐시를 활용할 수 있으므로 효율적이다.
- 실행할 프로세스의 Page Table을 load 해야함 (메모리에 없는 경우)
- 컨텍스트 스위칭시 현재 실행중인 프로세스의 정보(in Register)를 교체될 프로세스의 PCB(in Memory)에 저장, 실행될 프로세스(in Memory)의 PCB값을 레지스터로 로드 해야 한다.그 시간만큼 CPU가 동작하지 못하므로 속도저하가 발생(메모리가 레지스터에 비해 상대적으로 느리기때문에 지연됨)

<details>
<summary>TLB 동작 과정</summary>
<div markdown="1">
<img src=https://user-images.githubusercontent.com/33454557/112507744-41b59580-8dd2-11eb-85f7-14d9ca88123a.png />
</div>
</details>

- 쓰레드
- 프로세스를 컨텍스트 스위칭하는 비용에 비해서 저렴하긴 하지만 쓰레드도 비용이 든다. 쓰레드 컨텍스트 스위칭이 많이 발생할 경우 lock 때문에 비용이 든다.

※ (뇌피셜) 여러 프로세스에서 멀티 쓰레드
대분분의 자료들을 보면 멀티 쓰레드의 설명이 여러 프로세스일 때의 상황을 고려하지 않고 쓰여있는 것 같다. 쓰레드간의 컨텍스트 스위칭 비용이 프로세스간의 컨텍스트 스위칭 비용보다 적다는 설명을 보면서 멀티 쓰레드는 프로세스 컨텍스트 스위칭이 발생하지 않는다는 뉘앙스를 느꼈다. 단 하나의 프로세스로만 돌아가는 시스템은 말이 안된다. 멀티쓰레드를 사용하면 전체적인 프로세스 컨텍스트 스위칭 비용이 줄어드는것을 맞지만, 0은 아니다.

※ 쓰레드 lock 컨텍스트 스위치 되나?
한 쓰레드가 lock을 얻은채로 대기 상태로 돌아가게 되면 다른 쓰레드가 lock이 걸린 공유 자원에 접근 시 suspend 상태가 되어 스케쥴링 리스트에서 제거된다. lock이 풀릴 경우 이 자원으로 인해 suspend 상태가 된 쓰레드들을 wake up 시킨다.

모드 스위치 비용 어떻게 되나? 비쌈, 컨텍스트 스위치 비용에 비해서는 적음

유저 레벨 쓰레드 VS 커널 레벨 쓰레드

### 유저 레벨

- 사용자 수준에서 각 쓰레드를 라이브러리가 관리
- 쓰레드 라이브러리는 쓰레드의 생성과 제거, 스레드 간의 데이터 교환, 스레드 스케줄링, 스레드 문맥의 저장과 복구 등을 처리함
- 커널은 쓰레드의 존재를 알지 못하고 하나의 프로세스로 스케줄링

#### 장점

- 사용자 수준에서 쓰레드를 관리하기 때문에 사용자 모드에서 커널 모드로의 모드 전환이 필요없어 오버헤드를 감소시킴

#### 단점

- 스레드 하나가 대기 상태가 되면 나머지 스레드들도 대기 상태가 되어 작업을 진행할 수 없음
- 커널은 하나의 프로세스로 인식하기 때문에 멀티 CPU 환경에서 CPU를 한 개 밖에 사용하지 못함

### 커널 레벨

- 커널에서 쓰레드 관리

#### 장점
- 하나의 쓰레드에 문제가 생기더라도 같은 프로세스 내의 쓰레드는 작동
- 하나의 프로세스가 여러 CPU 코어를 사용 가능

#### 단점
- 커널에서 쓰레드를 관리하기 때문에 커널 모드로 모드 전환이 필요함. 오버헤드가 발생함.

## 컴파일러 VS 인터프리터 + JIT + 컴파일러 최적화

### 컴파일러란?
- 특정 프로그램 언어로 작성된 문장을 처리하여 기계어 또는 컴퓨터가 사용 할 수 있는 코드로 변경시켜 주는 것
- 크게 6개의 과정을 수행함
- 어휘분석 단계
- 구문분석 단계
- 의미분석 단계
- 중간코드 생성 단계
- 코드 최적화 단계
- 목적코드 생성 단계

※ 트랜스파일러란?

컴파일러는 높은 수준의 언어를 하위 수준의 언어로 변환
트랜스파일러는 높은 수준의 언어를 동일한 수준의 언어로 변환

### 인터프리터란?
- 고급 언어로 작성된 소스 코드를 직접 한 줄씩 해석하고 실행하는 프로그램

### 컴파일러 vs 인터프리터 차이점

- 컴파일러는 실행 전에 기계어로 변경하지만, 인터프리터는 실행 전에 기계어로의 컴파일 과정을 거치지 않고 한 줄씩 실행시켜나감.
- 컴파일러는 실행 파일을 생성하고 인터프리터는 실행 파일을 생성하지 않음
- 컴파일러의 컴파일된 파일은 다른 환경에서 실행시 다시 컴파일을 해야하지만, 인터프리터는 인터프리터가 설치되어 있으면 같은 프로그램을 다른 환경에서도 실행 가능
- 디버깅이 쉽다.
- 소스 코드가 굉장히 클 경우 컴파일이 오래 걸린다. 이런 경우 디버깅 시 결과를 확인하려면 매번 컴파일 해야하므로 시간이 오래걸린다. 인터프리터는 컴파일 하지 않고 즉시 실행할 수 있어서 디버깅이 용이해진다.

※ 웹에서 인터프리터를 사용하는 이유

로드 시간이 중요한 웹 환경의 경우, 컴파일하고 프로그램을 실행하는 것 보다 인터프리터가 프로그램을 바로바로 실행하는 것이 반응성이 좋다

### 하이브리드
- 컴파일러와 인터프리터를 같이 차용해서 쓰는 경우
- 기존 코드를 가상 머신이 이해할 수 있는 바이트 코드로 컴파일 한 후에 인터프리터가 바이트 코드를 해석한다

### JIT란?
- 인터프리터 방식의 성능 향상 방법
- 같은 코드를 매번 해석하는 대신 처음 실행할 때 한 줄씩 컴파일한 바이트코드를 캐싱함. 이후 실행 시 캐싱된 코드를 가져다 사용. 캐싱된 코드를 사용하기때문에 인터프리터의 속도를 빠르게 할 수 있음

- 단점이라면 초기 구동 시에는 소스 코드(혹은 바이트코드)를 실행 단계에서 컴파일하는 데에 시간과 메모리를 소모하기 때문에 정적 컴파일된 프로그램에 비해 실행 속도 면에서 손해를 본다는 것으로, 특히 실행 시간이 매우 짧은 경우에는 애써 컴파일된 코드를 제대로 울궈먹기도 전에 프로그램이 끝나는 배보다 배꼽이 더 큰 상황이 벌어지기도 한다.

### 가비지 컬렉터

## Virtual Memory

## 네트워크

## 디비
ACID
트랜젝션
lock
회복
https://d2.naver.com/helloworld/407507
http://kostja.github.io/misc/2017/01/24/tarantool-design-principles.html

## 자료구조

javacript - array
int a[4] = 0000 a[1] = 0004 a[2] =
a["test"] = 4;

## 알고리즘