CommandBuffer Threadsafe?

[KloBiX]

@friflo edit: format C# code

Is the "CommandBuffer" not thread-safe? I am spawning around 1000 elements, and beyond a certain point, I receive this error message:

System.InvalidOperationException: Playback - entity not found. Delete entity, entity: 638 at Friflo.Engine.ECS.CommandBuffer.ExecuteEntityCommands() at Friflo.Engine.ECS.CommandBuffer.Playback()
Here is my code

protected override void OnUpdate()
{
    CommandBuffer cmdBuffer = Query.Store.GetCommandBuffer();
    var elementJob = Query.ForEach((transients, entities) =>
    {
        var counter = 0;
        foreach (ref var transient in transients.Span)
        {
            transient.LifeTime -= Tick.deltaTime;
            if (transient.LifeTime <= 0) {
                cmdBuffer.DeleteEntity(entities[counter]);
            } else {
                transient.Position += transient.Velocity * Tick.deltaTime;
            }
            counter++;
        }
    });
    elementJob.JobRunner = runner;
    elementJob.RunParallel();

    cmdBuffer.Playback();
}

[friflo]

Hi @KloBiX,

thanks for reporting this.

In my first answer I wrote:
"The intention is: CommandBuffer must be thread-safe"

After diving into this I took a different decision.
So - as before - CommandBuffer is NOT thread safe. I fixed the documentation.

It is a valid use case to use a CommandBuffer in single threaded queries.
In this case the cost for a redundant lock is too high. ~50 ns per lock.

Instead I added CommandBuffer.Synced. This property must be used in parallel (multi threaded) queries.
Its interface is same as CommandBuffer.

So please use the new Synced property. E.g.

var cmdBuffer = Query.Store.GetCommandBuffer().Synced;

I also fixed a bug that was specific to the last parameter in Query.ForEach((transients, entities) when used in a parallel query.
The bug was: It returned always the same entities.
In single threaded queries it was - and still is - fine. The parameter entities is of type ChunkEntities.

Recommendation
In case of applying massive changes with a command buffer. The single threaded version is faster.
I made a test using a separate buffer for each thread to enable an implementation without locks.
It was slower than a the simple single thread solution.

Just published the fixed package to nuget. Version: v2.0.0-preview.7

Note: I reproduced your exception with:
https://github.com/friflo/Friflo.Json.Fliox/blob/engine/Engine/src/Tests/ECS/CommandBuffer/Test_CommandBuffer_GitHub_50.cs

[KloBiX]

glad to know :)

[friflo]

hey @KloBiX,

see my updated answer.

[friflo]

hey @MaansenV,

I guess your code was used as template for the bug above. So I added this comment to let you know.