Есть ли способ проверить, готово ли состояние std :: future гарантированно без ожидания?

Question

Я знаю, что могу проверить состояние std::future следующим образом:

my_future.wait_for(std::chrono::seconds(0)) == std::future_status::ready

Но согласно cppreference.com std::future::wait_forможет блокировать в некоторых случаях:

Эта функция может блокироваться дольше, чем timeout_duration, из-за задержек планирования или конфликта ресурсов.

Это все еще имеет место, когда timeout_duration0?Если это так, есть ли другой способ запрашивать состояние гарантированно без ожидания?

Answer 1

Это все еще тот случай, когда timeout_duration равен 0?

Да.Это верно для любой операции.Планировщик ОС может приостановить поток (или весь процесс), чтобы позволить другому потоку работать на том же процессоре.

Если это так, есть ли другой способ запросить состояние в гарантированно без ожиданияобразом?

Нет.Использование нулевого тайм-аута является правильным способом.

Нет даже гарантии, что совместно используемое состояние std::future не блокирует мьютекс, чтобы проверить, готов ли он, поэтому было бы невозможно гарантировать, что он былбез ожидания.

Для реализации GCC флаг готовности является атомарным, поэтому нет необходимости в блокировке мьютекса, и если она готова, wait_for немедленно возвращается.Если это не готово, тогда есть еще несколько атомарных операций и затем проверка, чтобы видеть, истекло ли уже время ожидания, тогда системный вызов.Таким образом, для нулевого тайм-аута есть только некоторые атомарные нагрузки и вызовы функций (без системного вызова).

Answer 2

Чтобы ответить на ваш второй вопрос, в настоящее время нет способа проверить, готово ли будущее, кроме ожидания.Мы, вероятно, получим это в какой-то момент: https://en.cppreference.com/w/cpp/experimental/future/is_ready. Если ваша библиотека времени выполнения поддерживает расширения параллелизма, и вы не против использовать experimental в своем коде, тогда вы можете использовать is_ready() сейчас.При этом я знаю несколько случаев, когда вы должны проверить состояние будущего.Вы уверены, что это необходимо?

Answer 3

Цитата из cppreference просто напоминает вам, что здесь важен планировщик ОС и что другие задачи, требующие ресурсов платформы, могли бы использовать процессорное время, необходимое вашему потоку для возврата из wait_for() - независимо от того, является ли указанная длительность тайм-аута нулевой или нет.Это все.Технически вы не можете получить больше, чем на платформе не в реальном времени.Таким образом, стандарт C ++ ничего не говорит об этом, но вы можете увидеть другие интересные вещи - см. Абзац для wait_for() в [futures.unique_future¶21] :

Эффекты: Нет, если в общем состоянии содержится отложенная функция ([futures.async]), в противном случае блокируется до тех пор, пока общее состояние не будет готово или до относительного таймаута ([thread.req.timing]), определенного rel_­time срок действия истек.

Нет такого упоминания о дополнительной задержке здесь, , но в нем говорится, что вы заблокированы , и он остается реализациейзависит * является ли wait_for() yield() потоком ¹ первым делом после такой блокировки или немедленного возврата, если продолжительность тайм-аута равна нулю.Кроме того, может также потребоваться, чтобы реализация синхронизировала доступ к будущему статусу блокирующим образом, который должен быть применен перед проверкой того, будет ли возможен немедленный возврат.Следовательно, у вас даже нет гарантии на блокировка свободы здесь, не говоря уже о ожидании ожидания .

Обратите внимание, что то же самое относится к вызову wait_until со временем в прошлом.

Это все еще имеет место, когда timeout_duration равно 0?Если да, есть ли другой способ запрашивать состояние гарантированным образом без ожидания?

Так что да, реализация wait_free() несмотря на это, все еще имеет место .Таким образом, это самое близкое к без ожидания , которое вы получите для проверки состояния.

---

¹ Проще говоря, это означает«освобождение» процессора и помещение вашего потока в конец очереди планировщика, что дает другим потокам некоторое время процессора.