doc: minor changes

docs/md/config.md

@@ -44,10 +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.
-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.
+the user is the one who knows if a synchronization point is required.<br/>
+However, some internal static data shared between threads should be atomic when
+using `EnTT` from multiple threads, even when dealing with local storage. Define
+this macro without assigning any value to it to get the job done.
 
 ## 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. 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).
+make sense and cannot be turned around.<br/>
+When using multiple threads with `EnTT`, you should 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
+[this section](config.md#entt_use_atomic).
 
 ## Iterators