rtprio and kse

[Daniel Eischen]

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