Atomic and non-atomic operations on the same key

[lann]

Somewhat related to #51: what are the semantics of having both e.g. successful set and swap operate on the same key at the "same time"?

A few options come to mind:

• Undefined (don't do that)
• Result is either the new set value or the new swap value
  • or the old swap value? 🤔
• Namespace atomic keys; set('foo') and increment('foo') refer to two different keys

Any other options? I can't think of anything stronger that would be supported by enough implementations.

[thomastaylor312]

I think I lean towards "undefined" and saying if you're doing a swap, you shouldn't use set at the same time

[thomastaylor312]

We had a great conversation about this in the Wasm WG and the opinion here was that this is actually fairly well defined behavior across keyvalue stores. If you're using swap, anything done in context of that swap wins. When you use set, last write wins. So to summarize how I think this should be documented

Scenario 1

1. Call set with foo=bar
2. Call swap with foo=baz
   • The current value during the start of the swap is bar, even if something else has called set. If the value was updated, it will return a CAS error
3. Value is now baz after swap is complete

Scenario 2

1. Value is currently bar
2. Call swap with foo=baz
3. Call set with foo=qux
4. Value is now qux

[lann]

OK, I think for a distributed store that is equivalent to

Result is either the new set value or the new swap value

If we think that can be implemented across stores it sounds good to me.