| 23:50 | <shu> | interesting limitation i just ran into during implementation of the shared struct prototype: on shared structs, Atomics operations that need to inspect the value for its operation cannot work for values that don't have identity |
| 23:51 | <shu> | for example, suppose there's a shared struct s with a field p that has the value 42 |
| 23:51 | <shu> | Atomics.load(s, 'p'), Atomics.store(s, 'p', whatever), Atomics.exchange(s, 'p', whatever) all work fine since they just treat the field as bits, there's no inspection of the contents |
| 23:52 | <shu> | Atomics.compareExchange(s, 'p', 42, whatever) or Atomics.add(s, 'p'), by contrast, can't be made to work on all implementations |
| 23:54 | <shu> | if an implementation chooses to box its values like V8, then '42' is not the integer 42, but a heap allocation. the implementation complexity for making those Atomics operations work is quite high, will be slow, and also defeats the purpose (lightweight synchronization). for heavier weight synchronization, use plain reads/writes and operations then synchronize separately on a mutex |
| 23:55 | <shu> | if an implementation NaN-boxes, like JSC and SpiderMonkey, maybe treating double bit patterns as arbitrary atomic64s might work for a subset of operations like compareExchange, but can't be made to work for arithmetic operations |
| 23:55 | <shu> | since there are no hardware instructions for atomic floating point math |
| 23:57 | <shu> | OTOH if we extend structs with field types, then Atomics could work on certain field types (like the existing TA types) |