THE RETURN OF CONCURRENT ENTITY LOGICS

[dt-rush]

dear god what have i imagined

I have an ECS game engine (entity-component-system) in which I execute entity logics eveyr frame. Could i write a tiny DSL in which an entity specifies which other entities its logic func is going to R/W on (probably blackboard references, like it will store in its mind a list of friends etc...) and then it tries to sequentially acquire their corresponding R/W mutexes in sorted order of ID (thus guarantees no deadlocks).

ChatGPT

Yes, it seems that you have a good understanding of how to prevent deadlocks in your ECS game engine using a tiny Domain Specific Language (DSL) and sorted locking.

To recap your approach:

Have each entity specify which other entities it will read from and write to in a list. Sort this list based on the entity IDs. Sequentially acquire the R/W mutexes in the sorted order. This method is an application of the "lock ordering" technique, which ensures that deadlocks are avoided by always acquiring locks in a consistent order. By sorting the entity IDs, you establish a global order in which locks are acquired, thus preventing the circular wait condition that leads to deadlocks.

In this setup, you should be able to run your entity logic functions on parallel cores without deadlocks. However, there are a few things to consider for optimal performance:

Contention: As you use more parallel cores, contention for shared resources may increase. If contention is high, it can lead to performance degradation. You can mitigate this by designing your system to minimize the number of shared resources and by using lock-free data structures when possible.

Granularity: Ensure that the granularity of your locking is appropriate for your workload. If you lock on larger scopes, you may reduce contention but limit parallelism. Conversely, locking on smaller scopes can increase parallelism but also contention. Striking the right balance is important for optimal performance.

Load balancing: Distribute work evenly across parallel cores to avoid bottlenecks and ensure that all cores are utilized efficiently.

By considering these factors, you should be able to implement a robust parallel ECS game engine with minimal fear of deadlocks or performance issues.

[dt-rush]

Wait, I think they would also have to acquire R/W locks on any blackboard keys they want. I have a DSL already that specifies blackboard keys by strings. What to do? How do we define a total order on blackboard keys?

For example, this is the syntax for accessing a world blackboard

bb.$blackboardname.$key

where key can contain dots

and for accessing this entity's mind, we have

mind.$key

and let's say that for the entity's we have selected to acquire RW mutexes on, they each also have associated a string name. Examlpe, if we wanted to acquire for the entity "mind.friends.best" (DSL resolves to an *Entity), then it would have a name like "bestfriend", binding it to a simple name for the purpose of the logic. So then, we can also specify which bb properties and components etc. of the entity we will acess like

bestfriend[position] or bestfriend.wishes

ChatGPT

To define a total order on blackboard keys and entity-related properties, you can use a consistent sorting method. This will allow you to sort any combination of blackboard keys, entity names, and properties, ensuring a global order for acquiring locks.

Here's a way to achieve this:

First, combine the blackboard name, entity name, or mind identifier with the corresponding key or property. You can use a delimiter, such as a dot or a special character, to separate the components. Examples:

bb.$blackboardname.$key mind.$key bestfriend.$property Normalize the combined strings to ensure that the order is not affected by case sensitivity. You can convert all strings to lowercase or uppercase.

Sort the combined strings using lexicographic (dictionary) order. This will provide a consistent and total ordering for acquiring R/W locks.

For instance, if you have the following blackboard keys and entity-related properties:

bb.world.temperature mind.favoriteColor bestfriend.position bestfriend.wishes After normalizing and sorting them, you would get:

bb.world.temperature bestfriend.position bestfriend.wishes mind.favoriteColor By following this sorted order, you can acquire R/W locks on blackboard keys, entity properties, and components without deadlocks.

Keep in mind that this approach assumes that the keys and entity names are unique. If there's a chance that they might not be unique, you can add a unique identifier (such as an ID) to each key or entity to ensure the total ordering is maintained.

[dt-rush]

So the examples they gave didn't really work but for example, instead of bestfriend.wishes, we'd acquire 72.wishes (or whatever their ID is)