From owner-freebsd-threads@FreeBSD.ORG Sun Jun 29 23:34:03 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 AD5B937B401; Sun, 29 Jun 2003 23:34:03 -0700 (PDT) Received: from InterJet.elischer.org (12-233-125-100.client.attbi.com [12.233.125.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D15943FAF; Sun, 29 Jun 2003 23:34:03 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA45932; Sun, 29 Jun 2003 23:33:57 -0700 (PDT) Date: Sun, 29 Jun 2003 23:33:57 -0700 (PDT) From: Julian Elischer To: Jeff Roberson In-Reply-To: <20030629223142.W17881-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: deischen@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: rtprio and kse X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 06:34:04 -0000 On Sun, 29 Jun 2003, Jeff Roberson 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. > > > > 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? > > > > If you mean spinlock_t, no, there are no issues with that. There is a > race condition that sometimes leads to deadlocked threads if you use the > pthread mutex. I expect that to be tracked down and fixed soon. Theoretically any process with rt priority can monopolise the CPU if it spins, regardless of whether it's threaded or not.. Is not that what having RT-priority means? > > Cheers, > Jeff > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >