[Concurrency] Lock: 조건 변수 (Condition Variable)

Condition Variable은 대표적인 동시성 primitive 구현 중 하나다.

스레드 간에 기다리거나(wait) 알려서 깨워주는(notify) 등 동적인 상호작용에 최적화된 동기화 수단이다.
특히 오랫동안 기다리는 행위에 잘 최적화되어있고, 기다리는 동안 스레드를 차단해서 CPU 리소스를 소모하지 않는 것이 특징이다.

대부분의 언어에서 기본 모듈로 제공한다.
C++에서는 "condition_variable", Rust는 "CondVar", Go는 sync.Cond, Java는 Condition이란 이름으로 들어가있다.

다음은 간단한 예제 코드다.

go

rust
wait을 통해 스레드를 차단한 채 기다리고, notify를 통해 차단된 스레드를 깨울 수 있다.
모든 스레드를 깨우는 notify_all과 한놈만 깨우는 notify_one 2가지가 제공된다.

다른 동기화 수단과 유독 다른 부분은, 단독으로 쓰이는게 아니라 Mutex와 강하게 결합되어있다는 것이다.
go는 아예 CondVar의 생성자에 Mutex를 넣는 식으로 만들어져있다.

구현 수준에서도 mutex에 강하게 의존한다.
Rust의 경우에는 spin loop 없이 futex syscall을 곧장 날리는 형태로 구현이 된다.

futex 기반으로 즉시 wait을 걸고

notify를 보면 futex awake를 날린다.

활용 시의 이점

그래서 이걸 왜, 어떨 때 쓰는걸까? 처음 접한다면 꽤 혼란스러울 수도 있다.

기실 스레드 safe하게 기다리는 행위 자체는 Mutex로도 달성 가능한 것이다.
Mutex의 lock도 실제로 대기 상태에 빠지면 스레드를 차단한다.
물론 불필요한 spin loop가 있기 때문에 CondVar보다는 비용이 비싸다.

CondVar가 필요해지는 지점은, 공유되는 값 접근과 별개로 주체적으로 대기/재시작을 해야 할 때다.

Mutex의 lock에서 발생하는 대기는 단순하게 "하나 빼고 전부 대기"이기 때문에 이러한 논리를 구현하기 까다롭고 비효율적이다.

vs 채널

condvar와 직접적으로 비교할 수 있는 대상은 채널일 것이다.
https://blog.naver.com/sssang97/223131767231
채널은 condvar와 마찬가지로 빈번한 wait/wake 패턴 처리를 위한 동기화 수단이다.
receiver는 이벤트가 없으면 wait 상태에 빠지고, sender가 값과 함께 wake를 날리면 깨어나는 식으로 동작한다.

단일 스레드가 wait을 하고 1개 이상의 스레드가 notify를 하는(mpsc) 경우에는 채널이 더 적합하고 깔끔하다.

개인적으로는 채널을 먼저 고려해보고, receiver가 여러개가 되는 등 채널의 기능 범위를 벗어나게 되면 convar를 통해 제어를 하는 것을 권장한다.

참조
https://doc.rust-lang.org/stable/std/sync/struct.Condvar.html
https://medium.com/@abhisheksagar_59776/mutex-vs-condition-variables-e0a15b2226a4