OnceLock: initialize shared state once

Fix the declarations in the starter so that all workers share one cell and one initialization counter.

pub fn init_once(workers: usize) -> (u64, usize)

Start workers.max(1) threads. Each calls CELL.get_or_init with a closure that increments ATTEMPTS and returns 42. Wait for all workers to finish, then return the stored value and the counter.

The expected result is (42, 1) for every tested worker count, including zero. Keep the threaded implementation: returning this pair directly would skip the initialization exercise.

The workers need not arrive simultaneously. Whether they overlap or run one after another, they must observe the same initialized value. The initializer in this exercise does not panic, so it runs once. The static state also persists across repeated calls in the same process.

Why the starter needs static storage

The starter declares CELL and ATTEMPTS as const items. These provide values at their use sites, rather than shared mutable storage. Updating one temporary counter does not update a counter read elsewhere. Similarly, initializing a temporary cell does not initialize the cell used by the final get(), so the starter's expect panics.

Use static for each shared object. Both constructors can run in a constant initializer:

static CELL: OnceLock<u64> = OnceLock::new();
static ATTEMPTS: AtomicUsize = AtomicUsize::new(0);

The existing imports supply these types. Clippy's declare_interior_mutable_const and borrow_interior_mutable_const diagnostics help identify the original mistake.

Reading and initializing a OnceLock

Calls made after initialization reuse the value without rerunning a closure. If an initializer panics and unwinds, that panic reaches its caller and the cell remains uninitialized. A later call can try again. Avoid recursively initializing the same cell from its own initializer.

In this exercise, the counter only counts initializer calls. Relaxed atomic operations are sufficient: OnceLock handles publication of its value, and leaving thread::scope waits for the workers before the final counter read.

When LazyLock is useful

LazyLock stores its initializer when it is constructed. Dereferencing it or calling LazyLock::force initializes it on demand:

use std::sync::LazyLock;

static LABEL: LazyLock<String> = LazyLock::new(|| String::from("ready"));

fn main() {
    assert_eq!(LABEL.as_str(), "ready");
}

Choose it when one predefined initializer suits the application. OnceLock lets the caller supply initialization logic or a value later.

Their panic behavior differs. A panic during LazyLock initialization poisons that instance; later attempts to force its value also panic. OnceLock allows another attempt after an unwinding initializer panic.

Returning Err is different from panicking. A LazyLock<Result<T, E>> can cache an error as its initialized value. Likewise, OnceLock<Result<T, E>>::get_or_init stores an Err; it does not automatically retry it. Decide explicitly whether failures should be cached or retried.

use std::cell::RefCell;

thread_local! {
    static SCRATCH: RefCell<Vec<u8>> = const { RefCell::new(Vec::new()) };
}

fn main() {
    SCRATCH.with_borrow_mut(|buf| buf.push(1));
    std::thread::spawn(|| {
        SCRATCH.with_borrow(|buf| assert!(buf.is_empty()));
    }).join().unwrap();
    SCRATCH.with_borrow(|buf| assert_eq!(buf.as_slice(), &[1]));
}

A passing submission must compile, pass the tests, and pass clippy -D warnings.

References: OnceLock, LazyLock, and thread-local storage.