Move AssetServerStats from AssetInfos to AssetServer

[Mysvac]

Objective

bevy_asset: move AssetServerStats struct from AssetInfos to AssetServer.

In previous versions, adding stats.started_load_tasks required acquiring a write lock on AssetInfos, which was inefficient and prone to deadlocks (e.g., the deadlock fixed by #23980).

Now started_load_tasks has been changed to an atomic variable and moved into AssetServer, eliminating the deadlock issue entirely.

Note that acquiring read-write locks inherently requires more atomic operations, so the new implementation also achieves better performance.

Testing

• cargo test bevy_asset, passed

---

Showcase

Click to view showcase

pub(crate) struct AssetInfos{
    // .....
    // stats: AssetServerStats, // removed
}

pub(crate) struct AssetServerData {
    infos: RwLock<AssetInfos>,
    // .....
    stats: AssetServerStats, // <- now
}

pub(crate) struct AssetServerStats {
    pub started_load_tasks: AtomicUsize,
}

[andriyDev]

I'm not very excited about this change personally. It takes something simple (counting the number of loads), and makes it a whole atomics thing which is inherently more complex.

The additional mutex locks are a little sad, but they are also for "low traffic" APIs like load_folder and load_untyped_async, so I don't care that much about them.

[andriyDev]

Relaxed ordering makes me nervous. It means there's no guarantee afaik that we actually see this increment, whether in the tests or in an actual app.

[Mysvac]

@andriyDev

Visibility is unlikely to be a real problem. In single-threaded mode, there's no need to consider ordering — visibility is guaranteed. In multi-threaded mode, while Relaxed doesn't guarantee timely visibility, atomicity is still guaranteed: all add operations are effective and never conflict. Diagnostic functions using Relaxed may not always see the absolute latest value under high contention, but as diagnostic information, it's accurate enough. In multi-threaded environments, there might be slight delays due to visibility issues, but thanks to atomicity, no data will be lost.

Additionally, even if we change the add function to Release ordering and the diagnostic function to Acquire ordering to ensure visibility, the performance is still significantly faster than using a read-write lock. You can briefly check the implementation of a read-write lock — it uses a more complex atomic counter. In the original bevy_asset implementation, the read-write lock wasn't reused well — most modifications required Acquire + Release for locking plus a Release for unlocking — that's two atomic operations, plus some extra computation.

In fact, the overhead of atomic operations is negligible compared to I/O itself. The main goal here is diagnostic information — modifying it shouldn't involve complex issues like deadlocks.

If Relaxed ordering is not acceptable, we should use stricter ordering rather than falling back to a read-write lock.

[Mysvac]

Note, visibility in tests is guaranteed even with Relaxed.

First, App itself runs in a single thread — no ordering needed at all.

For internal multi-threaded functions like run_schedule and par_query, the TaskPool::scope implicitly provides synchronization. That means subsequent operations are guaranteed to see changes made by previous operations inside the scope. This ensures visibility across App statements (later operations always see earlier results) without requiring explicit memory ordering.

---

Normally, because of the TaskPool scope, the current frame's (or schedule stage's) diagnostic function can at least see the previous frame's (or stage's) results. (The after/before in Schedule also imply memory ordering.)

For systems without explicit ordering in the current frame, no extra guarantees are needed — they're already unordered by design.