[boost] Re: problems with boost::thread

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-04-27 07:13:38

"Darryl Green" <darryl.green_at_[hidden]> wrote in message
news:loom.20040422T041504-129_at_post.gmane.org...
> Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
>
> >
>
> I've been offline a while. Still interested in improving time
support in boost
> threads though.

I'm still interested too, though I haven't been commenting much on
this thread (not having much of importance to contribute yet).

> > On Tue, 20 Apr 2004 08:16:06 +0000 (UTC), Darryl Green wrote
> >
> > > xtime is a very "c" sort
> > > of a creature and seems to lack basic type safety. Wouldn't it
be
> > > better to have a different time type for each clock type? A
common
> > > duration type could be used.
> >
> > I might suggest boost::posix_time::time_duration and its
breathren.  Then you
> > could expressions like:
> >
> >   time_duration td = milliseconds(100)+microseconds(20);
>
> I agree boost::posix_time::time_duration would be fine to use as a
duration
> representation. Broadly speaking, time_duration would be used where
posix uses
> the timespec struct.
> >
> > Bill and I had a discussion about moving toward this in the
future, but never
> > had a chance to do this.

If this was a public discussion, do you have a link to it? I'd be
interested in reading through it.

> Ok - but what is the time part of this then? xtime is a duration
since some
> epoch. Do you mean to directly replace xtime with a duration type?
>
> I think xtime needs replacing with a number of distinct clock types.
If we
> simply use a duration type everywhere, there is a possibility that
someone
> passes a duration intended to represent a time when used with epoch
A to a
> function that is using clock/epoch B. This strikes me as something
that should
> be detected at compile time. If all times use the same duration type
it is
> obviously simple enough to perform sensible conversions where
needed.
>
> > > The root of this lies in the fact that xtime's TIME_UTC is
> > > "wallclock" time, while the relative time used by the windows
Wait..
> > > functions is a "tick count" (afaik) and isn't affected by
changing
> >
> > As far as I know, all timers are relative...
>
> Sorry:
> The root of this lies in the fact that xtime's TIME_UTC is
> "wallclock" time, while the duration passed to the windows Wait..
> functions is used by a "tick count" clock with an undefined epoch
(afaik).

I agree that this is the root of the OP's problem.

For what it's worth, in my response to the OP I made a distinction
between "absolute" and "relative" times, indicating there was good
reason for Boost.Thread to use an absolute time with the timed_wait
function. Using stricter terminology, what I meant by absolute time
was time relative to a fixed epoch; what I meant by relative time is
time relative to a non-fixed epoch (i.e., relative to the time when
the timed_wait function was called). I still think it's a good idea in
general to pass what I was calling an absolute time to timed_wait.
What do you think?

[snipped discussion of types of time]

> As an example using boost thread:
>
> extern bool something_done;
> void start_something();
>
> condition<up_time> cond;

I didn't comment on this when you mentioned it the first time because
I wanted to think about it first, but I'd be pretty hesitant to turn
the condition class into a template class merely for the sake of the
timed_wait functions. I could see templating the timed_wait functions
themselves if necessary, but templating the whole condition class
seems to me like trying to solve the problem at the wrong level.

> mutex m;
> lock lk<m>;
>
> bool done_by(time<up_time> tm)
> {
>   while (!something_done) {
>     if (!cond.timed_wait(lk, tm))
>         return false;
>   }
>   return true;
> }
>
> int main(int, char*[])
> {
>   time<up_time> a(minutes(5)); // construct from duration since
epoch
>   time<utc_time> b(date(min_date), minutes(5)); // using
posix_time-like ctor
>
>   start_something();
>   if (done_by(a))
>      cout << "Did something within 5 minutes of system start." <<
endl;
>
>   if (done_by(b)) // won't compile
>      cout << "This is a very early computer!" << endl;
>
>   return 0;
> }

[snipped "a more realistic use case"]

> Have I somehow drawn the clock/time/duration distinctions in the
wrong places,
> or is the above a reasonable approach? I've had a look at the
implementation
> of date_time and I think it might fit ok with the model I was
thinking of
> where any time type is basically identical except for some sort of
clock
> dependent trait/policy.
>
> Using date_time this would be time_system. This looks like a
reasonable place
> to start but the base_time seems to require that:
>
> A time has a date component.
> A time has a zone.
>
> I guess one could write a time_system that had only a vestigial
concept of
> date and zone? Is there a way of making a pure day based date (no
fancy julian
> date calcs)?
>
> Regards
> Darryl Green.
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>