Re: [boost] Boost Threads Condition may block forever on clock change

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-26 08:46:53

Thorsten Froehlich <froetho_at_[hidden]> writes:

> Anthony Williams wrote:
>> As the POSIX spec points out, there is a race condition implementing an absolute
>> timeout on top of a relative-timeout-based API. If we want to support absolute
>> timeouts (and we do)
>
> But why does this imply forcing everybody to use absolute timeouts only in
> the boost interface? Sure, there are as many uses for relative timeouts as
> there are for absolute timeouts in an interface, yet only absolute timeouts
> have this race condition.

The new thread interface supports both in most places.

> IMHO it makes more sense to use relative timeouts internally and have users
>  compute relative timeouts for their absolute timeouts if they need them.

I side with the POSIX spec on this one: absolute timeouts are more scalable.

> The benefit would be that the absolute time needs to be queried only once to
> compute a relative timeout in code that wishes to work with absolute
> timeouts, eliminating the race condition on Windows. POSIX "users" can get
> predictable behavior using CLOCK_MONOTONIC even with the boost code
> internally using relative timeouts.

On Windows, the internal relative timeouts need to be calculated potentially
many times, as the code may need to wait multiple times, on either the same or
different internal sync objects.

> Making this change, the race condition goes away on one more platform using
> in the boost interface. It should also be considered that relative timeouts
> in the boost interface certainly eliminate a problem on a platform with a
> large market share relevant to many boost developers for better or worse ;-)

How does the race condition go away by making everyone use relative timeouts?

> As "xtime" is documented as "...temporary solution that will be replaced by
> a more robust time library once available in Boost." I cannot see a good
> argument to keep it given its real problems.

xtime is only kept for backwards compatibility. The new interface uses
boost::system_time, which is a typedef for boost::posix_time::ptime from
boost::date_time

> Of course, what this does not address is the issue of absolute timeouts that
> intentionally depend on absolute time being changed by the user ... but is
> this really so important to justify a fully absolute timeout-based interface?

Relative timeouts are now supported in most boost::thread interfaces. The
thread docs are out of date: I am in the process of updating them.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL