[boost] Re: problems with boost::thread

From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-04-20 03:16:06

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

> 
> "Darryl Green" <darryl.green <at> unitab.com.au> wrote in message
> It would be better to expend effort on supporting alternate clocks,
> in particular something similar to posix CLOCK_MONOTONIC. A monotonic
> clock would address the original issue (system time changing).
> 
> The links in Alexander Terekhov's post also mention this. Do you have
> any suggestions how to implement something along these lines?
> 

Well, xtime currently has the interface for it, but no impl for anything other 
than TIME_UTC. I assume TIME_MONOTONIC etc are there for future extension. The 
posix times() function's return value represents a form of monotonic time 
since a fixed point in time no later than the process start time. This should 
provide a widely available form of monotonic time information (limited range 
though). On posix pthreads systems with the relevant options supported, there 
shouldn't be a problem making xtime support whatever subset of clocks the 
system supports.

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.

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.

The existing windows code would work fine (except for the race/lack of 
precsion issue that already exists in converting from an absolute time to a 
duration) using a monotonic timer using the same tick count as the built-in 
timeout functions. The high resolution timer doesn't seem in any way usefull 
here as there is no way of scheduling a timeout to a higher precision than the 
tick period anyway.

For posix compatiblity, the type of clock used needs to be an attribute of the 
condition variable. It isn't possible to have each timed_wait use a different 
clock. Once again, it seems that this should be a template parameter, not a 
runtime option.

I think nptl + glibc 2.3.3 on linux supports the _POSIX_CLOCK_SELECTION option 
needed fort the above to work, but I haven't upgraded yet. I'd be happy to 
have a crack at implementing something and testing on that platform once I do.

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?

> > >
> > > > 2. The secound trouble is that the thread function has
> catch(...) at
> > > the root and
> > > > when unhandled exception in thread thrown, it's just silently
> eated
> > > and thread stopped.
> > > > But the process stay alive, and now nothing about it.
> >
> > It does know something (that the thread has terminated) about it if
> it joins
> > the thread. It won't need to know anything about it if the thread
> doesn't
> > throw unhandled exceptions. I'm not at all sure what Mag actually
> wants the
> > library to do in this case?
> >
> > > > And ever wrong that catch(...) under VC6 will catch OS
> exceptions.
> >
> > So don't use VC6...
> 
> Unfortunately, though I'm open to correction, isn't this also true
> under later versions of VC? At least as a compiler option?

Sorry, I don't know. Sounds horrible.

> 
> > >
> > > On the other hand, letting exceptions escape from the thread
> function
> > > is also bad.
> > Bad = undefined or some other reason?
> 
> Bad = undefined, or at best implementation defined.

Ok. But then that gets into the whole "isn't everything?" when it comes to C++ 
and threads.

> 
> > > For what it's worth, the thread_function in the
> > > thread_dev branch (which I'm working on merging into the main
> branch
> > > as time allows) has this:

[snip]

> > How is this better?
> 
> I wasn't necessarily implying that it was better. My main reason for
> mentioning it (though I failed to say so) was to see what people
> thought about it.
> 
[snip my long comment]
Ah. I couldn't see how it fixed anything for maq. I probably didn't really 
need to make quite so much noise. Just "not any better" would have done I 
guess.

> Thanks for your comment.

No problem.

Regards
Darryl.