Naming convention for wait/notify instructions

[rossberg]

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.wait
• memory.atomic.notify, memory.i32.atomic.wait
• memory.atomic.notify, memory.atomic.wait32

Admittedly, neither pair is particularly pretty. Thoughts?

[lars-t-hansen]

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 be atomic.wait (table $t).

[rossberg]

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) and get (global $x) either.

[binji]

Of all of these, I think I prefer memory.atomic.wait32. It keeps the precedent that we prefix with memory., and aligns well with things like i64.atomic.store32. It's not a particularly pretty name, but neither is i64.atomic.rmw32.cmpxchg_u. I imagine both will be relatively rare, so we shouldn't worry too much about their length.

[rossberg]

SGTM