Date: Sun, 29 Jun 2003 20:22:22 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Petri Helenius <pete@he.iki.fi> Cc: freebsd-threads@freebsd.org Subject: Re: rtprio and kse Message-ID: <Pine.GSO.4.10.10306292017070.1865-100000@pcnet5.pcnet.com> In-Reply-To: <005001c33e8f$6d90d6c0$44d5473e@PETEX31>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Jun 2003, Petri Helenius wrote: > > The rtprio() call affects the KSEG in which the thread runs. > > So it is the KSEG that has the realtime priority, and all > > threads that run in that KSEG will be affected. This doesn't > > affect other KSEGs, so if you are creating system scope > > threads (each has their own KSEG and KSE), they will only > > be affected if you call rtprio() from their threads. > > > So if I interpret this correctly, to achieve the "expected" result, What is the expected result? I expect the expected result to be exactly the way that libkse works. If you were to do the same thing in Solaris (pthreads), it would behave just like libkse works: it affects the LWP, not the thread, so any threads running in the LWP would benefit from the priority change. > one should link with -lthr, not -lkse? Expected result being > priorities apply only to threads which call for it. If you want (real-time) priority to apply only to the thread that calls it, then create those threads as scope system threads. > Does -lthr have any (known) issues with spinlocks like linuxthreads has, where > a thread with rtprio going into a spinlock might monopolize the CPU > and the other thread never gets a quantum to actually release the lock? Libpthread(^Wlibkse) has no such problems with mixing KSEs with different kernel priorities. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10306292017070.1865-100000>