Memory64, multithreading and the 128-bit atomics operations to combat the ABA problem
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- wasm
- Domain
- distributed-systems, operating-systems
Research direction
No files or tests are named. Start by reviewing the WebAssembly threads and Memory64 requirements described here, especially the requested 128-bit load/store/CAS/exchange/add/and/or/xor operations; done means establishing whether these operations can be specified and supported in multithreading+Memory64 modes, or documenting the constraints that rule them out.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- WebAssembly
- Stars
- 767
- Forks
- 54
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/threads
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
WebAssembly/threads#254 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/threads#245 · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/threads#240 ·
-
Branch renaming Open
Difficulty 1/5 Under an hour Newbie friendliness 20/100
WebAssembly/threads#237 ·
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
WebAssembly/threads#234 · 3 comments ·
All issues in WebAssembly/threads
Similar issues
-
bug examples invalid iris
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
ai_reviewed
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
ydb-platform/ydb#53838 · 3 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
NovaSky-AI/SkyRL#2263 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
johanhaleby/occurrent#1106 ·
-
ShuffleManagerRegistry.register recursion guard is inverted, permits GlutenShuffleManager subclasses Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100