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

From: Thorsten Froehlich (froetho_at_[hidden])
Date: 2007-11-26 07:57:12

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.

IMHO it makes more sense to use relative timeouts internally and have users
 compute relative timeouts for their absolute timeouts if they need them.
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.

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 ;-)

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.

Further, the relative timeouts also create a much neater interface compared
to what is currently needed to get something as simple as a 10 millisecond
timeout:

        xtime t;
        get_xtime(&t, TIME_UTC);

        t.nsec += 10000000;

        if(t.nsec >= 1000000000)
        {
                t.nsec %= 1000000000;
                t.sec++;
        }

        condition bar;
        bar.timed_wait(somelock, t);

to

        condition bar;
        bar.timed_wait(somelock, 10000000);

For the absolute time case, the date_time library would be a nice help (not
that I have used it before, so not sure the code below would be legal or
not). First, looking at the current code (assuming "myabsolutetime" is a
ptime object):

        time_duration td(second_clock::universal_time() - myabsolutetime);

        xtime t;
        t.nsec = td.total_nanoseconds() % 1000000000;
        t.sec = td.total_nanoseconds() - t.nsec;

        condition bar;
        bar.timed_wait(somelock, t);

to	

        time_duration td(second_clock::universal_time() - myabsolutetime);

        condition bar;
        bar.timed_wait(somelock, td.total_nanoseconds());

A lot nicer, isn't it? - Especially I strongly assume most programs rarely
need absolute timeouts just a few milliseconds or even nanoseconds apart and
using the date_time library's potential overhead (assuming there is a
significant overhead) will not be a major burden for those who need absolute
timeouts.

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?

    Thorsten