From owner-freebsd-threads@FreeBSD.ORG Sun Jun 29 19:32:53 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 6527737B401; Sun, 29 Jun 2003 19:32:53 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FE9A44008; Sun, 29 Jun 2003 19:32:49 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h5U2Wgl33084; Sun, 29 Jun 2003 22:32:42 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sun, 29 Jun 2003 22:32:42 -0400 (EDT) From: Jeff Roberson To: Petri Helenius In-Reply-To: <005001c33e8f$6d90d6c0$44d5473e@PETEX31> Message-ID: <20030629223142.W17881-100000@mail.chesapeake.net> 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 02:32:53 -0000 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. Cheers, Jeff