In native lock-free programming, a tricky issue is the ABA problem, which is caused by two or more atomic mutations by other threads, occurring between an observer thread checking on a shared state variable.
https://en.wikipedia.org/wiki/ABA_problem
The common elegant solution for this is to use auxiliary information, which typically ends up with a shared state block of "2x sizeof(ptr)" kind of a setup. Native compilation targets allow performing atomic operations on such 128-bit quantities, on 64-bit platforms.
When porting Unity to use WebAssembly's Memory64, we now find ourselves in a pickle with this scheme. Multithreading libraries that Unity uses, perform 128-bit atomic operations on shared memory (the usual: load/store/cas/exchange/add/and/or/xor).
We are looking at removing these 128-bit CAS support in the library code that assume its existence. Have there been considerations for adding 128-bit atomic operation support to multithreading+memory64 modes, or would that be something possible to consider?
In native lock-free programming, a tricky issue is the ABA problem, which is caused by two or more atomic mutations by other threads, occurring between an observer thread checking on a shared state variable.
https://en.wikipedia.org/wiki/ABA_problem
The common elegant solution for this is to use auxiliary information, which typically ends up with a shared state block of "2x sizeof(ptr)" kind of a setup. Native compilation targets allow performing atomic operations on such 128-bit quantities, on 64-bit platforms.
When porting Unity to use WebAssembly's Memory64, we now find ourselves in a pickle with this scheme. Multithreading libraries that Unity uses, perform 128-bit atomic operations on shared memory (the usual: load/store/cas/exchange/add/and/or/xor).
We are looking at removing these 128-bit CAS support in the library code that assume its existence. Have there been considerations for adding 128-bit atomic operation support to multithreading+memory64 modes, or would that be something possible to consider?