Atomic objects

[lars-t-hansen]

Atomic objects are abstractions of shared locations. (Each worker creates a front object for some shared locations.) They would have methods like compareExchange, add, subtract, get, set, etc. For integer locations the realization would be pretty trivial, since the Atomics API already provides most functionality. For float locations there would additionally have to be a spinlock behind the scenes to control access since there's no native CAS on floats.

We could also consider atomic objects that maintain multiple locations (ie a struct-like thing) and can CAS them as a unit, again using a spinlock probably; such objects would make it easier to implement lock-free data structures in client code.

The key is that there is no intercession by user code during the operation on the atomic object, so we control tightly the code that is executed and we can guarantee that - up to fairness - no agent has to wait indefinitely on performing the operation.

The design might take into account that at some point we may wish to expose these objects as standard APIs on the Atomics object.

Just because the atomic objects are lock-free does not mean that it's necessarily 100% safe to use them from the main thread - i'm thinking of issues with GC and JIT if they kick in while a lock is held - but it would be extremely nice if we could rely on it.

[lars-t-hansen]

This is subsumed by the Synchronic API, probably: see src/synchronic.js, though currently it only supports int types.