CLOCK_REALTIME/CLOCK_MONOTONIC

Norbert Koch NKoch at demig.de
Wed Jun 29 10:56:41 GMT 2005


Hello.

I am working on a multi-threaded application which
may call settimeofday() and therefore may have
serious problems with timing calculations.

In my applications I calclulate time differences
using clock_gettime(CLOCK_MONOTONIC) under FreeBSD-5.
Under FreeBSD-4 it is a trivial kernel patch in kern_time.c
to have CLOCK_MONOTONIC, as there already is a kernel function
nanouptime().

	int
	clock_gettime(p, uap)
		struct proc *p;
		struct clock_gettime_args *uap;
	{
		struct timespec ats;

		switch (SCARG(uap, clock_id)) {
			case CLOCK_REALTIME:
                        nanotime(&ats);
                        break;

                	case CLOCK_MONOTONIC:
                        nanouptime(&ats);
                        break;

                	default:
                        return (EINVAL);
		};
		return (copyout(&ats, SCARG(uap, tp), sizeof(ats)));
	}




Looking through the sources of the various threading libraries
I found that either gettimeofday() or clock_gettime(CLOCK_REALTIME)
is used for all calculations.

I am not sure, what posix currently says about this
but found a chapter 'Condition variable wait clock' in [Butenhof] (p.359).
As I understand it, Posix.1j expects an implementation to
- at least for pthread_cond_timedwait() - use CLOCK_MONOTONIC by default.
They introduce a new function pair pthread_condattr_(get|set)clock()
to change pthread_cond_timedwait() to use either CLOCK_MONOTONIC or
CLOCK_REALTIME.

>From my understanding of the threading libraries' internals, it
should be trivial to modify them to using CLOCK_MONOTONIC only, but not
quite as trivial to implement pthread_condattr_(get|set)clock().

For FreeBSD-4 I already have a modified libc_r, where I call
clock_gettime(CLOCK_MONOTONIC) once in _thread_init() and set
a global variable _sched_clkid to either CLOCK_MONOTONIC or CLOCK_REALTIME
for further calls to clock_gettime().

Any comments/ideas/opinions?

Norbert



More information about the freebsd-threads mailing list