有没有一种方法可以检查std :: future状态是否准备就绪,并且可以保证无等待状态? [英] Is there a way to check if std::future state is ready in a guaranteed wait-free manner?

查看:555
本文介绍了有没有一种方法可以检查std :: future状态是否准备就绪,并且可以保证无等待状态?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道我可以通过以下方式检查std::future的状态:

I know that I can check the state of the std::future the following way:

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

但是根据 cppreference.com std::future::wait_for可能会阻止一些情况:

But according to cppreference.com std::future::wait_for may block in some cases:

由于调度或资源争用延迟,此功能可能阻塞的时间超过timeout_duration.

This function may block for longer than timeout_duration due to scheduling or resource contention delays.

timeout_duration为0时是否仍然如此?如果是这样,还有另一种方法可以保证无等待状态地查询状态吗?

Is it still the case when timeout_duration is 0 ? If so, is there another way to query the state in a guaranteed wait-free manner ?

推荐答案

只是引用cppreference 来提醒您,此处是OS调度程序的一个因素,并且需要平台资源的其他任务可能正在使用线程所需的CPU时间才能从wait_for()返回-无论指定的超时持续时间是否为零.就这样.从技术上讲,您不能保证在非实时平台上能获得更多收益.因此,C ++标准对此一无所获,但是您可以在此处看到其他有趣的内容-请参见wait_for()段落. -21"rel =" nofollow noreferrer> [futures.unique_future¶21] :

The quote from cppreference is simply there to remind you that the OS scheduler is a factor here and that other tasks requiring platform resources could be using the CPU-time your thread needs in order to return from wait_for() -- regardless of the specified timeout duration being zero or not. That's all. You cannot technically be guaranteed to get more than that on a non-realtime platform. As such, the C++ Standard says nothing about this, but you can see other interesting stuff there -- see the paragraph for wait_for() under [futures.unique_future¶21]:

效果:如果共享状态包含延迟函数,则无 ([futures.async]),否则阻止,直到共享状态就绪或 直到由指定的相对超时([thread.req.timing]) rel_­time已过期.

Effects: None if the shared state contains a deferred function ([futures.async]), otherwise blocks until the shared state is ready or until the relative timeout ([thread.req.timing]) specified by rel_­time has expired.

这里没有这样提及额外的延迟,但是它确实表明您 被阻止,并且无论wait_for() 锁定-freedom ,更不用说 wait-freedom .

No such mention of the additional delay here, but it does say that you are blocked, and it remains implementation dependent whether wait_for() is yield()ing the thread1 first thing upon such blocking or immediately returning if the timeout duration is zero. In addition, it might also be necessary for an implementation to synchronize access to the future's status in a locking manner, which would have to be applied prior to checking if a potential immediate return is to take place. Hence, you don't even have the guarantee for lock-freedom here, let alone wait-freedom.

请注意,使用 wait_until 时也是如此过去的时间.

Note that the same applies for calling wait_until with a time in the past.

timeout_duration为0时是否仍然如此?如果是这样,那里 保证无等待状态查询状态的另一种方法?

Is it still the case when timeout_duration is 0 ? If so, is there another way to query the state in a guaranteed wait-free manner ?

是的,尽管实现了wait_free(),但情况仍然如此. .因此,这是您用来检查状态的最接近 free-free 的地方.

So yes, implementation of wait_free() notwithstanding, this is still the case. As such, this is the closest to wait-free you're going to get for checking the state.

1 简而言之,这意味着释放" CPU,并将您的线程放在调度程序队列的后面,从而给其他线程一些CPU时间.

1 In simple terms, this means "releasing" the CPU and putting your thread at the back of the scheduler's queue, giving other threads some CPU-time.

这篇关于有没有一种方法可以检查std :: future状态是否准备就绪,并且可以保证无等待状态?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆