Переменные `thread_local` и сопрограммы

До сопрограмм мы использовали обратные вызовы для запуска асинхронных операций. Обратные вызовы были обычными функциями и могли иметь thread_local переменные.

Давайте посмотрим на этот пример:

void StartTcpConnection(void) 
{
    using namespace std;
    thread_local int my_thread_local = 1;
    cout << "my_thread_local = " << my_thread_local << endl;
    auto tcp_connection = tcp_connect("127.0.0.1", 8080);
    tcp_connection.async_wait(TcpConnected);
}

void TcpConnected(void)
{
    using namespace std;
    thread_local int my_thread_local = 2;
    cout << "my_thread_local = " << my_thread_local << endl;
}

Как видно из кода, у меня есть некоторая (здесь не задокументированная) tcp_connect функция, которая подключается к конечной точке TCP и возвращает tcp_connection объект. Этот объект может дождаться, пока TCP-соединение действительно произойдет, и вызвать функцию TcpConnected. Поскольку мы не знаем конкретной реализации tcp_connect и tcp_connection, мы не знаем, будет ли он вызывать TcpConnected в том же или в другом потоке, возможны обе реализации. Но мы точно знаем, что my_thread_local отличается для 2 разных функций, потому что каждая функция имеет свою область видимости.

Если нам нужно, чтобы эта переменная была одинаковой (как только поток будет таким же), мы можем создать третью функцию, которая будет возвращать ссылку на переменную thread_local:

int& GetThreadLocalInt(void)
{
    thread_local int my_variable = 1;
    return my_variable;
}

Итак, у нас есть полный контроль и предсказуемость: мы точно знаем, что переменные будут разными, если TcpConnected и StartTcpConnection будут выполняться в разных потоках, и мы знаем, что они могут быть разными или одинаковыми в зависимости от нашего выбора, когда эти функции будут выполняться в разных потоках. та же нить.

Теперь давайте посмотрим версию той же операции в сопрограмме:

void Tcp(void)
{
    thread_local int my_thread_local = 1;
    auto tcp_connection = co_await tcp_connect("127.0.0.1", 8080);
    cout << "my_thread_local = " << my_thread_local << endl;
}

Эта ситуация для меня немного сомнительна. Мне все еще нужно локальное хранилище потоков, это важная языковая функция, от которой я не хочу отказываться. Однако здесь у нас есть 2 случая:

1. Нить перед co_await такая же, как и после co_await. Что будет с my_thread_local? Будет ли это одна и та же переменная до и после co_await, особенно если мы будем использовать функцию GetThreadLocalInt для получения ссылки вместо значения?
2. Тема меняется после co_await. Будет ли среда выполнения C++ повторно инициализировать my_thread_local значением из нового потока, или делать копию значения предыдущего потока, или может использовать ссылку на те же данные? И аналогичный вопрос для функции GetThreadLocalInt, она возвращает ссылку на объект thread_local, но само хранилище ссылок auto, будет ли сопрограмма повторно инициализировать его в новый поток, или мы получим (опасно!!!) состояние гонки, потому что поток 2 странно получит ссылаться на локальные данные потока 1 и потенциально использовать их параллельно?

Даже если легко отлаживать и тестировать то, что произойдет на любом конкретном компиляторе, важный вопрос заключается в том, говорит ли стандарт нам что-то об этом, в противном случае, даже если мы протестируем его на VC++ или gcc, увидим, как он ведет себя как-то на этих двух популярных компиляторы, код может потерять переносимость и компилироваться по-другому на некоторых экзотических компиляторах.