Answer.

Background:

Working with multithreading is a source of errors in most programming languages: data races, resource contention, and non-obvious bugs. Learning from the experiences of C++ and Java, the creators of Rust decided to embed thread safety mechanisms directly into the type system, so most errors are caught at compile time.

Problem:

In classical languages, programmers often have to rely on discipline and external tooling: the risks of transferring ownership of data, shared mutable memory, and lack of concurrent access control can lead to critical failures. A system was needed to guarantee the absence of memory races at compile time.

Solution:

In Rust, special types from the standard library are used for synchronization and data transfer between threads — for example, Arc, Mutex, and channels. The key roles are played by trait markers Send and Sync, which are automatically checked by the compiler. A type is considered thread-safe if:

only safe types can be shared between threads (Sync)
a type can only be sent between threads if it implements Send

Example code:

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];
    for _ in 0..10 {
        let counter = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            let mut num = counter.lock().unwrap();
            *num += 1;
        });
        handles.push(handle);
    }
    for handle in handles {
        handle.join().unwrap();
    }
    println!("Result: {}", *counter.lock().unwrap());
}

Key features:

Synchronization primitives Mutex, RwLock, and channels are thread-safe by contract
Access to data is passed through wrapper types (Arc, Mutex), not through pointers
The Send/Sync system does not allow erroneously sharing unsafe structures between threads

Trick questions.

Why can't Rc<T> be used for data transfer between threads?

Rc<T> does not implement the Send trait and is not thread-safe — its internal implementation relies on a non-blocking reference counting, leading to data races when accessed from multiple threads. For threads, use Arc<T>.

Can you manually implement Send or Sync for your own type to bypass compiler restrictions?

Yes, but it is extremely dangerous! Violating invariants (e.g., sharing a raw pointer) can lead to data races. Leave manual implementation only for experts who are fully confident in the thread safety of the type.

When can Mutex lead to deadlock in Rust, and how can it be avoided?

Deadlock can occur if the order of acquiring multiple mutexes is unstable or if the lock is nested recursively on a single thread (Mutex is not reentrant!).

use std::sync::Mutex;
let a = Mutex::new(0);
let _g1 = a.lock().unwrap();
let _g2 = a.lock().unwrap(); // panic: deadlock!

Common mistakes and anti-patterns

Using Rc instead of Arc for inter-thread access
Storing mutable references or raw pointers in types that are shared between threads
Forgetting to check unwrap when working with lock()

Real-life examples

Negative case

A developer used Rc<RefCell<T>> to pass state between threads in a web server. In local tests, it worked fine, but in production, race conditions appeared: sometimes variables "lost" their states, and at times the server crashed.

Pros:

Simple and concise code

Cons:

Dynamic races, crashes, irreparable bugs, security vulnerabilities

Positive case

Using Arc<Mutex<T>> when passing state, strictly adhering to Send/Sync, distributing work across threads via channels, no mutable shared data in threads.