Re: nanosecond debiting cv_timedwait

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Fri, 20 Mar 2015 18:34:15 +0100
   From: Christoph Badura <bad%bsd.de@localhost>

   We don't want people to think a mechanical conversion to:

           struct timespec timeout = { .tv_sec = 1, .tv_nsec = 0 };
           struct timespec now, end;
           int error;

           nanotime(&now);
           timespecadd(&now, &timeout, &end);
           while (!condition) {
                   error = cv_timedwait_sig(&sc->sc_cv, &sc->sc_lock,
                       &timeout);
                   if (error)
                           goto fail;
                   nanotime(&now);
                   if (timespeccmp(&end, &now, <) {
                           error = EWOULDBLOCK;
                           goto fail;
                   }
                   timespecsub(&end, &now, &timeout);
           }

   is going to work as before. Or does it?

I don't see why that wouldn't work: you're just ignoring the update of
timeout and repeating the bookkeeping yourself.  The individual waits
will take just as long.  (However, nanotime is not appropriate here
because it might go backwards.  Either nanouptime or getnanouptime is
preferable.[*])

But there are very few cases of explicit bookkeeping like that anyway
in the kernel, and many more of

	while (!condition) {
		error = cv_timedwait_sig(&sc->sc_cv, &sc->sc_lock,
		    mstohz(1000));
		if (error)
			goto fail;
        }

which looks at a glance like it should wait a maximum of one second,
but in reality does not.


[*] I chose getnanouptime for the initial proposed implementation of
cv_timedwaitns since the timed wait itself has only 1/hz resolution.
In the future, nanouptime may be preferable -- or, perhaps there ought
to be an extra argument specifying the desired resolution in multiples
of nanoseconds: e.g., cv_timedwaitns(cv, lock, timeout, 10000000) to
request ten-millisecond resolution, or an error of at most +/- 10ms,
or something.