CODEWITHSUNDEEP
c++boost
Christoph Lipka
Christoph Lipka

Reputation: 668

Eliminate `boost::xtime` in `boost::condition::timed_wait`

We currently have lots of code of the following form:

boost::xtime t;
boost::xtime_get (&t, POV_TIME_UTC);
t.sec += 3 ;
m_Event.timed_wait (lock, t);

or even:

boost::xtime t;
boost::xtime_get (&t, POV_TIME_UTC);
t.nsec += 50000000 ;
m_Event.timed_wait (lock, t);

(Yes, that's without checking t.nsec for overflow. :shudder:)

where POV_TIME_UTC is defined as either boot::TIME_UTC or boost::TIME_UTC_ depending on boost version.

Is it safe to replace these with:

m_Event.timed_wait (lock, boost::posix_time::seconds(3))

and 

m_Event.timed_wait (lock, boost::posix_time::milliseconds(50))

respectively?

Also, does someone happen to know what minimum version of boost this requires? My research indicates boost 1.35, but I might be mistaken.

Upvotes: 0

Views: 138

Answers (1)

JaMiT
JaMiT

Reputation: 17073

Yes, Boost 1.35 added support for relative timeouts in Boost.Thread. Yes, the canonical way to specify a relative time is with boost::posix_time::time_duration (which is the base class of posix_time::seconds and posix_time::milliseconds).

If you need documentation as to the required Boost version, the changes in 1.35 (a.k.a. changes since 1.34), mentions support for relative timeouts. If that's too vague for your purposes, compare the 1.34 documentation for condition to the 1.35 documentation for condition_variable_any. (There's a typedef that allows you to keep the type name "condition" in 1.35.) Version 1.34 documents only absolute time versions of timed_wait(), while version 1.35 has templates for versions taking relative times. A time parameter that is neither an xtime nor a system_time is assumed to be a relative time.

Be aware that timed_wait() was deprecated in Boost 1.50 -- the replacements are wait_for() and wait_until(), for relative and absolute timeouts respectively. As of Boost 1.53 the declarations of timed_wait() are suppressed unless specifically requested via a #define. So what you propose is valid for versions 1.35 through 1.52. Edit: Apparently, the deprecated functions were not removed on the documented schedule. However, they are still deprecated, so once you can establish 1.50 as a minimum version, it would be prudent to convert to the newer functions.

Upvotes: 1

Related Questions