svn commit: r231906 - head/lib/libthr/thread
Bruce Evans
brde at optusnet.com.au
Sun Feb 19 10:52:24 UTC 2012
On Sun, 19 Feb 2012, David Xu wrote:
> Log:
> Check both seconds and nanoseconds are zero, only checking nanoseconds
> is zero may trigger timeout too early. It seems a copy&paste bug.
>
> Modified:
> head/lib/libthr/thread/thr_umtx.c
>
> Modified: head/lib/libthr/thread/thr_umtx.c
> ==============================================================================
> --- head/lib/libthr/thread/thr_umtx.c Sun Feb 19 07:44:38 2012 (r231905)
> +++ head/lib/libthr/thread/thr_umtx.c Sun Feb 19 08:17:14 2012 (r231906)
> @@ -205,7 +205,7 @@ _thr_umtx_timedwait_uint(volatile u_int
> if (abstime != NULL) {
> clock_gettime(clockid, &ts);
> TIMESPEC_SUB(&ts2, abstime, &ts);
> - if (ts2.tv_sec < 0 || ts2.tv_nsec <= 0)
> + if (ts2.tv_sec < 0 || (ts2.tv_sec == 0 && ts2.tv_nsec <= 0))
> return (ETIMEDOUT);
> tsp = &ts2;
> } else {
>
Use timespeccmp()? It is even likely to be faster, since it can do the
comparison in parallel, while the above has to wait for TIMESPEC_SUB()
before doing the comparison, unless the compiler is very smart.
However, I seem to have done too good a job of keeping kernel time* APIs
out of userland, so timespeccmp() is only available in the kernel, and
there are uglier but more correct unsafe macros like TIMESPEC_SUB()
macros in userland, and various kernel APIs escaped anyway, starting
with the NetBSD timeval ones, which escaped 10-15 years after timevals
should have gone away because they were superseded by timespecs.
Bruce
More information about the svn-src-all
mailing list