Thread safety info for functions. about entt HOT 9 CLOSED

Of course. I was copying back into the temporal array every time i wanted to update the system. Even with the copy and allocation it was still a big upgrade in performance. This would be pointless and you would lose performance if the complexity of each iteration is low.

from entt.

The whole entity-component system isn't thread safe out of the box. The README file already contains some notes about it.
Adding mutexes or whatever all around the codebase would ruin the performance in case you use it in single threaded applications, applications based on async stuff or if you have a go with the classical threading model of an ECS.
So, no need for a line to each function description in the documentation. It would be redundant.

If you care about it, I can add a dedicated section to the README where I mention it explicitly once and for all the cases.

from entt.

Yes, please. Do add a section specifically about thread safety.

from entt.

Not a problem. Maybe it's better if I add an extensive note to the Side Notes section. It already tells something to the readers about thread safety and views actually. There isn't much to say about this argument, but for the fact that I could write a book about how to deal with threads in an ECS!! :-)

from entt.

Added a note as mentioned above. Thank you for having pointed it out.

from entt.

Thanks for adding the note. Two comments, however:

1. It's better to put it in named section, which has a link in the Table of Contents. That way, it's obvious from the TOC that there's a section devoted to this topic. It's an important topic. Currently, it's burried in the side notes, so it's not apparent that it's mentioned in the docs. Even knowing that you added it, I couldn't find it, at first, and had to look at the commit history.
2. I mean no offense, but the info that you added isn't very useful. It's mostly justification, or telling the users what they need or want. Instead, it should state facts, and let the users make their own choices based on those facts. People know what they need. Maybe something along the lines of:

"The EnTT framework uses no locks or other synchronization primitives. As such, it requires external synchronization for [most|all] calls when used in a multi-threaded environment.

"Such and such methods are thread safe.

"Such and such methods may be called without external synchronization, as long as this and that requirements are met. Otherwise, they must be externally synchronized.

"Such and such methods must always be externally synchronized.

"Such and such methods must not be called from multiple threads because they use global or static data."

Thanks

from entt.

No offense, don't worry. I see what you say.
The problem is that it's much more complicated than this. It's not just a list like such and such ok, such and such no.

First of all, one should have a grasp of what are the possible approaches to the problem ECS and threads. Then I should explain in which cases a solution should be preferred and why. At this point we can explore the methods one at a time and say something about them for the particular solution, even though it's still different from the such and such description.
There are methods that are thread safe if and only if you did something before. As an example, the view member function template, is it thread safe? It depends. Did you know it?

These are consequences of some choices made in the past that gave you today a runtime tool that is faster than its compile-time counterparts and has a nicer API.
Well, this isn't for free. It has a buried complexity that makes it difficult to fully understand how it works and explain it in a few lines.
I was not joking when I said that I should write a book about thread safety and EnTT. Actually, more in general, about ECS and pick your argument, using EnTT as an example.

Unfortunately I'm doing all of this in my free time and I cannot provide users with a full explanation about thread based models for ECS, plus a detailed description of how to use EnTT and squeeze the best out of it in such a context.
That's also why I'm available for hiring. ;-)

Consider that part of the features you enjoy are the result of funded development or donations.
There had been only one (actually very big and well known) game company that invited me to the headquarter to know more about EnTT, wrote down all the information and hadn't even reimbursed the flight: no comment.

To be honest, I'm sorry if you don't get a full answer on the topic at the end of the discussion.
EnTT can be easily and freely used in a multi thread application (either a game or whatever). However, doing this requires quite a good grasp of its internals and it's far behond the goal of the README (that is already indecently large).

Probably I should open an account on patreon or write the above mentioned notes/book somehow, somewhere.
This is the first time someone asked me explicitly to do that. Let's see if some others follow you and thus doing it is worth it. ;-)

from entt.

Probably should write about what i did.
In the space battle i created, the target aquisition for the bullets was too expensive. Even with an acceleration structure, there were 3000 bullets trying to find all of the possible targets in an X radius to steer towards them.

What i did, is to use a raw view .count function to initialize an array, and then a normal view to copy all the bullet data from the view into that array (by storing pointers to the components).
After the copy was done, i did a Parallel For (given by unreal engine, does exactly what it sounds like, #pragma omp parallel for would do too) to iterate through that copy and do my logic. As i was storing pointers to the components, they were updated well.

I did not try to have multiple views iterating at the same time, as that would prove complex to check. A parallel for is dirt simple. and gave me a x5 speedup (on a ryzen) on the code i needed to speed up.

from entt.

@vblanco20-1

As i was storing pointers to the components, they were updated well.

Be aware that pointers and references to components can be invalidated in case you add or remove some other instances.

from entt.