Currently the hashtable and the storage db, as direct conseuquence, allow only blind updates but for certain kind of operations a RMW pattern is required.

For example the redis set command has 2 flags, NX and XX, which make it hard to atomically decide what needs to be done without a RMW operation.

Because RMW opertions are going to be slower than the normal blind updates it's necessary to implement them side by side to the blind operations introducing 3 new functions in the hashtable:

• hashtable_op_set_rmw_start
• hashtable_op_set_rmw_commit
• hashtable_op_set_rmw_rollback

The hashtable_op_set_rmw_start function will have to perform the initial index search and return the bucket to be used (existing or new) and the value in the bucket.
The needed behaviour matches what hashtable_mcmp_support_op_search_key_or_create_new does behind the scenes so it can easily be a wrapper of that function once the necessary bits and pieces required are added.

The hashtable_op_set_rmw_commit instead will have to complete the operations, saving the new value in the bucket as needed.

The hashtable_op_set_rmw_rollback function instead will have to revert the operations carried out by hashtable_mcmp_support_op_search_key_or_create_new because under the hood that function marks a bucket as occupied if during the initial search one with a matching hash and key wasn't found.

Both hashtable_op_set_rmw_commit and hashtable_op_set_rmw_rollback will have to release the locks as necessary.

The work to be carried out on the hashtable can be thought almost as simply splitting the hashtable_mcmp_op_set function into 3 separated parts.

The storage db will simply have to expose this interface wrapping it to work with the entry indexes.