From owner-freebsd-threads@FreeBSD.ORG Mon Jul 7 14:37:37 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 122D737B401; Mon, 7 Jul 2003 14:37:37 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8294843F3F; Mon, 7 Jul 2003 14:37:35 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (h81.vuokselantie10.fi [193.64.42.129]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h67LbWsL013804; Tue, 8 Jul 2003 00:37:34 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <010501c344cf$f66be110$812a40c1@PETEX31> From: "Petri Helenius" To: References: Date: Tue, 8 Jul 2003 00:37:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-threads@freebsd.org Subject: Re: thread scheduling priority 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, 07 Jul 2003 21:37:37 -0000 > > So when the main thread unlocks the mutex there are two runnable threads, > > which one keeps running? > > The current thread. As I said before, if there are idle KSEs, then > one is woken to run the newly runnable thread. > Although I cannot prove this doesnŽt happen, I think the other thread does not get scheduled until a few moments later because when I get the scenario where thread1 has the mutex, thread2 is waiting on it, thread1 goes to cpu-bound tasks without holding the mutex, thread2 is not woken up, at least not immediately. Is there a delay for waking up the KSE? Obviously if neccessary I can write a simple test program to spit out timestamps. > > It waits until either you hit a blocking condition or the > quantum expires. The library is not (yet) smart enough > to switch out the current thread after the unlock if the > new owner has a higher priority. We could do that, but > if there are other KSEs that can run the new thread, then > they should get it. > IŽll test more soon and see if I can identify a reproducable issue. Pete