Implementing a Custom Arc (Atomically Reference Counted) Smart Pointer in Rust

This challenge involves creating your own version of Rust's Arc<T>, a thread-safe reference-counting pointer. Implementing Arc will deepen your understanding of smart pointers, ownership, and concurrency primitives in Rust. This is a fundamental building block for many concurrent data structures and shared-state management scenarios.

Problem Description

Your task is to implement a custom smart pointer, MyArc<T>, that behaves similarly to std::sync::Arc<T>. MyArc<T> should allow multiple owners of the same data, ensuring that the data is deallocated only when the last owner goes out of scope. Crucially, MyArc<T> must be thread-safe, meaning it can be safely shared and manipulated across multiple threads concurrently.

Key Requirements:

• Reference Counting: MyArc<T> must maintain a reference count for the data it points to. This count should increase when a new MyArc points to the same data and decrease when an MyArc goes out of scope. The data should be deallocated when the count reaches zero.
• Thread Safety: The reference counting mechanism and the data itself must be safe to access and modify from multiple threads simultaneously. This implies using atomic operations for the reference count.
• Dereferencing: MyArc<T> should implement the Deref trait to allow access to the underlying data T.
• Cloning: MyArc<T> should implement the Clone trait. Cloning an MyArc should increment the reference count, not create a deep copy of the data.
• Data Ownership: The underlying data T should be owned by the MyArc and deallocated when the last MyArc pointing to it is dropped.
• No Data Mutation (by default): MyArc<T> should provide immutable access to the data. If mutable access is needed, it should be achieved through other thread-safe mechanisms (e.g., Mutex<T> or RwLock<T> wrapped within MyArc).

Expected Behavior:

• Creating an MyArc<T> should initialize the reference count to 1.
• Cloning an MyArc<T> should return a new MyArc<T> pointing to the same data and increment the reference count.
• When an MyArc<T> is dropped, the reference count should be decremented. If the count becomes zero, the underlying data T should be deallocated.
• Dereferencing an MyArc<T> (e.g., using *my_arc or my_arc.method()) should provide access to the contained T.

Edge Cases:

• Dropping the last MyArc: Ensure proper deallocation of the data when the reference count reaches zero.
• Cloning and Dropping in Concurrent Threads: Verify that the reference count is updated correctly and the data is not deallocated prematurely when MyArc instances are cloned and dropped across different threads.

Examples

Example 1: Basic Usage and Cloning

use std::sync::atomic::{AtomicUsize, Ordering};
use std::ops::Deref;
use std::rc::Rc; // For comparison/testing, not part of the solution

// Assume MyArc<T> is implemented as described.
// For demonstration purposes, we'll define a simple wrapper for the counter.
struct Counter {
    value: usize,
}

// Mock implementation of MyArc for demonstration context
struct MyArc<T> {
    ptr: *mut T,
    counter: Rc<AtomicUsize>, // Using Rc for the counter itself in this mock
}

impl<T> MyArc<T> {
    fn new(data: T) -> Self {
        // In a real implementation, this would involve Box::into_raw and allocation
        let boxed_data = Box::new(data);
        let ptr = Box::into_raw(boxed_data);
        MyArc {
            ptr,
            counter: Rc::new(AtomicUsize::new(1)),
        }
    }
}

impl<T> Clone for MyArc<T> {
    fn clone(&self) -> Self {
        self.counter.fetch_add(1, Ordering::SeqCst);
        MyArc {
            ptr: self.ptr,
            counter: Rc::clone(&self.counter),
        }
    }
}

impl<T> Deref for MyArc<T> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        unsafe { &*self.ptr }
    }
}

impl<T> Drop for MyArc<T> {
    fn drop(&mut self) {
        if self.counter.fetch_sub(1, Ordering::SeqCst) == 1 {
            // In a real implementation, this would deallocate the data
            // For this mock, we'll simulate deallocation by printing
            println!("Deallocating data!");
            // unsafe { Box::from_raw(self.ptr) }; // Real deallocation
        }
    }
}

// --- Actual Example Usage ---
let data = Counter { value: 10 };
let arc1 = MyArc::new(data);
println!("Initial ref count: {}", arc1.counter.load(Ordering::SeqCst)); // Expected: 1

let arc2 = arc1.clone();
println!("Ref count after clone: {}", arc1.counter.load(Ordering::SeqCst)); // Expected: 2

let arc3 = arc1.clone();
println!("Ref count after another clone: {}", arc1.counter.load(Ordering::SeqCst)); // Expected: 3

println!("Value accessed via arc1: {}", arc1.value); // Expected: 10
println!("Value accessed via arc2: {}", arc2.value); // Expected: 10

// When arc3 goes out of scope:
{
    let arc4 = arc3.clone();
    println!("Ref count before arc3 drops: {}", arc1.counter.load(Ordering::SeqCst)); // Expected: 4
} // arc4 drops here, ref count decrements

println!("Ref count after inner scope: {}", arc1.counter.load(Ordering::SeqCst)); // Expected: 3

// When arc3 eventually drops (at the end of this scope, if not moved)
// and arc2 eventually drops, and arc1 eventually drops, the data should be deallocated.

// In this mock, manual drop simulation for illustration:
// arc2.drop(); // simulated drop
// arc1.drop(); // simulated drop

Output (Conceptual):

Initial ref count: 1
Ref count after clone: 2
Ref count after another clone: 3
Value accessed via arc1: 10
Value accessed via arc2: 10
Ref count before arc3 drops: 4
Ref count after inner scope: 3
// Deallocating data! (This would appear when the last MyArc drops)

Example 2: Threaded Usage

use std::thread;
use std::sync::atomic::{AtomicUsize, Ordering};
use std::ops::Deref;
use std::rc::Rc; // For comparison/testing, not part of the solution

// Assume MyArc<T> is implemented as in Example 1.

// --- Actual Example Usage ---
let data = vec![1, 2, 3, 4, 5];
let shared_data = MyArc::new(data);
let mut handles = vec![];

let initial_ref_count = shared_data.counter.load(Ordering::SeqCst);
println!("Initial ref count in main thread: {}", initial_ref_count); // Expected: 1

for i in 0..5 {
    let cloned_data = shared_data.clone(); // Clone for each thread
    handles.push(thread::spawn(move || {
        println!("Thread {} accessing data: {:?}", i, *cloned_data);
        // The cloned_data MyArc will be dropped when the thread finishes.
    }));
}

// Wait for all threads to complete
for handle in handles {
    handle.join().unwrap();
}

let final_ref_count_in_main = shared_data.counter.load(Ordering::SeqCst);
println!("Ref count in main thread after threads: {}", final_ref_count_in_main); // Expected: 1 (all clones from threads have dropped)

// When `shared_data` drops here, the data should be deallocated.

Output (Conceptual - order of thread output may vary):

Initial ref count in main thread: 1
Thread 0 accessing data: [1, 2, 3, 4, 5]
Thread 3 accessing data: [1, 2, 3, 4, 5]
Thread 1 accessing data: [1, 2, 3, 4, 5]
Thread 4 accessing data: [1, 2, 3, 4, 5]
Thread 2 accessing data: [1, 2, 3, 4, 5]
Ref count in main thread after threads: 1
// Deallocating data! (This would appear when `shared_data` finally drops)

Constraints

• The MyArc<T> struct should store a pointer to the data T and a reference to its atomic counter.
• The atomic counter must be of type std::sync::atomic::AtomicUsize.
• All operations that modify the reference count (increment, decrement, load) must use appropriate Ordering values from std::sync::atomic (e.g., Ordering::SeqCst for simplicity, though Ordering::Relaxed might be sufficient for some operations if carefully analyzed).
• You must implement Clone and Deref.
• You must implement Drop to handle deallocation when the count reaches zero.
• The underlying data T should be heap-allocated using Box<T> and then converted to a raw pointer. Deallocation should be handled by converting the raw pointer back to a Box<T> within the Drop implementation.
• The implementation must be Send and Sync if T is Send and Sync respectively. This usually happens implicitly if you use raw pointers and AtomicUsize.

Notes

• This challenge requires a good understanding of Rust's memory management, smart pointers, and concurrency primitives.
• Be careful with raw pointers (*mut T). You will need to use unsafe blocks for dereferencing and deallocation. Ensure these blocks are as small as possible and that the invariants are maintained.
• Consider how to manage the lifetime of the data. Box::into_raw and Box::from_raw are key here.
• Think about the Ordering to use for atomic operations. Ordering::SeqCst is the strongest and safest default, but understanding weaker orderings can lead to more performant code in complex scenarios. For this challenge, SeqCst is perfectly acceptable.
• This is a simplified Arc. A real Arc might have optimizations or handle internal allocation differently. The focus here is on the core logic of atomic reference counting and thread-safe sharing.
• You will need to create your own MyArc struct and implement the necessary traits for it.