OS가 제공하는 실행 중인 프로그램의 개념./

단순화해서 3가지 경우가 있는데
PintOS에서는 대기 상태(Sleep)로 변경하는 것을 구현하기도 했었다.
OS의 핵심은 "추상화"인데
Process는 사용자 프로그램을 추상화 한 것 이다.
사용자 프로그램이 컴퓨터 하나는 다 쓰는 것 "처럼" 보이도록 한다.
또한 하나의 프로세스 안에서 여러 실행흐름이 있을 수 있다.
이걸 멀티 스레딩이라고 한다.
이때 프로세스 안에서 스레드는 프로세스의 자원(주소 공간)을 같이 쓰는 경우가 있다.
이렇게 자원을 공유하기 때문에 동기화 문제가 발생한다.
여기서 같이 쓰는 공유 자원의 일부분을 Critical Section(임계 영역), 멀티 스레드가 동시에 임계 영역에 접근하는 것을 Race Condition 이라고 한다.

위 그림에서 B와 C는 A가 끝날 때까지 100 시간을 대기하는데,
이렇게 다른 프로세스의 작업이 끝날 때까지 기다리는 현상을 Convoy Effect 라고 한다.

선입 선출과 다르게 다 끝날때까지 기다리는 것이 아니라 일정 시간 동안까지만 기다리고, 다음 작업으로 전환 한다.

이름 그대로 빨리 끝낼 수 있는 작업들 부터 끝내는 것이다.
근데 이 친구도 만약 B,C보다 A가 빨리 도착한다면 FIFO와 별 다를바가 없다.

여기서 부터 선점(Preemption)의 개념이 들어오는데,
A보다 작업시간이 짧은 B나 C가 들어오면 A가 점유한 CPU를 B나 C가 점유하는 것이다.
그치만 우리가 작업의 길이를 알 수 있는 방법이 있을까...?
위에서 여러 쓰레드가 같은 자원에 접근해서 수정하게 되면 동기화 문제가 발생한다고 했다.
이를 해결하기 위한 방법이 뮤텍스와 세마포어가 있다.

위 그림처럼 2개의 스레드가 같은 공유 자원에 접근시
저 Mutex, 즉 락을 갖고 있는 스레드가 공유자원에 접근하고,
모든 작업완료시 이 락을 release 하여, 다른 스레드가 락을 가질 수 있도록 한다.

사용하고 있는 스레드 혹은 프로세스의 수를 공통으로 관리하는 하나의 값을 활용하여 상호 배제를 달성한다.
공유 자원에 접근할 수 있는 최대 허용치 만큼 접근 가능하다.
즉 저 그림에서 만약 3번까지만 허용해놓는다면,
세 개의 스레드가 공유자원에 접근이 가능하고,
4번째로 접근하는 스레드는 다른 스레드가 세마포어를 release 할때까지 기다려야한다.
문맥 교환은 현재 실행 중인 프로세스의 레지스터 값들을 커널 스택 같은 곳에 저장하고 새로이 실행될 프로세스의 커널 스택으로부터 레지스터 값을 복원하는 것.
예를 들어 유튜브로 음악을 들으면서 Velog 글을 작성할때
우린 Velog와 유튜브가 동시에 실행하는 것 처럼 느끼지만 사실은 둘이 빠르게 번갈아가면서 실행중인데
이때마다 Context Switching이 발생하는 것.
자세히 잘 설명되어 있어서 링크 공유로 갈음할게요...
어디서 많이 본듯한 글이네요!!