From owner-freebsd-threads@FreeBSD.ORG Mon Jun 30 06:30:14 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8A9637B401 for ; Mon, 30 Jun 2003 06:30:14 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDDEB43FB1 for ; Mon, 30 Jun 2003 06:30:13 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h5UDU4AI024040; Mon, 30 Jun 2003 09:30:05 -0400 (EDT) Date: Mon, 30 Jun 2003 09:30:04 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: rtprio and kse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 13:30:15 -0000 On Sun, 29 Jun 2003, Julian Elischer wrote: > 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, > > one should link with -lthr, not -lkse? Expected result being > > priorities apply only to threads which call for it. > > yes and no.. > That's only YOUR expectation.. > > if your thread is a "scope-process" thread then you cannot expect your > thread to go to rt priority without effecting the priority of the rest > of the group it is a part of. That's what the process-scope part > means... The thread's priority is only relevant within teh process as a > whole and doesn;t effect it's priority vs other processes. > > Your thread is only scheduled within the scope of the process it is a > part of. if the process is not at rt priority, then the thread cannot > really be.. If your thread is "system scope" then each thread can have > an independent priority from the system's point of view. > > If you link with libthr you are specifying that all threads are "scope > system" threads. in libkse you get a choice of which you want. Actually, doesn't libthr create new KSE's within the same KSEG? Perhaps this has changed, but unless libthr creates new KSEGs then all threads would be affected by kernel priority changes. > So to answer your original point.. > if you want "scope system" threads and a system-wide scheduling priority > then you need to ask for that.. but.. that;s expeceted. > Note.. asking for a new thread to be "scope system" is something that > I leave to Dan to tell you about :-) > > > > > 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? > > probably. it's a programmer error to do that.. This is the implementation he's talking about. Use of true spinlocks can cause a deadlock. Libpthread doesn't use spinlocks so it doesn't have this problem. There may be problems with the kernel's use of spinlocks though... -- Dan Eischen