Sebastian Redl <sebastian.redl@getdesigned.at> writes:

ak1mbox-boost@yahoo.ca wrote:

...

One quick note, another cross OS library that implements a lot of threading primitives is APR (Apache Runtime Library). I have been using APR heavily for the last few month and my testing showed that APR does not have this problem of being affected by clock changes. I am not sure about their internal implementation so can't comment on differences between APR and BOOST condition but this might be something interesting to look at.

The APR condition object uses relative timeouts. If you're interested, the source is in locks/unix/thread_cond.c and locks/win32/thread_cond.c, respectively. For the pthread condition object, the library simply adds the offset to the current time to receive the end time.

apr_time_t then; struct timespec abstime;

then = apr_time_now() + timeout; abstime.tv_sec = apr_time_sec(then); abstime.tv_nsec = apr_time_usec(then) * 1000; /* nanoseconds */

rv = pthread_cond_timedwait(&cond->cond, &mutex->mutex, &abstime);

Because it uses relative timeouts, it's not subject to the clock change problem on Win32. However, it also shows nicely how easy it is to get a relative offset based on an absolute system. As mentioned, the opposite is very difficult.

The win32 implementation (http://svn.apache.org/viewvc/apr/apr/trunk/locks/win32/thread_cond.c?view=ma...) also demonstrates how hard to use relative timeouts are: the same timeout is used every time round the loop. That means that if a thread acquires the semaphore just before its timeout, but it shouldn't be woken, then it will wait the whole timeout period again. There is no guarantee that this state of affairs won't repeat next time round, thus leading to an infinite loop. Relative timeouts are dangerous, and give a false sense of security. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL