doc: improve documentation on for `ENTT_USE_ATOMIC` (#1251)

docs/md/config.md

@@ -44,9 +44,10 @@ also limited to this library only.
 
 In general, `EnTT` does not offer primitives to support multi-threading. Many of
 the features can be split over multiple threads without any explicit control and
-the user is the one who knows if a synchronization point is required.<br/>
-However, some features are not easily accessible to users and are made
-thread-safe by means of this definition.
+the user is the one who knows if a synchronization point is required.
+However, some internal static data shared between threads *MUST* be made atomic
+when using `EnTT` in multiple threads, even when using local storage.<br/>
+Define this macro without assigning any value to it to make those variables atomic.
 
 ## ENTT_ID_TYPE
 

docs/md/entity.md

@@ -2366,11 +2366,11 @@ expedients.
 
 Finally, `EnTT` is configured via a few compile-time definitions to make some of
 its parts implicitly thread-safe, roughly speaking only the ones that really
-make sense and cannot be turned around.<br/>
-In particular, when multiple instances of objects referencing the type index
-generator (such as the `registry` class) are used in different threads, then it
-might be useful to define `ENTT_USE_ATOMIC`.<br/>
-See the relevant documentation for more information.
+make sense and cannot be turned around. When using multiple threads with `EnTT`,
+you *MUST* define `ENTT_USE_ATOMIC` unless you know exactly what you are doing.
+This is true even if each thread only uses thread local data.
+For more information, see:
+[configuring `ENTT_USE_ATOMIC`](config.md#entt_use_atomic).
 
 ## Iterators