|
Boost : |
Subject: Re: [boost] [thread] countdown_latch
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-27 09:47:39
Le 27/04/13 09:51, Michael Marcin a écrit :
> On 4/27/2013 2:05 AM, Vicente J. Botet Escriba wrote:
>>
>> The change set is https://svn.boost.org/trac/boost/changeset/84055. To
>> see the sources, you would need to update the trunk or to take a look at
>> https://svn.boost.org/svn/boost/trunk/boost/thread/
>>
>> Please let me know what do you think.
>>
>
> I think in latch your wait_for and wait_until don't work correctly in
> the case of spurious wakes.
You are right, my implementation needs a loop (I didn't tested it).
>
> The easy answer to this is probably use the predicate versions, which
> will also handle the technicalities of turning wait_for into
> wait_until during loops caused by spurious wakes.
>
> like:
>
> struct count_not_zero
> {
> count_not_zero(const std::size_t& count_) : count(count_) {}
> bool operator()() const { return count != 0; }
> const std::size_t& count;
> };
>
> template <class Rep, class Period>
> cv_status wait_for(const chrono::duration<Rep, Period>& rel_time)
> {
> boost::unique_lock<boost::mutex> lk(mutex_);
> return cond_.wait_for(rel_time, count_not_zero(count_));
> }
>
> template <class lock_type, class Clock, class Duration>
> cv_status wait_until(const chrono::time_point<Clock, Duration>& abs_time)
> {
> boost::unique_lock<boost::mutex> lk(mutex_);
> return cond_.wait_until(abs_time, count_not_zero(count_));
> }
>
Yes this would work much better ;-)
>
> You should probably also add a latch_any to go along with
> condition_variable_any.
>
>
Why? the use of the condition_variable is an internal detail and more
efficient than condition_variable_any. How latch_any could profit of an
internal change?
Thanks,
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk