[QUESTION] Order Guarantees with the Async API

[barshaul]

Hey,

I have a question regarding execution order in the async API.
Given the following example:

Future<bool> set_res = async_redis.set("key", "val");
Future<Optional<string>> get_res = async_redis.get("key");
auto val = get_res.get(); // Will this always return "val"?

Since SET is not explicitly awaited before calling GET, can we rely on GET always executing after SET?
Does redis-plus-plus internally guarantee that commands are sent to Redis in the same order they are called, or should users explicitly ensure order using .get(), callbacks, or pipelining?

Thanks!

[sewenew]

Good question! The answer is: it depends...

First of all, let's make the following assumptions:

• there's no other clients modify or delete the key between your set and get command
• both set and get are sent successfully, and there's no connection is closed or broken
• both set and get run in a single thread. Although your code might run in a multiple-threading env

redis-plus-plus uses a connection pool to manage connections to Redis server. By default, the pool size is 1, i.e. only one connection in the pool.

If there's only one connection, the set and get commands are sent by one connection sequentially. And you're guaranteed that get always returns the value setting by set. Even if the code runs in multiple-threading env, and some other thread might sending commands on the same connection.

However, if you configured the pool with more than one connection. There's no such guarantees (even if you call future.get() explicitly or use callback). In a multiple-threading env, since there's a time window between get and set. Some other thread might send command in the time window, and the connection that used to send get might be occupied by the other thread. So set might be sent by a different connection. In this case, Redis server might process get before set. If you runs your code in a single thread env, the current implementation can guarantee that both get and set are sent by the same connection. However, I'd suggest you not take that guarantee, since the implementation might be changed in the future.

Regards