프로세스가 병행, 병렬로 실행
cpu스케줄러 프로세스 사이에서 빠르게 오가며 각 프로세스를 실행시켜서 병행 실행시킴
프로세스는 어느 지점에서나 인터럽트되고, 처리 코어는 다른 프로세스의 명령어를 실행하도록 할당될 수 있다.
두 프로세스가 동시에 변수를 조작한다면 race 상태가 된다.
그래서 프로세스들이 동기화되도록 할 필요가 있다.
n개의 프로세스가 있고, 각 프로세스는 임계구역이라고 부르는 코드 부분을 포함하고 있다.
그 안에서는 적어도 하나 이상의 다른 프로세스가 자신의 임계구역에서 수행하는 동안 다른 프로세스들은 그들의 임계 구역에 들어갈 수 없다.
따라서 임계구역에 들어가려면 진입 허가를 받아야한다.
요청을 구현한 코드가 진입 구역, 퇴출구역이 있다.
운영체제 내에서 임계구역을 다루기 위해서 선점형 커널과 비선점형 커널의 방법이 사용된다.
선점형 커널은 선점을 허용하고, 비선점은 허용하지 않기때문에 비선점은 race를 신경쓰지 않아도 된다.
선점형은 신경을 써야함!
특히 SMP 구조에서 race를 신경쓰기란 어렵다.
서로 다른 프로세서의 두 프로세스가 동시에 커널 모드에 있을 수 있기 때문이다.
그래도 선점형이 사용되는 이유가 현재 커널에서 실행 중인 프로세스를 선점할 수 있기 때문에 실시간 프로그래밍에 더 적합함
peterson의 해결법은 두 프로세스가 있고 임계구역으로 진입할 순번을 지정받는데, 절대로 같은 순서가 나올 수 없게하는것이다.
최신 아키텍처에서는 쓰이지 않는데, 주된 이유가 프로세서 및 컴파일러가 종속성이 없는 읽기 및 쓰기 작업을 재정렬 할 수 있기 때문이다.
강한 순서, 한 프로세서의 메모리 변경결과가 다른 모든 프로세서에 즉시 보임
약한 순서, 보이지 않음
메모리 모델은 프로세서 유형에 따라 달라서 공유 메모리 다중 프로세서에서 메모리 변경의 가시성에 대한 어떤 가정도 할 수 없다.
메모리의 모든 변경 사항을 다른 모든 프로세서로 전파하는 명렁어가 메모리 장벽이라 한다.
메모리 장벽 명령어가 실행되면, 시스템은 모든 적재 및 저장이 완료되도록 한다.
두 워드의 내용을 원자적으로 교환할 수 있는 명령어를 제공함
test and set 명령어를 지원한다면, 순차적으로 실행된다.
compare and swap은 인자를 3개 받음
카운터가 증가할 때와 같이 갱신되는 동안 단일 변수에 대한 데이터 경쟁이 잇을 수 잇는 상황에서 상호 배제를 보장한다.
atomic var이 CAS 연산을 사용하여 구현됨
임계구역을 보호할 수 있고 race를 막느다.
들어갈떄 락하고, 나올때 해제하면 된다.
반복문에서 계속 락을 획득하려고 하지만 반환이 될때까지 계속 봉쇄된다.
하지만 이런 대기는 바쁜대기로 다른 프로세스가 생산적으로 사용할 수 있는 cpu를 낭비한다.
하지만 context switch는 필요가 없다는 장점이 있다.
지금까지 설명한 것이 스핀락, 계속 회전하기 때문
mutex와 유사하지만 더 정교하다
세마포 S는 정수 변수로서, 단지 2개의 표준 아토믹 연산 wait, signal로만 접근가능하다.
한 스레드가 세마포 값을 변경하면, 다른 어떤 스레드도 동시에 동일한 세마포 값을 변경할 수 없다.
카운팅 세마포의 값은 제한 없는 영역
이진 세마포는 0과 1 사이의 값만 가능하다. 이진은 mutex와 비슷
wait연산시 세마포의 값은 감소하고, signal 연산시 세마포는 증가한다.
세마포는 잘못 사용하면 발견하기 어려운 타이밍 오류를 야기할 수 있다.
프로그램의 세마포에 대한 wait, signal의 연산의 순서가 바뀐 경우
프로그램이 siganl을 써야할 곳에 잘못해서 wait를 쓸경우
프로세스가 wait, signal을 둘 다를 빠트렸을 경우
임계구역에 들어가려고 시도하는 프로세스는 무기한 대기할 가능성이 있다.
무기한 대기는 진행 및 한정된 대기 2개의 기준을 위반한다.
라이브니스는 프로세스가 실행 수명주기 동안 진행되는 것을 보장하기 우해 시스템이 충족해야 하는 일련의 속성, 무기한 대기가 라이브니스 실패의 예시이다.
대기 큐를 가진 세마포를 구현은 2개 이상의 프로세스들이, 오로지 대기 중인 프로세스들 중 하나에 의헤서만 야기도리 수 있는 이벤트
서로를 가지고 있고 서로를 원하는 상태
높은 우선순위 프로세스가 낮은 우선순위 프로세스들에 의해 커널 데이터를 읽거나 변경할 필요가 있을 때
보통 락이 해제될떼까지 낮은 우선순위 프로세스는 기다려야함
라이브니스 문제는 우선순위 역전 문제로 알려져 있고, 3개 이상의 우선순위를 가진 시스템에서만 발생
우선순위 상속 프로토콜을 구현하여 해결함
더 높은 우선순위 프로세스가 필요로 하는 자원에 접근하는 모든 프로세스는 문제가 된 자원의 사용이 끝날 때까지 더 높은 우선순위를 상속받는다.
자원 사용이 끝나면 원래 우선순위로 돌아감