Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Dec 2016 10:51:19 +0100
From:      Goran =?utf-8?B?TWVracSH?= <meka@tilda.center>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: How to use sem_timedwait?
Message-ID:  <20161214095118.4wmt2dtf2cmgangl@hal9000.meka.no-ip.org>
In-Reply-To: <20161214092437.GD94325@kib.kiev.ua>
References:  <20161214074228.zh6q5zya2gszw4g6@hal9000.meka.no-ip.org> <20161214092437.GD94325@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

--54aufmfj3s6lderl
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Wed, Dec 14, 2016 at 11:24:37AM +0200, Konstantin Belousov wrote:
> Because this is how computers work. The declared resolution is the
> resolution of the clock_gettime(2) call. While you tried to measure the
> different actions: de-facto you scheduled a wakeup, then put the thread
> to sleep, then thread was awaken.  The system guarantees that the thread
> is made runnable due to timeout not earlier than the interval specified.
> After the thread is marked runnable, it should be selected for CPU, then
> the syscall must complete which put thread to sleep, then userspace must
> execute enough to call clock_gettime(), then it should return etc.
>
> You end up with 1.7ms difference between requested and actual wakeups in
> this attempt, which is quite good.
>
> Note that system also does some micro-optimizations by trying to collapse
> wakeups close enough to each other, which might also affect occurences
> of wakeups.

OK, that sounds logical, but I have a problem now. I need < 1ms precision on this. Is there a way to achieve it? Anyway, thanks for the clarification!

Regards,
meka

--54aufmfj3s6lderl
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAlhRFhMACgkQWj1Tknov
rLY9ZQ/+NIketNBQ/lYgS7oZVh+3SqerDUwHlAZO3R6d47dLGo8WI7vUJtKkzOj5
rUtHCPuGWvA83Ib+eqyuVlAdlsr0BHwjMq0ASzgTwEZMDJwaggOILgkDwifBy0r3
HRMAcUMohlmgmBhsUcjIvA+2rl1ef0BDaQZB3KYMZpRIACFntd+g6FV720FIp15c
M+WLcgYcu0Rp7tI1IMEHP3iJbSlWHOpHeFZ+Loj6Rw/sTahB+mqHrHDxsSXgrAT0
hPKnodFiBsuBvh5VxJ2ffNTNynZWeQkyii4rKR0WDO6kCeiFGzS3IwipGEdct13x
/w/m1+omEjaIWdE1+4oFoovebTM+7g21oaNIvOTX2UX/cLTn24uPb4e8zwVeCKYb
n6h2jCICnb6sOvxzUtcecLOYZxvYGcZwgYYyIXRJuBLpj3X4x1ulQcb3+5uj0+nm
YZ9I29y1icgZvCY2YFX9FRIlhoSWUdrOsqYAx1FQLFwE2JdFbLLZY1FzR3oMx8WX
L7TeIgrdDgwwqgTUVW+nYCVKjiWRHKOnyKrK14ALngdeB9onOSYn6mBu9mFvj3N1
QRYcBa+03TPyrYz+tZQI4CRQysx/5Y3WXb0P7sLxkaGZ3PFYUT32krZ9/xBm3gWu
bl+Us3uABHVPlgoYntHagS9vU/np2ppTEjbNWxGKr1sk85PL3O0=
=xzAu
-----END PGP SIGNATURE-----

--54aufmfj3s6lderl--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161214095118.4wmt2dtf2cmgangl>