[Rust] 표준 Mutex와 tokio Mutex

비동기 Rust를 접한 사람들이 혼란을 겪을 만한 부분 중 하나가 바로 Mutex다.

표준 라이브러리에도 Mutex가 있는데, 비동기 런타임인 tokio에도 자체 구현 Mutex가 있기 때문이다.

뭐가 다르고, 뭘 써야하는걸까?

tokio에서 제공하니까 tokio를 쓰는 상황에서는 항상 적합하다고 생각하기 쉽지만, 꼭 그렇지는 않다.
tokio에서도 기본적으로는 표준 뮤텍스를 쓰는 것을 권장하기 때문에, 내부 동작 방식과 tradeoff를 이해하고서 선택해야 한다.

API 비교

대략적인 사용 방법은 비슷하나, 세세한 부분에서 다르다.

표준 뮤텍스는 현재의 OS 스레드를 블락할 수 있는 형태로 동작하며, Result를 반환한다.
Result를 반환하는 이유는, 뮤텍스틀 잡은 채로 스레드가 패닉으로 죽으면 "poison" 상태가 되어 뮤텍스 사용을 잠가버리는 동작을 가지기 때문이다.

tokio 뮤텍스는 현재의 tokio Task를 블락하는 형태로 동작하며, 락을 잡는 행위 자체가 Future 기반으로 동작한다. 그리고 이건 poison 상태가 없어서 실패여부 체크가 없다.

tokio Mutex Internal

그럼 tokio의 Mutex는 어떻게 만들어진 녀석일까?
사실 이건 Mutex를 완전하게 만들어낸건 아니고, 표준 Mutex를 복잡하게 래핑해둔 래퍼에 가깝다.

들어가보면 자체 구현 세마포어를 내장하고

그 세마포어는 또 내부 표현용 뮤텍스를 갖고 있는데

그 세마포어는 표준 뮤텍스의 래퍼다.

그리고 자체적인 대기열을 내장하고 있다.
그래서 tokio의 Mutex lock은 FIFO 기반으로 동작하며, 최소한의 공정성을 보장한다.

공정성 (Fairness)

표준 뮤텍스의 경우에는 공정성이 존재하지 않는다.
먼저 기다렸다고 해서 먼저 lock을 점유하는건 아니라는 것이다.
그래서 스레드 처리의 공정성이 많이 떨어질 수 있다.

반면 tokio의 뮤텍스는 FIFO 기반의 큐를 사용해서 최소한의 공정성이 보장된다.
먼저 기다렸다면, 먼저 lock을 획득할 수 있다.

스레드 차단 문제

표준 뮤텍스는 lock을 실행할때 대기가 발생할 경우, 현재 함수를 스레드에서 차단할 수 있다.
이 말인즉슨 현재 함수를 OS의 스케줄러에 집어넣고 진짜 실행을 멈춘다는 것이다.

이 방식은 std::thread를 쓰는 방식에서는 완전히 의도된 동작이고 효율적이지만, tokio를 쓰는 상황에서는 의도와 다르게 동작할 수 있다.
tokio의 Task는 여러개의 Task가 하나의 OS 스레드 위에서 나뉘어 실행될 수 있고, OS 스레드를 블락하면 그 OS 스레드에 소속된 Task들이 전부 차단되는 부작용을 야기할 수 있기 때문이다. 그래서 의도치 않은 데드락을 유발할 수 있다.

반면 tokio Mutex는 lock().await을 실행할때 대기가 발생한다면, 멈추되 다른 Task에게 자연스럽게 스레드 사용을 양보할 수 있다.

Mutex 점유 상태에서의 await

표준 뮤텍스는 근본적인 한계를 가지고 있다.
lock을 점유한 상태에서 await을 사용하는 것이 불가능하다는 것이다.

표준 뮤텍스는 Send를 구현하나, 표준 뮤텍스의 Guard가 Send를 구현하지 않고, await 호출은 반드시 Send를 요구하기 때문이다. 기본적으로 MutexGuard는 다른 스레드에 전송되는 것을 고려하지 않은 타입이다.

근데 await을 호출하게 되면 해당 함수는 tokio runtime에 제어권을 넘기게 되고, 해당 함수가 다른 스레드에서 재실행될 수도 있음을 뜻하게 된다.
표준 뮤텍스는 이런 것을 상정한 기능이 아니기 때문에, 만약 허용이 되었다고 해도 오동작을 했을 것이다.

이런 상황에서는 반드시 tokio Mutex를 써야 한다.

리소스 효율성

그럼에도 불구하고 tokio의 Mutex는 기본적으로 표준 Mutex보다는 비용이 많이 든다.

그래서 CPU 집약적인 워크로드라면, 그리고 lock 점유 시간이 짧은 경우라면 표준 뮤텍스를 쓰는 것이 강력하게 권장된다. 예를 들어 코어 스레드 20개에 빅데이터를 올리고 분할해서 연산하는 경우라든지...

반면 I/O 집약적인 워크로드라면, tokio Mutex를 쓰는 것이 보다 효율적이다. 그리고 lock 점유 시간이 길다면 더욱 그렇다. 그래서 사실 일반적인 경우에는 tokio Mutex를 쓰는 편이 더 자연스럽긴 하다.
애초에 async 런타임 자체가 I/O 집약적인 경우를 위해 설계된 것이기도 하고.

그래서

일반적인 경우에는, tokio Mutex를 쓰는 것이 대체로 더 나을 수 있다.

tokio 뮤텍스가 적절한 곳에 표준 뮤텍스를 쓰면 컴파일조차 안되거나 예상치 못한 문제를 일으킬 수 있는 반면에,
표준 뮤텍스가 적절한 곳에 tokio 뮤텍스를 쓰는건 미미한 성능 저하(CPU 바운드) 정도가 전부이기 때문이다.

내가 볼 때는 tokio 뮤텍스를 먼저 써보고 성능에 문제가 있다면 표준 뮤텍스를 써도 충분하다.

참조
https://stackoverflow.com/questions/73840520/what-is-the-difference-between-stdsyncmutex-vs-tokiosyncmutex
https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html
https://blog.naver.com/sssang97/224019441610
https://www.linkedin.com/pulse/comparison-between-stdsyncmutex-tokiosyncmutex-async-rust-nadiger-3tnlc/