Advanced Rust test (Advanced)

Sample questions

5 sample questions from the Advanced Rust test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. Which type should be used to safely box a trait object for use in a multi-threaded context where the trait must implement `Send` and have a static lifetime?

   1. Box<dyn 'static>
   2. Box<dyn Send + 'static>
   3. Box<dyn Trait>
   4. Box<dyn Sync>

   Answer: B. Box<dyn Send + 'static>

   When boxing a `dyn Trait` for use across threads, it's necessary for the trait object to implement `Send` and have a static lifetime to ensure it can be safely moved between threads. `Box<dyn Send + 'static>` ensures both safety and thread compatibility. `Box<dyn Trait>` lacks explicit `Send` and `static` guarantees, `Box<dyn Sync>` is for shared access, and `Box<dyn 'static>` lacks `Send`.

2. Which statement correctly describes how the Sync trait is implemented in Rust?

   1. The Sync trait is not implemented for any types that are Send.
   2. The Sync trait is automatically implemented for types that are Send and have no interior mutability.
   3. The Sync trait is manually implemented for all types that are Send.
   4. The Sync trait is implemented for all types that have interior mutability.

   Answer: B. The Sync trait is automatically implemented for types that are Send and have no interior mutability.

   The Sync trait is implemented automatically for types that are Send and have no interior mutability. This is because Sync ensures that a type can be safely shared between threads, and if a type is Send, it can be moved between threads. However, if a type has interior mutability, it may not be safe to share between threads, and thus Sync is not automatically implemented for such types.

3. What is a common performance issue when using `tokio::spawn` with a future that holds large amounts of data in memory?

   1. It improves performance by allowing the runtime to manage memory optimally.
   2. It can lead to poor performance due to unnecessary memory allocations and increased latency.
   3. It has no impact on performance as the async runtime handles data efficiently.
   4. It is only a concern in blocking code, not in async code.

   Answer: B. It can lead to poor performance due to unnecessary memory allocations and increased latency.

   Using `tokio::spawn` with a future that holds a large amount of data in memory can lead to poor performance due to unnecessary memory allocations and increased latency, as the data must be copied across threads. This is a common mistake when not considering the implications of moving data across threads in async contexts.

4. What is the default behavior of Tokio's task scheduler when it comes to task execution?

   1. Tokio schedules tasks in a single-threaded manner, ensuring strict sequential execution of all tasks.
   2. Tokio uses a multi-threaded scheduler by default, which allows tasks to be executed on different threads, enabling better utilization of multiple CPU cores.
   3. Tokio randomly assigns tasks to either threads or processes based on the current system load.
   4. Tokio schedules tasks using a round-robin algorithm on a single thread, ensuring fair execution time for all tasks.

   Answer: B. Tokio uses a multi-threaded scheduler by default, which allows tasks to be executed on different threads, enabling better utilization of multiple CPU cores.

   Tokio's default task scheduler is multi-threaded, which allows tasks to be distributed across multiple threads and CPU cores. This improves parallelism and performance on multi-core systems. The other options describe incorrect or incomplete behaviors of Tokio's task scheduling.

5. What is the thread-safety status of `Rc<RefCell<T>>` in Rust?

   1. Rc<RefCell<T>> is both Send and Sync, so it can be safely shared across threads.
   2. Rc<RefCell<T>> is Send but not Sync, so it can be shared across threads with caution.
   3. Rc<RefCell<T>> is Sync but not Send, so it can be shared across threads with caution.
   4. Rc<RefCell<T>> is neither Send nor Sync, so it cannot be shared across threads safely.

   Answer: D. Rc<RefCell<T>> is neither Send nor Sync, so it cannot be shared across threads safely.

   The `Rc<RefCell<T>>` type is not `Send` or `Sync` because `Rc` is not `Send` or `Sync`, and `RefCell` is not `Sync`. This makes it unsafe to share `Rc<RefCell<T>>` across threads. For thread-safe shared mutable state, `Arc<Mutex<T>>` is the recommended alternative.