Repository navigation
Naming convention for wait/notify instructions #145
Description
Activity
The table or memory argument will be embedded in the opcode, so atomic.notify (in the text format) without a memory or table argument can be interpreted as the existing notify-on-memory; atomic.notify with an argument would be disambiguated by the argument:
atomic.notify (table $t). For wait, i32 and i64 both designate memory operations; the table operations could just beatomic.wait (table $t).Hm, that would be really odd. All existing table/memory/global instructions have the respective entity index in plain form. For example, we don't write
get (table $x)andget (global $x)either.Of all of these, I think I prefer
memory.atomic.wait32. It keeps the precedent that we prefix withmemory., and aligns well with things likei64.atomic.store32. It's not a particularly pretty name, but neither isi64.atomic.rmw32.cmpxchg_u. I imagine both will be relatively rare, so we shouldn't worry too much about their length.SGTM
- added a commit that references this issue
on Jan 23, 2020 - added 2 commits that reference this issue
on Feb 4, 2020 - added a commit that references this issue
on Sep 26, 2026
The threads proposal as is is limited to shared memories, but we probably want to generalise the language to other shared entities eventually, e.g., globals or tables. At that point, it might be conceivable that we may want to introduce not just atomic get/set for those, but also wait/notify instructions.
However, the current naming scheme for wait/notify instructions does not make explicit that they are operating on a memory. In the interest of forward compatibility, should we fix that? It might also be nice for improved consistency with other memory instructions.
Bikeshedding possibilities:
memory.atomic.notify,i32.memory.atomic.waitmemory.atomic.notify,memory.i32.atomic.waitmemory.atomic.notify,memory.atomic.wait32Admittedly, neither pair is particularly pretty. Thoughts?