알고리즘 고수가 되기까지

설명 순서는 다음과 같습니다.

1. 유저모드와 커널모드란
2. 시스템콜
3. 인터럽트

1. 유저모드와 커널모드란

   - 유저 모드 : 우리가 개발하는 프로그램이 실행되는 모드. 함부로 시스템의 자원에 침범하지 못하는 모드

   - 커널 모드 : 운영 체제 코드를 실행할 수 있는 모드. 시스템의 전반을 관리하는 연산을 실행할 수 있는 모드. 하드웨어와 관련된 작업을 여기서 직접 수행함 

   - 실행 모드를 두 가지로 나눈 이유 : 시스템을 보호하기 위해. 시스템의 자원에 사용자가 함부로 침범할 경우, 시스템에 심가한 문제가 생길 수 있음. 따라서, 시스템에 관련된 부분이나 하드웨어와 관련된 부분은 커널이 담당하고, 개발자는 커널을 통해서 시스템의 기능이나 하드웨어를 사용할 수 있도록 하는 것임

   - 유저모드 -> 커널모드로 전환되는 때

      ① 프로그램이 시스템에 관련된 기능을 사용하고 싶을 때 -> 시스템 콜을 호출해서 커널모드로 전환

      ② 프로그램 실행 도중, 시스템에서 이벤트가 발생했을 때 -> 하드웨어나 소프트웨어에서 이벤트가 발생했을 때, 인터럽트가 발생하고 커널모드로 전환

   - 유저모드에서 커널모드로 전환되는 과정

      ① 유저모드에서 프로그램 실행

      ② 시스템콜 또는 인터럽트가 발생하면, 커널모드로 전환

      ③ 커널모드에서 먼저 프로세스의 상태를 PCB에 저장

      ④ 커널이 시스템콜 또는 인터럽트를 처리

      ⑤ 처리가 완료되면 다음 실행될 프로세스의 PCB를 통해 CPU상태 복원

2. 시스템콜

   - 프로세스가 시스템의 자원이나 서비스를 사용하고 싶을 때, 운영체제에 요청하는 것을 '시스템콜'이라고 함

   - 운영체제 서비스를 사용하기 위한 인터페이스라고 생각하면 됨

   - ex) 프로세스 제어, 파일 조작, 장치 연결 및 관리 등등

3. 인터럽트

   - 시스템에서 이벤트(일 또는 문제)가 발생해서 처리가 필요할 때 '인터럽트'가 발생하고, 커널 모드에서 이를 처리함

   - 인터럽트는 하드웨어나 소프트웨어 모두 발생하게 됨

   - ex) 프로세스에게 할당된 시간을 다 사용했을 경우 Timer Interrupt가 발생하고, 커널 모드로 전환돼서 context-switching이됨

시스템콜과 인터럽트에 대해 알아볼 수 있었습니다.  

설명 순서는 다음과 같습니다.

1. 동기, 비동기의 관점
2. 동기란
3. 비동기란
4. 정리

1. 동기, 비동기의 관점

   - 작업을 순차적으로 실행할 것인지 아닌지에 대한 작업의 수행방식을 말함

2. 동기란

   - 작업을 순차적으로 실행시키는 방식

   - 큰 작업이 여러 소작업의 모음이라고 할 때, 한 소작업이 완료된 후에 다음 소작업이 진행되는 방식임

3. 비동기란

   - 작업을 순차적으로 실행시키지 않는 방식

   - 여러 소작업을 멀티로 한꺼번에 실행시키는 방식임

   - 오래걸리는 소작업이 있다고 할 때, 이를 동기로 처리할 경우 뒤에 소작업들은 오래걸리는 작업이 완료될 때까지 기다려야함. 그렇지만 비동기로 처리할 경우 뒤에 소작업들은 오래걸리는 작업과 상관없이 자신의 작업을 처리할 수 있음

   - 이렇게 동시에 여러 작업을 처리한다는 것은 멀티스레드나 멀티프로세싱같은 방법으로 구현될 수 있다

4. 정리

   - 동기, 비동기 방식은 작업을 순차적으로 처리하는 방식이냐, 처리하지 않는 방식이냐의 차이임

   - 동기는 작업의 순서를 지켜지는 작업 처리 방식임

   - 비동기는 여러 작업을 함께 실행시키기 때문에, 작업의 순서를 지키지 않는 작업 처리 방식임

동기, 비동기에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. Monitor 방법
2. Java에서 Monitor 방법
3. 예시를 보며 이해
4. Java에서 Lock & Condition 방법

1. Monitor 방법

   - Java는 프로그래밍 레벨에서 동기화 문제 해결을 돕기 위해, Monitor 방법을 채택해서 제공

   - Monitor의 전체적인 흐름 : Lock을 획득 -> 임계영역 진입 -> Lock반환. Lock을 획득하지 못할 경우 잠시 대기 상태에 들어가고, 누군가 Lock을 반환할 때 스레드를 깨우는 방법

   - Monitor의 구조

      ① 임계영역 : 한 스레드만 들어가서 실행 가능한 영역

      ② Entry Set : Lock을 얻기위해 대기하는 영역

      ③ Wait Set : Lock을 얻었지만, 실행할 수 있는 조건에 맞지 않아 Lock을 반납하고 대기하는 영역

2. Java에서 Monitor 방법

   - Java 객체는 내부적으로 하나의 Monitor를 가짐

   - 동기화를 위한 키워드

      ① synchronized : 메서드 또는 블럭 앞에 붙임. 이 메서드 또는 블럭은 내부적으로 모니터 락을 획득해서, 상호배제를 보장함

      ② wait() : lock을 획득해서 synchronized 블럭에 들어왔는데 만약 어떤 해당 조건에 만족하지 않아서 일을 진행할 수 없을 때, 내가 갖고 있는 lock을 풀고 wait set에 들어감

      ③ notify() : wait set에 있는 thread 중 하나를 깨워서 entry set에 넣음

      ④ notifyAll() : wait set에 있는 모든 thread를 깨워서 entry set에 넣음

   - 전체적인 흐름

      * Lock획득(synchronized 블럭 진입) -> 임계영역 실행 -> Lock반환(synchronized 블럭 탈출)

      * entry set에 있는 하나의 스레드를 빼서 synchronized 블럭에 진입

      * synchronized 블럭에 들어갔더라도, 조건이 맞지 않은 경우 lock을 풀고 wait set에 들어가고 블럭 탈출

      * 다른 스레드가 synchronized 실행 후 notify로 wait set에 있는 하나를 깨워서 entry set에 넣음

3. 예시를 보며 이해

   - Producer 1번, 2번을 P1, P2로 하고, Consumer 1,2,3번을 C1, C2, C3라 하자

   - 그림의 Buffer는 한번에 한 스레드만 사용해야 함

   - 진행

      ① C1이 Buffer(Buffer의 Lock) 획득. 하지만, Buffer가 비어있으므로(실행할 수 없는 조건) C1은 wait set에 진입

      ② P1, P2, P3가 모두 Buffer를 획득하기를 원해서 P1만 Buffer 획득. 나머지는 entry set에 진입

      ③ P1은 Buffer하나를 채운 후 notify -> wait set에 있는 하나를 깨움 -> C1은 entry set에 진입

      ④ entry set에 있는 P2, P3, C1 중 하나가 Buffer 획득

      ⑤ ... 반복

   - wait set중 어떤 것을 깨울 것인가? entry set중 어떤 것에 Lock을 줄 것인가? -> 이러한 문제는 starvation을 야기할 수 있음.

   - 또한, wait set에 Producer와 Consumer가 같이 관리되기 때문에 만약 Producer가 Buffer를 가득 채우고 wait set에 있는 다른 Producer를 깨우면, 이 Producer는 Buffer를 획득하더라도 채울 수 없기 때문에 또 wait set에 들어감. Producer가 Buffer를 채웠다면, wait set에 있는 Consumer를 깨우는게 더 효율적인 상황임

4. Java에서 Lock & Condition 방법

   - 위와 같은 문제를 해결하기 위해 Lock & Condition 방법을 제공함

   - Monitor 방법과 다른 점은 Condition에 따라 wait set을 따로 구분하는 것임. 위 문제에서는 Producer wait set과 Consumer wait set을 따로 구분함

   - 만약 P1이 Buffer를 채웠다면, Consumer wait set중 하나를 깨워서 entry set에 넣음

   - 반대로 C1이 Buffer를 소비했다면, Producer wait set중 하나를 깨워서 entry set에 넣음

   - 이렇게 스레드의 상태에 따라 종류를 나눠서 wait set을 만들 경우, 더 효율적인 상황이 됨

   - 하지만, 같은 종류의 스레드(ex. P1, P2)끼리의 경쟁은 있기 때문에 기아현상이 발생할 가능성은 여전히 있고, Entry Set중 어떤 스레드에 lock을 줄 것인지에 대한 문제도 있기 때문에 기아현상 여전히 존재

   - 공정하게 lock을 주기 위해서 java에서는 Lock lock = new ReentrantLock(boolean fair) 라는 공정성 매개변수를 제공하는데(true일 경우 오래 기다린 스레드에게 lock을 획득하게함), 그런데 그만큼 성능이 떨어지고, 대부분의 경우 공정함보다는 성능을 채택함

Java에서 Programming Level에서의 동기화 문제를 어떻게 해결하는지 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. 자원을 공유할 때 생기는 문제
2. 동기화란
3. 임계영역
4. 임계영역 문제 해결 방법

1. 자원을 공유할 때 생기는 문제

   - 두 개의 스레드가 counter라는 변수를 공유한다고 가정하고, 두 스레드 모두 counter++ 메서드를 실행할 때

   - counter++ 명령문은 실제 cpu에서 실행될 때는 3개의 복합 명령문으로 되어있음(counter 변수를 로드하고, counter 값을 1증가시키고, counter에 다시 저장)

   - 그래서 만약 한 스레드가 counter를 로드하고 값을 1증가시키기만 하고 Context-Switching이 발생하고 다른 스레드가 counter++을 한 경우, 업데이트되지 않은 counter값을 참조하게 됨

   - 이렇게 여러 프로세스 또는 스레드가 동시에 같은 데이터를 조작할 때 타이밍이나 접근 순서에 따라서 데이터의 결과가 달라질 수 있는 상황을 'Race Condition'이라고 하고, 이것이 자원을 공유할 때 생기는 문제

2. 동기화란

   - 여러 프로세스 또는 스레드를 동시에 실행해도 공유 데이터의 일관성을 유지하는 것임

   - 위 문제를 보면 3개의 복합 명령문이 실행하는 도중에 Context-Switching이 발생해서 문제가 생겼으므로, '복합 명령문이 실행하는 도중에 Context-Switching이 발생하지 않게끔 하면 해결할 수 있겠다'라고 생각할 수 있음

   - 하지만, 이 해결방법 Single Core일 때만 가능하고 Multi Core일 때는 불가능함. 왜냐하면, 두 스레드 모두 다른 코어에서 동시에 변수를 Load하면 아까와 같은 문제는 피할 수 없음

   - 근본적인 해결방법은 공유 데이터를 한번에 한 스레드나 프로세스만 사용하도록 해야함

3. 임계영역

   - 이렇게 공유 데이터의 일관성을 보장하기 위해서 한 스레드나 프로세스만 진입해서 실행 가능한 영역을 임계 영역이라고 부름

   - 그리고 임계영역의 문제에 대한 해결책이 되기 위한 조건으로 아래 3가지가 있음

      ① 상호배제 : 한번에 하나의 프로세스 또는 스레드만 임계영역에 들어갈 수 있음

      ② 진행 : 만약에 임계영역이 비어있고 그 임계영역에 들어가고 싶은 프로세스나 스레드가 있을 경우, 그 중에 하나는 임계영역에 들어가서 진행이 되어야함

      ③ 한정된 대기 : 어떤 프로세스나 스레드가 무한정 임계영역에 들어가지 못하고 기다리고 있으면 안되는 조건

   - 이 3가지 조건을 모두 만족해야 임계영역 문제에 대한 해결책이 될 수 있음

4. 임계영역 문제 해결 방법

   - 임계영역의 문제를 해결하기 위한 방법은 'Lock'을 사용하는 것

   - 임계영역에 들어가기 전에 락을 걸고, 한 프로세스만 임계영역을 사용한 후, 락을 풀면 이제 다음 프로세스가 임계영역에 락을 걸고 사용하는 방법임

   - 락을 이용한 대표적인 임계영역 구현 방법 : Spinlock, Blocking & Wake up

      ① Spinlock

         * 한 프로세스나 스레드가 임계영역에 들어가기 전에 lock을 걸고, 나머지는 임계영역에 들어가기 위해 lock을 획득하려고 계속 기다리는 상태

         * 하지만, lock을 기다리는 동안 CPU를 낭비함. 락을 계속 확인하는 과정에 다른 프로세스나 스레드가 유용하게 사용할 수 있기 때문임

         * 한정된 대기 조건을 만족시키지 못할 수 있음. 한 스레드만 계속해서 락을 가져가고, 한 스레드는 계속 락을 기다릴 수 있기 때문임

      ② Blocking & Wake up

         * Spinlock의 단점을 극복한 것

         * lock을 획득하기 위해 계속 기다리지 않고 Ready Queue에 들어가서 휴식하는 방법임

         * 그러나 Mutex가 Spinlock 항상 좋은 것은 아님. 멀티코어 환경에서 임계영역에서의 작업이 Context-Switching보다 빠르다면 Spinlock이 더 좋은 성능을 가짐

   - 락을 이용한 대표적인 임계영역 해결 방법 : Mutex, Semaphore

      ① Mutex

         * 하나의 스레드 또는 프로세스만 임계영역에 들어갈 수 있도록 하는 방법

         * 사용하려는 스레드가 lock을 걸고 임계영역을 사용한 후에 unlock을 해야, 다른 스레드가 이 임계영역을 사용할 수 있음

      ② Semaphore

         * 정해진 수의 스레드 또는 프로세스만 임계영역에 들어갈 수 있도록 하는 방법

         * 한 스레드가 임계영역에 들어가서 lock을 획득하고 unlock을 하지 않아도, 옆에 있는 스레드가 unlock을 할 경우 다른 스레드가 임계영역에 들어올 수 있음

동기화에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. 가상 메모리
2. 페이지 교체 알고리즘

1. 가상 메모리

   - 메인 메모리의 크기는 한정되어 있어서, 메모리 크기보다 더 큰 프로세스는 현실적으로 실행시킬 수 없음. 또한, 실행하는 여러개의 프로세스의 크기가 메모리보다 크다면 많은 프로세스를 함께 실행시킬 수 없음

   - 이러한 문제를 해결하기 위해 물리적으로 메모리의 크기를 키우지 않고, 메모리를 사용하는 사용자에게 마치 매우 큰 메모리처럼 보이게하는 것이 '가상 메모리' 기법임

   - 해결방법의 핵심은 프로세스 전체를 메모리에 로드하지 않고, 당장 실행에 필요한 프로세스의 페이지만을 메모리에 올리는 것임

   - 여기서 프로세스의 페이지는 프로세스를 책으로 생각했을 때, 그 안에 있는 페이지라고 생각할 수 있음. 그래서 책에서 내가 지금 읽을 페이지만 따로 떼서 읽는 것

2. 페이지 교체 알고리즘

   - 메인 메모리에 필요한 페이지가 없을 때(page fault발생 시), 디스크에서 페이지를 찾아 메모리의 빈 프레임에 로드해야 함

   - 이 때 만약 메모리에 빈 프레임이 없을 경우, 한 프레임을 디스크로 내리고 비워야 함. 이 때 교체될 프레임을 고르는 알고리즘이 페이지 교체 알고리즘임

   - 페이지 교체 알고리즘의 목적은 'page fault 발생 비율을 줄이는 것'임

   - 주요 알고리즘

      ① FIFO(First In First Out)

         * 가장 먼저 메모리에 올라온 페이지를 내보내는 방법

         * 성능이 좋지 않음. 프로세스에 프레임을 많이 할당해도 page fault가 역설적으로 늘어나는 현상 발생할 수 있음

      ② OPT(Optimal)

         * 이상적인 방법. 앞으로 가장 오랫동안 사용하지 않을 페이지를 내보내는 방법

         * 성능이 가장 좋음

         * 하지만, 프로세스가 사용할 페이지를 미리 모두 알아야함. 사실상 구현 불가능

      ③ LRU(Least Recently Used)

         * 가장 오랫동안 사용하지 않은 페이지를 내보내는 방법

         * 성능이 좋은 편

      ④ LFU(Least Frequently Used)

         * 가장 적게 참조된 페이지를 내보내는 방법

         * 시간 지역성을 이용하지 못하므로 성능이 좋지 않다고 생각함. (1번 페이지를 방금 1번 사용했는데, 1번은 또 사용될 가능성이 높기 때문)

      ⑤ MFU(Most Frequently Used)

         * 가장 많이 참조된 페이지를 내보내는 방법

페이지 교체 알고리즘에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. 데드락이란
2. 데드락의 발생 조건
3. 데드락 해결 방법

1. 데드락이란

   - 두 개 이상의 프로세스가 서로가 가진 리소스를 기다려서 더 이상 진행되지 못하는 상태

2. 데드락의 발생 조건

   - 아래의 4가지 조건을 모두 만족해야 데드락이 발생함

   - 조건

      ① 상호 배제 : 한 리소스는 한번에 한 프로세스(스레드)만 사용할 수 있음. 동시에 같이 사용할 수 없음.

      ② 점유 대기 : 한 리소스를 점유하고 다른 프로세스(스레드)가 사용하는 리소스를 기다리는 상태.

      ③ 비선점 : 다른 프로세스가 사용하는 리소스를 강제로 빼앗을 수 없음.

      ④ 순환 대기 : 프로세스들이 순환 형태로 서로의 자원을 기다리고 있는 상태.

3. 데드락 해결 방법

   - 해결 방법은 크게 3가지로 나누어 볼 수 있음. 예방, 회피, 탐지 & 회복.

   - 예방은 데드락 발생 조건 중 하나라도 만족하지 못하게 해서, 데드락의 발생을 예방하는 방법.

   - 회피는 자원을 할당하기 전에, 할당하더라도 데드락이 발생하지 않는지 확인 후 자원을 할당하는 방법.

   - 탐지 & 회복은 데드락이 발생하게끔 둔 다음, 회복하는 방법.

   - 예방

      ① 상호 배제를 부정 : 리소스를 같이 사용할 수 있게끔 만들어야함. 그렇지만, 이럴 경우 동기화 문제 발생. 사실상 불가능한 방법

      ② 점유 대기를 부정 : 사용할 리소스를 모두 얻은 후에 진행 가능. 대기하는 상황을 없애는 것임. 하지만, 지금 당장 사용하지 않는 리소스를 가져가는 바람에 다른 프로세스는 이 리소스를 사용하지 못함. 리소스 사용효율이 떨어짐. 또한, 사용할 리소스가 인기가 많아서 한꺼번에 확보하기가 쉽지 않다면, 진행할 수 없음.

      ③ 비선점을 부정 : 다른 프로세스가 리소스를 강제로 빼앗을 수 있게 만듬.(기아현상 발생 가능할 듯)

      ④ 순환 대기를 부정 : 자원에 번호를 붙이고, 번호가 작은 것부터 요청할 수 있도록 하는 것

   - 회피

      ① 리소스를 요청했을 때, 데드락이 발생할 가능성이 있는지 확인 후에 없으면 할당하는 방법

      ② 리소스를 요청할 때마다 특별한 알고리즘으로 매번 확인해야하는 오버헤드가 발생함

      ③ 미리 어떤 자원을 요구할 지 알아야 함

   - 탐지 & 회복

      ① 자원 할당 상태를 파악하여, 데드락이 발생했는지 탐지한 후에, 데드락을 해결(회복)하는 방법

      ② 데드락을 탐지하는 방법은 자원 할당 그래프 등을 통해서 알 수 있음

      ③ 회복하는 방법은 한 프로세스씩 종료하거나 아니면 일시적으로 리소스의 선점을 가능하도록 함

      ④ '어떤 프로세스를 종료' 하거나 '어떤 프로세스가 리소스를 선점' 할 때, '어떤 프로세스'를 정해야하는데 이 때 특정 프로세스만 자원을 할당받아 다른 프로세스는 '기아현상'이 벌어지지 않도록 해야함

      ⑤ 기아현상을 해결하기 위해 리소스를 오래 대기할 수록 우선순위를 높여주는 방식을 채택할 수 있음

데드락에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. Context Switching이란
2. Context Switching이 발생하는 이유
3. Context Switching의 자세한 과정
4. 프로세스 or 스레드 Context Switching의 비교

1. Context Switching이란

   - CPU(코어)에서 실행중이던 프로세스 or 스레드가 다른 프로세스 or 스레드로 변경되는 것을 의미

   - 오늘날의 컴퓨터에서 프로세스는 하나의 스레드를 가짐. 이유는 이 스레드가 CPU(코어)에서 작업의 단위이기 때문임. 따라서 프로세스에서 프로세스로 변경된다는 의미는 프로세스의 스레드가 다른 프로세스의 스레드로 변경된다는 의미와 같음

   - Context Switching이란 말을 풀어보면 '문맥 전환'인데, 여기서 문맥은 CPU가 한 프로세스를 실행시키기 위해서 레지스터, 캐시 또는 TLB 등등에 데이터를 올려놨다가, 다른 프로세스를 실행시키기 위해서 이러한 값들이 바뀌는 것을 의미함

2. Context Switching이 발생하는 이유

   - 컴퓨터 시스템의 변천사에서 본 것처럼, 프로세스의 응답률을 높이기 위해서 여러 프로세스가 짧은 시간동안 CPU를 번갈아가며 사용하게 되는데, 이렇게 프로세스가 바뀔때마다 Context Switching이 발생함

   - 이런 멀티태스킹 방식에서 Context Switching이 발생하는 예시를 살펴보면

   - P1 -> (컨텍스트 스위칭) -> P2 -> (컨텍스트 스위칭) -> P1 ...

   - 컨텍스트 스위칭은 OS의 커널에 의해서 실행됨

3. Context Switching의 자세한 과정

   - 진행중인 프로세스 or 스레드가 다른 프로세스 or 스레드로 바뀌려면, 진행중인 프로세스의 상태를 어딘가에 저장하고 다른 프로세스의 상태를 불러와야함. 그래야 바뀐 작업을 다시 이어나갈 수 있고, 현재 진행중인 것을 나중에 다시 이어나갈 수 있기 때문임

   - 과정

      ① 커널은 진행중인 프로세스 or 스레드의 상태정보를 특정 자료구조에 저장(프로세스는 PCB, 스레드는 TCB)

      ② 바꿀 프로세스 or 스레드의 상태정보를 가져와 그것을 바탕으로 레지스터 캐시 등에 데이터를 로드함

      ③ 바꾼 프로세스 실행

4. 프로세스 or 스레드 Context Switching의 비교

   - PCB보다 TCB가 더 가벼움. 이유는 프로세스는 독립적인 메모리를 사용하는 반면 스레드들은 같은 메모리를 공유함. 그래서 TCB는 stack 및 간단한 register 정보만을 저장하기에 더 가볍다.

   - 프로세스 Context Switching은 Cache 메모리를 초기화해야함. 이유는 프로세스들끼리는 메모리를 공유하지 않기 때문에, 사용되는 메모리 또한 다르기 때문임. 그렇지만, 스레드 Context Switching의 경우 Cache를 초기화하지 않음(다른 프로세스 간 스레드일 경우는 캐시 초기화를 함)

Context Switching에 대해 알아볼 수 있었습니다   

설명 순서는 다음과 같습니다.

1. 기본적인 용어 정리
2. 컴퓨터 시스템의 변천사
3. 스레드의 등장배경
4. 스레드의 특징

1. 기본적인 용어 정리

   - 프로그램 : 컴퓨터가 실행할 수 있는 명령어들의 집합(ex. .exe파일)

   - 프로세스 : 컴퓨터에서 실행중인 프로그램. 이 때 프로세스는 독립적인 메모리 공간을 할당받고 이 공간에 명령어들과 데이터를 가짐

   - CPU : 작업(프로세스, 쓰레드)를 처리하는 연산장치

2. 컴퓨터 시스템의 변천사

   - 처음에는 단일 프로세스 시스템부터 시작

   - 단일 프로세스 시스템이란 한번에 하나의 프로세스만 동작할 수 있음. 풀어서, 현재 실행하는 프로세스를 먼저 끝내고 종료시킨 후 다음 프로세스를 진행하는 방식임

   - 이 방식은 프로세스가 실행도중 Input/Output 작업을 만나서 CPU를 사용하지 않게되면, CPU는 계속 쉬고 있는 단점이 발생함

   - 따라서, CPU의 사용률을 높이기 위해 '여러 개의 프로세스를 메모리에 올려놓고, 현재 진행중인 프로세스가 CPU를 사용하지 않을때, 대기중인 프로세스가 CPU를 사용할 수 있게 하자'는 방식이 등장 -> 멀티 프로그래밍 방식(아마도 멀티프로그래밍 방식의 등장으로 CPU 스케쥴링이 등장한 것이라고 생각)

   - 하지만, 이렇게 프로세스를 여러개 올려놓는 방식도 문제가 있음

   - 한 프로세스가 CPU를 오래 사용하는 작업이라면 뒤에 짧게 사용하는 프로세스는 모두 대기해야함(이러한 단점도 CPU스케쥴링에서 비선점형 방식의 단점이라고 생각). 프로세스의 응답시간이 낮음

   - 그래서, '프로세스는 한번 CPU를 사용할 때 아주 짧은 시간동안만 사용하도록 해서 응답률을 높이자'는 방식이 등장 -> 멀티 태스킹 방식(마치 여러개의 작업을 동시에 처리하는 것처럼 보이게 함. 실제는 프로세스를 빠르게 번갈아가며 실행시키는 방식임)

   - 실행되는 프로세스가 바뀔 때, 그 프로세스가 사용하는 데이터를 불러오는 Context-Switching이라는 비용이 발생하더라도 응답률을 높이기 위해 trade-off

3. 스레드의 등장배경

   - CPU의 성능을 계속 발전시키에는 발열등의 이슈로 한계에 봉착

   - 그래서, CPU안에 코어를 여러개 둠으로써 성능을 향상시키는 방법을 사용

   - 그러면 이제 중요한 이슈는 '어떻게 여러개의 코어를 잘 사용할까'임

   - 이를 해결하기 위해 '프로세스를 여러 개의 프로세스로 나누고 이 작업들을 각자의 코어에서 돌리자'는 방식이 등장 -> 멀티 프로세스 방식

   - 그런데 여기서 더 개선하고 싶은 여지가 있음

      ① 프로세스는 독립된 메모리 공간을 사용해서, 서로 데이터를 공유하기가 어려움

      ② 프로세스 간 Context-Switching 비용을 줄이고 싶음

   - 그래서, 한 프로세스 내부에서 '서로 데이터를 공유하기 쉽고', 'Context-Switching 비용이 적은' 작업 단위인 스레드가 등장

4. 스레드의 특징

   - 이제 한 프로세스를 여러 개의 작업으로 나눌 수 있고, 한 프로세스 내부에서 서로 데이터를 공유하기 쉽고 Context-Switching 비용이 적은 하나의 작업 단위인 스레드를 사용할 수 있음

   - 그리고 이 스레드는 코어가 실행되는 '작업의 단위'가 됨

   - 정리해보면

      ① 한 프로세스는 여러개의 스레드를 가질 수 있음

      ② 스레드는 코어에서 실행되는 작업의 단위임

      ③ 같은 프로세스의 스레드들끼리는 프로세스의 메모리를 공유 -> 그래서 데이터 공유가 쉬움. 스레드들이 독립적으로 사용하는 stack 영역이 있고, code, data, heap영역은 다른 스레드와 공유함

      ④ 위 ③으로 인해, 프로세스에 비해 Context-Switching 비용이 적음

         * 메모리를 공유하기 때문에, PCB에 비해서 TCB는 간단한 정보만 들어있기 때문

         * 프로세스 내 스레드 간 Context-Switching인 경우, 캐시 메모리를 초기화하지 않음(그 스레드 또한 같은 데이터를 사용하기 때문)

       ⑤ 하지만, 서로 다른 스레드가 데이터를 공유하다보니, 이런 자원들의 동기화를 해결해야하는 문제가 있음

프로세스와 스레드에 대해 알아볼 수 있었습니다.