{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Which function should be used to create a new thread in Rust?","acceptedAnswer":{"@type":"Answer","text":"The thread::spawn function from the std::thread module creates a new execution thread. It takes a closure as parameter and returns a JoinHandle that allows waiting for the thread to finish using the join() method. This function is the main entry point for thread-based concurrent programming in Rust."}},{"@type":"Question","name":"What does the join() method return when called on a JoinHandle?","acceptedAnswer":{"@type":"Answer","text":"The join() method returns a Result where T is the return type of the thread's closure. If the thread completes normally, you get Ok(value). If the thread panicked, you get Err containing the panic information. This allows safely retrieving thread results or handling its errors."}},{"@type":"Question","name":"Why use the move keyword with a closure passed to thread::spawn?","acceptedAnswer":{"@type":"Answer","text":"The move keyword forces the closure to take ownership of captured variables instead of borrowing them. This is essential with thread::spawn because the new thread may outlive the scope where variables are defined. Without move, the compiler refuses because it cannot guarantee that references will be valid for the thread's entire lifetime."}},{"@type":"Question","name":"What is the role of the Send trait in Rust?","acceptedAnswer":{"@type":"Answer","text":"The Send trait indicates that a type can be safely transferred from one thread to another. Most primitive types and structures composed only of Send types are automatically Send. Types like Rc are not Send because their reference counter is not thread-safe. This trait is fundamental for guaranteeing memory safety in multi-threaded contexts."}},{"@type":"Question","name":"What is the role of the Sync trait in Rust?","acceptedAnswer":{"@type":"Answer","text":"The Sync trait indicates that a type can be safely referenced from multiple threads simultaneously. In other words, if T is Sync, then &T is Send. Types with non-thread-safe interior mutability like RefCell are not Sync. This trait complements Send to guarantee safety of concurrent access to shared data."}},{"@type":"Question","name":"What does mpsc mean in the context of Rust channels?","acceptedAnswer":{"@type":"Answer","text":"mpsc stands for Multiple Producer, Single Consumer. This channel type allows multiple threads to send messages to a single receiving thread. The Sender can be cloned to obtain multiple producers, but there is only one Receiver. This is the most common inter-thread communication pattern in the Rust standard library."}},{"@type":"Question","name":"How to create an mpsc channel in Rust?","acceptedAnswer":{"@type":"Answer","text":"The mpsc::channel() function returns a tuple (Sender, Receiver). The Sender is used to send messages with send() and the Receiver to receive them with recv(). This function creates an asynchronous channel with unlimited buffer. For a synchronous channel with limited buffer, use mpsc::sync_channel(n)."}},{"@type":"Question","name":"What happens when calling recv() on a Receiver whose all Senders have been dropped?","acceptedAnswer":{"@type":"Answer","text":"When all Senders associated with a channel have been dropped, recv() returns Err(RecvError). This means the channel is closed and no new messages will ever be sent. This mechanism allows cleanly detecting the end of communication and terminating receive loops elegantly."}},{"@type":"Question","name":"How to obtain multiple producers (Sender) for the same mpsc channel?","acceptedAnswer":{"@type":"Answer","text":"The Sender implements the Clone trait, so simply calling clone() on the existing Sender creates a new producer that sends to the same channel. Each clone is independent and can be moved to a different thread. The channel remains open as long as at least one Sender exists."}},{"@type":"Question","name":"Why is Rc neither Send nor Sync?","acceptedAnswer":{"@type":"Answer","text":"Rc uses a non-atomic reference counter for performance reasons. If Rc were shared between threads, multiple threads could modify the counter simultaneously, causing data races and memory corruption. For multi-thread sharing, use Arc which uses atomic operations for its counter."}},{"@type":"Question","name":"How to safely share mutable data between multiple threads?","acceptedAnswer":{"@type":"Answer","text":"To share mutable data between threads, use Arc>. Arc enables ownership sharing between threads (Send + Sync), and Mutex ensures mutual exclusion for modifications. Each thread must acquire the lock with lock() before modifying data, guaranteeing only one thread accesses it at a time."}},{"@type":"Question","name":"What is the difference between Mutex and RwLock?","acceptedAnswer":{"@type":"Answer","text":"Mutex only allows one access at a time (read or write). RwLock allows multiple simultaneous readers OR one exclusive writer. RwLock is more performant when reads are frequent and writes are rare, as readers don't block each other. However, RwLock has higher overhead than Mutex."}},{"@type":"Question","name":"What happens if a thread panics while holding a Mutex lock?","acceptedAnswer":{"@type":"Answer","text":"When a thread panics while holding a lock, the Mutex is marked as poisoned. Subsequent calls to lock() return Err(PoisonError) containing the guard. This allows detecting that protected data may be in an inconsistent state. The guard can be recovered with into_inner() if one wishes to continue despite the poison."}},{"@type":"Question","name":"What is the difference between mpsc::channel() and mpsc::sync_channel(n)?","acceptedAnswer":{"@type":"Answer","text":"mpsc::channel() creates an asynchronous channel with unlimited buffer: send() returns immediately without blocking. mpsc::sync_channel(n) creates a channel with buffer size n: send() blocks if the buffer is full until a message is consumed. With n=0, the channel is rendezvous: send() blocks until recv() is called."}},{"@type":"Question","name":"How to prevent deadlock when using multiple Mutexes?","acceptedAnswer":{"@type":"Answer","text":"To avoid deadlocks, always acquire locks in a consistent order throughout the program. If thread A acquires Mutex1 then Mutex2, all threads must follow the same order. Limiting lock scope to the minimum necessary and avoiding calling external code while holding a lock are also essential best practices."}},{"@type":"Question","name":"Which method to use to receive a message without blocking the thread?","acceptedAnswer":{"@type":"Answer","text":"The try_recv() method on Receiver attempts to receive a message without blocking. It returns Ok(message) if a message is available, or Err(TryRecvError::Empty) if the channel is empty, or Err(TryRecvError::Disconnected) if all Senders have been dropped. This allows periodically checking for messages while doing other work."}},{"@type":"Question","name":"What is a data race and how does Rust prevent them?","acceptedAnswer":{"@type":"Answer","text":"A data race occurs when multiple threads access the same memory simultaneously, with at least one write access, without synchronization. Rust prevents data races at compile time through Send and Sync traits and the ownership/borrowing system. The compiler rejects any code that could cause a data race, guaranteeing thread safety without runtime overhead."}},{"@type":"Question","name":"How to use thread::scope to avoid the move keyword?","acceptedAnswer":{"@type":"Answer","text":"thread::scope creates a scope in which threads can borrow data from the parent scope. Threads spawned in this scope are guaranteed to finish before the scope ends, so the compiler can prove borrows are valid. This avoids having to clone or use Arc to share read-only data with temporary threads."}},{"@type":"Question","name":"What type to use for an atomic counter shared between threads?","acceptedAnswer":{"@type":"Answer","text":"For an atomic counter, use AtomicUsize (or AtomicI32, AtomicU64, etc.) from the std::sync::atomic module. These types provide atomic operations like fetch_add() and load() without requiring a Mutex. They are more performant than a Mutex for simple operations on primitive values because they use CPU atomic instructions directly."}},{"@type":"Question","name":"What is the impact of Ordering in atomic operations?","acceptedAnswer":{"@type":"Answer","text":"Ordering specifies memory synchronization guarantees. Relaxed offers only atomicity without ordering guarantee. Acquire/Release create point-to-point synchronization between threads. SeqCst (Sequentially Consistent) guarantees a total order observable by all threads. Choosing the right Ordering is crucial for performance while maintaining correctness of the concurrent program."}}]}