[boost] Re: problems with boost::thread

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2004-04-19 08:58:41

"Michael Glassford" <glassfordm_at_[hidden]> writes:

> "Darryl Green" <darryl.green_at_[hidden]> wrote in message
> news:loom.20040419T065628-962_at_post.gmane.org...
>> Michael Glassford <glassfordm <at> hotmail.com> writes:
>>
>> >
>> > "MagomedAbdurakhmanov" <maq <at> mail.ru> wrote in message
>> > news:200404160031.i3G0VZO1023813 <at> milliways.osl.iu.edu...
>> > > Hello. I have some troubles with boost::thread, and think they
> are
>> > important:
>> > >
>> > > 1. condition::timed_wait dangerous to use, because waiting delay
>> > specified as time
>> > > when we are will stop waiting. So this is very surprising when
>> > system time is changed!
>> > > I guess that waiting for specified delay is much more safe than
>> > waiting until some time arrive.
>> >
>> > I'll have to think about this. It would break a lot of code to
> change
>> > this now, and there are some good reasons for specifying an
> absolute
>> > time instead of a relative time. For example, if you use the
>> > recommended loop to wait on the condition variable, using an
> absolute
>> > time is at the very least a lot more convenient.
>>
>> The real problem isn't relative vs absolute (It is clear that
> absolute is the
>> only choice for accurate timing) but what the clock is. 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?

On Windows, you could use GetTickCount to do the timing, with
GetSystemTimeAsFileTime and SystemTimeToFileTime to get the limits --- e.g.

const SYSTEMTIME suppliedEndTime=...;
FILETIME endTime={0};
SystemTimeToFileTime(&suppliedEndTime,&endTime);
FILETIME startTime={0};
GetSystemTimeAsFileTime(&startTime);
DWORD const initialTick=GetTickCount();
ULONGLONG const diff=reinterpret_cast<ULARGE_INTEGER const&)(endTime).QuadPart-
        reinterpret_cast<ULARGE_INTEGER const&)(startTime).QuadPart;
ULONGLONG const elapsedTicks=diff/10000;
ASSERT(elapsedTicks<=ULONG_MAX);
while((GetTickCount()-initialTick)<elapsedTicks)
{
    doStuff();
}

>> >
>> > > 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?

I think this is always true under VC7.1, too. What you can do is call
set_unexpected_handler in the thread startup code, but I am not sure that this
is any better than catch(...)

As for what one should do with an unhandled exception in a thread... don't
know. Terminate sounds good, but you could do with a means of forcing other
threads to unwind.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.