`strand::running_in_this_thread()` false positive

I have the following code sample
(assume asio headers included and using directives present)

io_context _io_ctx;
auto _strand1 = make_strand(_io_ctx);
auto _strand2 = make_strand(_io_ctx);

asio::awaitable<void> g()
{
    auto ex = co_await asio::this_coro::executor;

    assert(_strand1.running_in_this_thread()); // *** This assertion should fail, but doesn't
    assert(_strand2.running_in_this_thread());

    // the following line can be replaced with `sleep(1)` to the same effect
    co_await steady_timer{ex, std::chrono::milliseconds{10}}.async_wait(use_awaitable);

    assert(!_strand1.running_in_this_thread()); // Here it works as expected
    assert(_strand2.running_in_this_thread());

    co_return;
}


asio::awaitable<void> f()
{
    auto ex = co_await asio::this_coro::executor;

    for (;;)
    {
        assert(_strand1.running_in_this_thread());
        assert(!_strand2.running_in_this_thread());

        co_await steady_timer{ex, std::chrono::milliseconds{5}}.async_wait(use_awaitable);

        assert(_strand1.running_in_this_thread());
        assert(!_strand2.running_in_this_thread());

        co_spawn(_strand2, g, detached);
    }
}

int main()
{    
    co_spawn(_strand1, f, detached);
    _io_ctx.run();
}

The program is single-thread (I know there's no point using strands, but they should do their work anyway). The question is: why are both strands returning true to running_in_this_thread() in coroutine g? And what implications does this behavior have to the scheduling of functions through the strands?

My guess is that the strand is not eager to change it's internal state as to report "not running" (it gives a false positive).

EDIT

Running the context on multiple threads makes the result of the first call to _strand1.running_in_this_thread() on g unpredictable. I presume it depends on whether g is run right after f on the same thread or not.

Your assumptions don't match reality.

Indeed, ASIO does not provide the guarantees you're expecting. In fact, the documentation goes out of their way to even state the corollary:

> The implementation makes no guarantee that handlers posted or dispatched through different strand objects will be invoked concurrently.

A number of factors are at play here.

First, strands don't need to be unique/distinct, full stop. In fact, a naive implementation where each strand would get it's own unique lock instance would be bad for performance and potentially have unnecessarily high resource usage.

Instead, all strand services employ hashing to map logical strands onto "real strands". The number of buckets is configurable, see BOOST_ASIO_HASH_MAP_BUCKETS

> Determines the number of buckets in Boost.Asio's internal hash_map
> objects. The value should be a comma separated list of prime numbers,
> in ascending order. The hash_map implementation will automatically
> increase the number of buckets as the number of elements in the map
> increases.
>
> Some examples:
>
> - Defining BOOST_ASIO_HASH_MAP_BUCKETS to 1021 means that the hash_map objects will always contain 1021 buckets, irrespective of the
> number of elements in the map.
> - Defining BOOST_ASIO_HASH_MAP_BUCKETS to 53,389,1543 means that the hash_map objects will initially contain 53 buckets. The number of
> buckets will be increased to 389 and then 1543 as elements are added
> to the map.

Lastly, as you have found out (in your edit), the implementation only need to uphold the guarantees made¹. It does not need to pessimize behaviour to guarantee the opposite(s). In particular, completions may be dispatched instead of posted (though never immediately invoked). Asio's clever thread-local queue optimizations help prevent unnecessary overhead for common situations.

¹ eg here, here