[Proposal] Add Rust-style AtomicUsize/AtomicIsize and GC-free SegQueue/ArrayQueue

[Molth]

Summary

This proposal introduces two sets of pure C# features ported from Rust's standard library and crossbeam-queue, to extend DotNext's atomic operation and lock-free queue capabilities. I have completed the full implementation, and I want to confirm the adaptation requirements before submitting a PR.

1. New Atomic Structure Encapsulation

Feature Overview

Add Rust-style atomic wrapper structures for common numeric types, including int, long, as well as platform-sized types AtomicIsize (nint) and AtomicUsize (nuint).

This set of wrappers unifies scattered Volatile and Interlocked API calls, and exposes explicit memory ordering parameters to control atomic memory behavior consistently following Rust atomic design.

Core Capabilities

• Covers most existing Interlocked atomic operations: read/write, exchange, compare-exchange, increment, decrement.
• Adds extended atomic bitwise operations: And, Or, Xor.
• Supports full memory ordering semantics: Relaxed, Acquire, Release, AcqRel, SeqCst.
• Provides two unified entry points for all atomic types:
  • T Load(Ordering order)
  • void Store(T value, Ordering order)
• Supports both 32-bit and 64-bit process environments.

Implementation Basis

Implemented based on standard .NET Unsafe and Interlocked APIs. The code can be refactored to match DotNext existing architecture and code style.
Source: AtomicHelpers.cs

2. GC-Free Lock-Free Queue: SegQueue & ArrayQueue

Feature Overview

Ported Rust crossbeam-queue's SegQueue and ArrayQueue to pure C#. The implementations work only with unmanaged types, suitable for GC-sensitive scenarios.

Core Features

• Fully GC-free, allocated on unmanaged memory.
• MPMC lock-free concurrent queue design.
• Pure C# cross-platform implementation.

Implementation Basis

Full pure C# port implementation: crossbeam-queue C# Port

3. PR Adaptation Consultation & Next Steps

All features are fully implemented. I intend to submit a PR to integrate them into DotNext. I would like to clarify the project requirements for adaptation:

• Code style, naming convention and namespace rules
• Unit test coverage and testing framework requirements
• XML documentation / annotation requirements for new APIs
• Target branch and commit message format
• How to integrate these atomic abstractions with DotNext's existing concurrency/atomic design

[sakno]

Hi @Molth , thanks for you suggestion. There is my review:

1. New Atomic Structure Encapsulation

public static object? Load(ref object? location, Ordering order) implementation doesn't support Ordering.Release and throws, same for Store and Ordering.Acquire. Moreover, Load and similar methods use branching, which adds additional performance overhead for every call.

Implementation of Ordering.Relaxed looks like a compiler-level barrier. However, JIT/AOT could inline Load or Store method, so the value at the memory location ref location could be cached once:

class MyClass
{
  private int field;

  public int M()
  {
    var x = Load(ref field, Ordering.Relaxed);
    DoSomethingElse();
    var y = Load(ref field, Ordering.Relaxed); // can be cached and turned into x
  }
}

The only way to express compiler-level barrier is to use NoInlining flag on the method, which is an overkill for another barrier types in your case.

Also, Load doesn't mutate the field, passing the location by ref instead ref readonly makes the method unusable for struct methods with non-mutating behavior (declared as readonly).

Typically, memory barriers are used in performance-critical paths, and additional branching has overhead comparable or even larger (in case of branch misprediction) that the overhead of the memory barrier itself.

For arbitrary value types that cannot be used with volatile keyword .NEXT provides generic Atomic<T> type, which provides atomic access to the value type of arbitrary size and based on SeqLock algorithm to reduce contention between readers.

One more thing: in .NET 10 there are generic versions exist of Interlocked.CompareExchange<T> and Interlocked.Exchange<T>, which makes them reusable for enums, all primitive types (including nint, nuint, bool), so no need in generic containers for them.

2. GC-Free Lock-Free Queue: SegQueue & ArrayQueue

It's not clear why these types are better than ConcurrentQueue<T>? Moreover, they are restricted to unmanaged element types only, which is a huge limitation that reduces their reusability in generic scenarios. Moreover, .NEXT has RingBuffer<T> type and public BoundedObjectPool<T> class based on it. It offers MPMC queue in efficient way, and works with any type - reference or value type.

[Molth]

@sakno Thank you very much for your response. I feel truly ashamed of my earlier behavior, thank you for your time and your valuable guidance, I really appreciate it. (^_^)