Состояние гонки в pthread_once()? - программирование

У меня есть std::future в одном потоке, который ждет, когда std::promise устанавливается в другом потоке.

EDIT: Обновлен вопрос с помощью примерного приложения, которое будет блокироваться навсегда:

UPDATE: Если вместо этого я использую pthread_barrier, нижеприведенный код делает не.

Я создал тестовое приложение, которое иллюстрирует это:

В основном класс foo создает thread, который устанавливает promise в своей функции запуска и ждет в конструкторе для этого promise, который должен быть установлен. После установки он увеличивает значение atomic count

Затем создаю кучу этих объектов foo, оторвав их, а затем проверьте мои count.

Если я запустил это в цикле с 1000 потоками, ему нужно выполнить его несколько раз, пока не произойдет гонка, и один из futures никогда не проснулся, и поэтому приложение застряло навсегда.

Если я теперь SIGABRT приложение, результирующая трассировка стека показывает, что он застрял на future::wait Трассировка стека ниже:

Я уверен, что я не делаю ничего плохого в своем коде, верно?

Это проблема с реализацией pthread или реализация std:: future/std:: prom?

Ответы

Ответ 1

Действительно, между деструктором локального объекта promise существует условие расы (в конце конструктора и вызов set_value() из потока. То есть set_value() просыпает основной протектор, который сразу же уничтожает объект обещания, но функция set_value() еще не закончена, а мертвые блокировки.

Чтение стандарта С++ 11, я не уверен, разрешено ли ваше использование:

void promise<void>::set_value();

Эффекты: атомарно сохраняет значение r в общем состоянии и делает это состояние готовым.

Но где-то еще:

Элементы set_value, set_exception, set_value_at_thread_exit и set_exception_at_thread_exit ведут себя так, как будто они приобретают один мьютекс, связанный с объектом обещания, при обновлении объекта обещания.

Являются ли вызовы set_value() атомами относительно других функций, таких как деструктор?

ИМХО, я бы сказал, нет. Эффекты будут сопоставимы с уничтожением мьютекса, в то время как другой поток все еще блокирует его. Результатом является undefined.

Решение заключалось бы в том, чтобы p пережить поток. Два решения, о которых я могу думать:

Сделайте p членом класса, как предложил Майкл Берр в другом ответе.
Переместите обещание в поток.

В конструкторе:

std::promise<void> p;
std::future <void> f = p.get_future();
_thread = std::thread(&foo::run, this, std::move(p));

Кстати, вам не нужен вызов bind, (конструктор потока уже перегружен) или вызовите std::move для перемещения потока (правое значение уже является r-значением). Однако вызов std::move в обещание является обязательным.

И функция потока не получает ссылку, но перенесенное обещание:

void run(std::promise<void> p)
{
    p.set_value();
}

Я думаю, что именно поэтому С++ 11 определяет два разных класса: promise и future: вы переносите обещание в поток, но вы сохраняете будущее для восстановления результата.

Ответ 2

Попробуйте переместить std::promise<void> p;, чтобы вместо того, чтобы быть локальным для конструктора, он будет членом struct foo:

struct foo
{
    foo(std::atomic<int>& count)
        : _stop(false)
    {
        // std::promise<void> p;    // <-- moved to be a member
        std::future <void> f = p.get_future();

        // ...same as before...
    }
    void run(std::promise<void>& p)
    {
        // ... same ...
    }

    std::promise<void> p;   // <---
    std::thread _thread;
    bool _stop;
};

Я полагаю, что может произойти то, что вы попадаете в расу, где p уничтожается в конструкторе, а p.set_value() действует на ссылку на promise. Что-то происходит внутри set_value(), пока оно заканчивается/очищается; действующий на ссылку на уже уничтоженный std::promise, искажает некоторое состояние в библиотеке pthread.

Это просто предположение - у меня нет готового доступа к системе, которая воспроизводит проблему на данный момент. Но создание p члена гарантирует, что его время жизни продлится задолго до завершения вызова set_value().