[boost] Re: problems with boost::thread

From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-04-27 23:19:31

Michael Glassford <glassfordm <at> hotmail.com> writes:

> 
> "Darryl Green" <darryl.green <at> unitab.com.au> wrote in message
> news:loom.20040422T041504-129 <at> post.gmane.org...
> 
> > 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.

>From The Open Group Base Specifications from 
http://www.opengroup.org/products/publications/catalog/c032.htm
(follow the link to free HTML version).

int pthread_condattr_setclock(pthread_condattr_t *attr,
       clockid_t clock_id); 

and

int pthread_cond_init(pthread_cond_t *restrict cond,
       const pthread_condattr_t *restrict attr);

To follow this model directly, one would need to create an attributes object, 
and pass it as a c'tor parameter when creating a condition variable. This 
works too - it just makes it a runtime rather than a compile time error to mix 
timer types. I'd pick compile time, but I guess there might be cases where 
this is bad because of potential template explosion - but I' not convinced.

Note that it may require quite some trickery to get some or all of the clock 
types to work as expected, portably, so the template parameter on the condvar 
may be quite "reasonable" in that the code may actually need to be quite 
different (eg. actually use some sort of system realtime event to implement a 
timeout) for some clock types on some platforms.

Do you see a need to have 2 threads waiting on a condvar, one with a timeout 
next tuesday at 12:34pm EST, taking into account daylight saving, and the 
other precisely 1.23456789 seconds from now, using monotonic time? That might 
be nice, but afaics posix doesn't support doing this. I'm not sure if there is 
a profound reason why, or if it allows some form of scheduler 
optimisation/design (maybe condvar in some kernel/scheduler maintained list, 
with a the condvar having a list of waiting tasks sorted by timeout, which 
would be ugly if the timeouts could be wrt different clocks).

Do you think the different clocks for timeouts on the one condvar use case is 
real? Important? If using different clocks is not supported, do you see any 
advantage to selecting the clock at time of construction vs. compile time?

Regards
Darryl.