The current Domain.DLS implementation is not (sys)thread-safe, because the implementations of the various state updating operations include safe points during which the runtime may switch between threads. I'll briefly highlight some specific scenarios of what can go wrong.

Consider the implementation of Domain.DLS.get:

Two threads on a single domain that concurrently get with the same key before init has been called may both end up calling init (so init would be called twice for a single key). That can happen because maybe_grow (which potentially allocates) includes a safe point and because init (which often allocates) itself may include a safe point. What can happen then is that the two calls of get return two different results (e.g. two different mutable records), one of which is stored in DLS.

Consider the implementation of the internal Domain.DLS.maybe_grow:

Two threads on a single domain that concurrently get with two different keys both call maybe_grow and may both end up allocating a new array for the DLS. This is possible because maybe_grow includes a safe point. Only one of the two arrays eventually ends up being stored as the DLS and one of the get operations ends up being undone. Furthermore if the two threads also perform set operations, some of those may end up being undone.

Here is an example interleaving (variation of the above) where the effects of DLS operations performed by Thread B vanish:

  Thread A                 Thread B
  get x starts

    <--- switch at a safe point --->
  
                           get y starts
                           get y ends
                           set y starts
                           set y ends  

    <--- switch at a safe point --->
  
  set_dls_state
  get x ends

The effects of both get y and set y vanish. Even just having get y vanish is a problem, because get may call init, which may return a mutable object, which might be mutated or stored outside of the DLS.