[Concurrency] Lock: 세마포어 (semaphore)

세마포어(semaphore)는 멀티스레드 환경에서 공유자원을 관리하는 동기화 방법론 중 하나다.
다익스트라가 고안했다.

논리적인 구조는 대략 이렇다.

atomic한 세마포어 제어 변수를 하나 둔다. (int a;)
이건 보통 정수이며, 한번에 최대 접근 가능한 스레드의 개수가 초기값이 되어야 한다.

각 스레드는 임계영역(critical section)이라는 세마포어 처리 구간을 둔다.

1. 임계영역에 들어갈때 세마포어가 열려있는 상태면 세마포어를 잠그고(a--) 임계영역을 수행한 뒤, 처리가 끝나면 세마포어를 다시 열어준다.(release, a++)
2. 임계영역에 들어갈때 세마포어가 닫혀있는 상태면(a==0) 열릴 때까지 기다린다.(wait)

기본적으로 세마포어 변수는 정수값이며, 0을 초과할 때 열려있다고 가정한다. 0이 되면 잠긴 것으로 취급한다.

세마포어의 용도

기본적으로는 자원의 충돌 방지보다는 동시에 처리 가능한 수를 제한하는, 사용량 제한 관점에서 더 잘 사용되는 편이다. 엄밀한 수준의 data race 방지를 원한다면 세마포어보다는 mutex를 쓰는 것이 일반적이다.

이진 세마포어: mutex

이 세마포어의 논리적 변종 중 하나가 일반적으로 많이 사용되는 뮤텍스(Mutex)다. - 구현 관점에서는 많이 다르다.

세마포어 카운트가 0/1만 되고, lock과 unlock 2개의 상태만 있다고 해서 binary 세마포어라고 부른다.

그래서 무조건 동시에 하나의 스레드만 접근할 수 있고, 충돌에 가장 안전한 편이다.
https://blog.naver.com/sssang97/223131650074

세마포어의 구현

세마포어의 구현법은 딱 정해져있지는 않다. Mutex가 일반적으로 OS의 mutex 기능에 의존한 채로 추가적인 최적화만 약간 하는 것과는 다르다.

그래도 내가 확인한 구현체들은 접근법이 대부분 비슷하긴 했다.
일단 count의 제어 같은건 확실하게 원자적 처리가 되어야 하므로, 대부분의 구현체는 그 기본적인 보장에 대한 부분을 Mutex에 의존한다.

tokio의 Semaphore의 경우를 예로 들면, Mutex와 Atomic 카운트를 하나 두는 것으로 구현을 한다.

그리고 나서는 LinkedList 기반으로 대기열을 구현하고 그런다.
빈 공간이 나면 대기열 기반으로, 대기자에게 접근권한을 주는 것이다.

Golang의 반-표준 구현체(golang.org/x/sync/semaphore)도 접근법은 다르지 않다.

여기서는 채널 기반으로 대기를 구현하더라.
동시 접근에 대한 보장은 똑같이 Mutex에 의존한다.