Maximizing Multithreading Use of Entt

[Idealist-dreamer]

Hello~

I'm considering maximizing parallelism for entities. Based on documentation and some scattered answers, I'm treating each type of component as a container, and each entity as a container as well.

I've defined five operations: EntityQuery, EntityCreator, EntityDestroyer, ComponentReader, and ComponentWriter.

EntityQuery can only determine if an entity is valid or return a const view. EntityCreator can additionally create entities and return a non-const view. EntityDestroyer, in addition to these two, can also destroy entities. ComponentReader and ComponentWriter are similar.

The conflict judgment logic code is as follows:

bool checkOneOther(T t1, T t2, T x, T& other) {
  if (t1 == x) {
    other = t2;
    return true;
  }
  if (t2 == x) {
    other = t1;
    return true;
  }
  return false;
}

bool isConflict(const Mutex& other) const {
  if (checkOneOther(type, other.type, MutexType::EntityQuery, otherSide)) { 
      return otherSide == MutexType::EntityCreate || otherSide == MutexType::EntityDestroy; 
  } 
  
  if (checkOneOther(type, other.type, MutexType::EntityCreate, otherSide)) { 
      return otherSide == MutexType::EntityCreate || otherSide == MutexType::EntityDestroy; 
  } 
  
  if (checkOneOther(type, other.type, MutexType::EntityDestroy, otherSide)) { 
      return otherSide == MutexType::EntityDestroy || otherSide == MutexType::ComponentRead || otherSide == MutexType::ComponentReadWrite; 
  } 
  
  if (checkOneOther(type, other.type, MutexType::ComponentRead, otherSide)) { 
      return otherSide == MutexType::ComponentReadWrite && tag == other.tag; 
  } 
  
  if (checkOneOther(type, other.type, MutexType::ComponentReadWrite, otherSide)) { 
      return otherSide == MutexType::ComponentReadWrite && tag == other.tag; 
  } 

    return false;
}

The tag records the component's std::type_index, and I use this information to maximize the parallelism of the system using TaskFlow.

However, I consulted Google AI, and they said this would cause a conflict: "Although Pool<T> and Pool<U> are independent, the container storing these Pools (usually a std::vector<std::unique_ptr<base_pool>> inside the registry) is not thread-safe.

Risk: If thread A calls addDelayed<T> for the first time, and thread B calls addDelayed<U> for the first time, the registry will simultaneously attempt to assure (create) both Pools. This will cause push-back contention in the registry's internal Pool list, leading to a crash."

His meaning is that different components or entities in the entity do indeed use different pools, but the initial creation of the pools requires access to a unified object in the registry, which may cause data races in a multi-threaded environment. Is that correct?

[skypjack]

His meaning is that different components or entities in the entity do indeed use different pools, but the initial creation of the pools requires access to a unified object in the registry, which may cause data races in a multi-threaded environment. Is that correct?

The entity pool exists from the beginning. Component pools are lazily created on first use. So, yeah, that's kinda correct.
You can have a dry non-multi-threaded run on the first tick(s) to populate a registry, or just use registry.storage<T>() to force pool creation before entering the multithreaded code.