Re: [boost] Re: problems with boost::thread

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-20 06:47:54

On Tue, 20 Apr 2004 08:16:06 +0000 (UTC), Darryl Green wrote
> Michael Glassford <glassfordm <at> hotmail.com> writes:
> 
> > 
> > "Darryl Green" <darryl.green <at> unitab.com.au> wrote in message

> That said, is this the right thing to do? 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);
 
Bill and I had a discussion about moving toward this in the future, but never
had a chance to do this.

> One way or another, changing the time type is easy, but the actual 
> timed wait implementation is harder, as evidenced by maq's test on 
> windows. 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 
> the system time. Unless windows supports some form of timer event 
> that uses "wallclock" time there doesn't seem to be a way to fix 
> this. Posix systems should act consistently (CLOCK_REALTIME used 
> throughout) afaik.

As far as I know, all timers are relative...

>... 
> Does the general direction sound ok? Basically make a timer that 
> takes the clock type as a policy and make classes that support 
> timeouts (condvars, mutexes so far) templated on the timer type? 
> Provide partial specializations for for things like full pthreads-
> based clock selection, but can allow (as per current windows impl) a 
> fallback to using a duration based timeout running whatever clock 
> the OS uses for timeouts?

In general the separation of the clock from the representation of time is the
correct approach.  date_time does this because there is a recognition that
different platforms (and systems) have different clock sources that can be
adapted to produces a particular time representation with different resolution
and accuracy attributes.  From what I'm reading here this is exactly the issue
you are facing...

Jeff