rescrv
atomic_add should return new value
I agree, without returning the new value the atomic functions are useless in a lot of situations.
When they don't return the new value you have to do a get, cond_put combination in a loop :(
iirc it was waiting for protocol changes or something like that isn't as simple as it looks.
It was possibly discussed in detail by rescrv on the lists at some point, but I understand the gist of it and why it's a pain to implement.
Being atomic meant that the instructions could be applied in any order, or even bulk-applied, while the consensus is in a state of flux.
To have instructions return the value would require an additional level of synchronisation and overhead, not to mention protocol changes.
I hope that makes sense, and given the get/cond_put combination works in a loop there is a solution to what I wanted to do, albeit not in the ideal way.
I am happy with the trade-off, as the advantages of the way atomic instructions work in HyperDex outweighs the performance and synchronisation overheads of changing it to return a value.
I don't know if any of this is correct, would be handy to get feedback on it at some point.