[Rust] Send와 Sync

Send와 Sync는 Rust가 지향하는 "안전한 동시성 프로그래밍"의 근간을 이루는 trait이다.

사실 Send와 Sync은 시스템적으로 대단한 기능을 하는 요소는 아니다. 의미를 부여하는 용도의 마커일 뿐이다.

이 2개의 트레잇이 특별한 점은 자동으로 구현이 된다는 것이다.
예를 들어 새 구조체를 정의할 경우, 내부 필드들이 전부 Send를 구현하고 있다면 그 타입은 자동으로 Send가 된다. 하나라도 Send를 구현하지 않는 타입이라면 Send를 구현하지 않는다.

Send와 Sync를 충족하지 않는 unsafe한 타입은 포인터 타입 등이 있다.

Send 트레잇

Send 트레잇은 스레드 생성시 해당 타입의 값을 안전하게 이동시킬 수 있는지를 의미하는 트레잇이다.
예를 들면, 이런 상황이다.

move 클로저를 통해 클로저 밖의 num 변수를 이동시켜서 값을 사용하고 있다.
이것은 num의 타입인 i32가 Send를 구현하고 있어서 가능한 일이다.

만약 아래와 같이 Send를 위반하는 타입을 정의한다면

바로 코드가 깨질 것이다.

스레드 안전성이 지켜지지 않는다고 한다.

이걸 해결하는 가장 단순무식한 방법은, Send를 강제로 구현시키는 것이다.

이 트레잇 구현 자체가 어떤 결과를 낳을지 알지 못하기 떄문에 unsafe가 붙는다.
그래서 이 타입을 구현하는 사람이 반드시 safe함을 보장하도록 구현을 해야 한다.

물론 가장 좋은 방법은 안전하게 Send가 되도록 구현해놓은 기존 타입들을 사용하는 것이다.

대표적으로 레퍼런스 카운팅 타입인 Arc가 Send를 충족하는 안전한 타입이다.
반면 Rc는 Send를 충족하지 않는다. Rc 자체가 thread-safe하지 않게 구현되어있기 때문에, clone은 마구 할 수 있더라도 그걸 스레드로 이동시키지는 않도록 잠금장치를 둔 것이다.

Sync 트레잇

Sync는 해당 타입이 스레드에 안전하게 참조로 공유될 수 있는지를 뜻하는 트레잇이다. Send가 값이 스레드로 옮겨질 수 있는지를 의미한다면, Sync는 여러 스레드에서 동시에 공유된 채로 사용할 수 있는지를 의미한다.

조금 헷갈릴 수도 있는데, Arc 같은 타입에 Sync를 구현하지 않는 타입을 넣어보면 이게 어떻게 사용되는지 알 수 있다. Cell은 Send를 구현하지만 Sync는 구현하지 않는 대표적인 타입이다.

Cell이 Sync를 구현하지 않는다고 불평을 내뱉는다.
Arc는 얼마든지 clone을 통해 복제될 수 있는데 반해, 정작 Cell이 복제된 상태에서의 thread safety한 동작을 보장하지 않기 때문에 (Sync를 구현하지 않기 때문에) 경고를 내뱉는 셈인 것이다.

Rust는 이러한 제약을 통해 thread에 안전한 타입과 안전하지 않은 타입을 분류하고 thread safety를 보장한다.

Send Sync 강제로 없애기

흔한 상황은 아니겠지만, Send나 Sync를 구현하지 않게 만들 수도 있다.
가장 간편한 방법은 비슷한 마커 타입인 팬텀 데이터로 안전하지 않은 타입을 구겨넣는 것이다.

이러면 Send와 Sync에 대한 자동 구현이 막혀버리고

에러가 발생한다.

참조
https://doc.rust-lang.org/nomicon/send-and-sync.html
https://stackoverflow.com/questions/59428096/understanding-the-send-trait