When I call Hashtbl.randomize (), I believe that I want the guarantee that all further hash-table creations will be randomized. With the proposed PR, I get a weaker guarantee: all further hash-table creations on the current domain and its transitive children will be randomized. This is equivalent if the call happens before spawning any domain, but not in the general case of calling the function from "some" domain. I'm a bit nervous about this inequivalence.

We could consider the following:

• Keep a single configuration state, using an atomic boolean variable. I think this option has my preference: in theory domain-local storage avoids synchronization costs for reading this option at hashtable-creation time, but in fact I would expect that reading from an atomic boolean is fast enough, and the domain-local code is significantly more complex, at least conceptually.
• Forbid setting the flag once several domains have been spawned, and fail with an error. Meh.
• Add an option to the DLS interface to mutate a value for all domains where the corresponding key is defined. This could be difficult to implement (does it require a stop-the-world? meh) and it may be a dangerous option to offer to the user.

So I guess my question is: do we want domain-local state here or really global (atomic) state?

Like @gasche I would prefer the setting for hash table randomization to be an atomic global rather than per-domain. A per-domain setting for the temporary directory makes perfect sense, but the hash table randomization setting is peculiar, in particular because it (purposefully) can be changed only once.

Applications that want to protect against hash table collision attacks are supposed to call Hashtbl.randomize() before any hash table is created. If domains have already been spawned when Hashtbl.randomize() is called, something weird is happening but it can still be secure if these domains haven't created any hash table yet. For this scenario to work, the setting must be an atomic global. An inherited per-domain setting is less secure.

I agree that it also make sense to have randomized a global setting. However, I am not sure if it should be an atomic itself?

If multiple domains are at play, don't we have the problem that happen-after is no longer a total order? Restoring a order before setting randomized and other threads requires a synchronization mechanism that must be external to the randomized setting: For a domain waiting on randomized to change value to true can be more efficiently done by setting randomized to true on the domain.

Thus I have the impression that changing randomized to atomic would only help in the following scenario

by ensuring that the order 2 - 3 - 4 - 1 - 5 cannot happen even if the log operation is not atomic. But do we want to offer such synchronization guaranteed on the randomized status?

You're probably right that an atomic bool or a bool ref make little difference in this particular case. The good thing about atomic bool is that it makes the intent clear right in the source code: yes, this is not protected by a mutex, but we have determined that it's OK to access concurrently.

I also found a counter-example to my mental model of the issue:

I would expect that the second domain eventually see the write to randomized but this property only holds with an atomic.

I have switched to an atomic for randomized.