// -----------------------------------------------------------------------------
// file="SlabAllocator"
// Project: StgSharp
// Copyright (c) Nitload.
// SPDX-License-Identifier: MIT
// -----------------------------------------------------------------------------
using StgSharp.HighPerformance.Memory;
using System;
namespace StgSharp.HighPerformance.Memory
{
public static class SlabAllocator
{
///
/// Creates a new SLAB allocator instance with the specified configuration.
///
///
/// Initial number of objects that can be allocated.
///
///
/// Memory layout strategy for the SLAB allocator.
///
///
/// Whether to enable concurrent access support.
///
///
/// A new SLAB allocator instance.
///
///
/// Thrown when an invalid layout is specified.
///
///
/// Thrown when requesting unsupported configurations.
///
///
/// Important Threading Considerations: While SLAB
/// allocators themselves may be designed for single-threaded use, allocated objects are
/// frequently shared across multiple threads in real-world applications. Due to the
/// special implementation of expandable concurrent sequential SLAB allocators, they rely
/// on internal expansion locks to ensure that memory buffer expansions (which involve
/// copying the entire buffer to a new location) do not occur while other threads are
/// reading from allocated regions. Sequential Layout Limitations:
///
Sequential layout SLAB allocators cannot provide a single- threaded
/// version because:- They use contiguous memory
/// layout that requires buffer expansion when capacity is exceeded
///
- Buffer expansion involves copying all
/// existing data to a new memory location
- Without
/// proper synchronization, concurrent access to allocated objects during synchronization,
/// concurrent access to allocated objects during expansion would cause memory
/// corruption
- The expansion lock mechanism is
/// essential even if allocation itself is single- threaded
///
Chunked Layout:
/// Chunked layout allocators can optionally provide single-threaded versions since they
/// don't require buffer expansion and copying. Each chunk is allocated independently,
/// avoiding the memory relocation issues present in sequential layouts.
///
public static SlabAllocator Create(
nuint count,
SlabBufferLayout layout,
bool concurrentSupport = true
) where T : unmanaged
{
return layout switch
{
SlabBufferLayout.Sequential => concurrentSupport ?
new ConcurrentSequentialSlabAllocator(count) :
throw (new NotSupportedException("Non-concurrent version of sequential layout SLAB is not supported due to expansion lock requirements for memory safety during buffer expansion.")),
SlabBufferLayout.Chunked => concurrentSupport ?
new ConcurrentChunkedSlabAllocator(count) :
new ChunkedSlabAllocator(count),
_ => throw (new ArgumentOutOfRangeException(nameof(layout), layout, null))
};
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static SlabAllocator FromBuffer(
nuint buffer,
nuint count,
Action freeHandle
) where T : unmanaged
{
return new FixedSlabAllocator(buffer, count, freeHandle);
}
}
public abstract class SlabAllocator : IDisposable where T : unmanaged
{
public abstract nuint Allocate();
public abstract void Dispose();
public abstract void EnterBufferReading();
public abstract void ExitBufferReading();
public abstract void Free(
nuint index
);
public abstract SlabAllocationHandle ReadAllocation();
}
public enum SlabBufferLayout
{
Sequential,
Chunked
}
}