From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 08:36:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E301837B401 for ; Fri, 23 May 2003 08:36:55 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53B6543F3F for ; Fri, 23 May 2003 08:36:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc0o6.dialup.mindspring.com ([209.86.3.6] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19JEb6-0003nV-00; Fri, 23 May 2003 08:36:45 -0700 Message-ID: <3ECE3FBE.7EBE5ED5@mindspring.com> Date: Fri, 23 May 2003 08:35:26 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d071267c8ef139432ac040cfd76a1b472601a10902912494350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Dan Nelson cc: Julian Elischer Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 15:36:56 -0000 Daniel Eischen wrote: > This is just because rtld-elf is not thread safe (or written > so that locks are not needed as you claim). No. There is plenty of code that falls into this category; as soon as you finish fixing rtld, you will reveal other problems. Mark my words; you cannot make user space thread safe for all eventualities, with the user process never having to know anything about mutexes that the pthreads model expects the user program to hold in order to ensure against race conditions. > > The second of these is that the libkse model is M:N, with N being > > defaulted to 1. If you want more kernel threads, you have to ask > > N is defaulted to the number of CPUs that you have. Libkse > will create as many KSEs as there are CPUs (or whatever > kern.threads.virtual_cpu is set to); these will be KSEs > that run scope process threads. Scope system threads > get their own KSE/KSEG pair without regard to number of > CPUs or kern.threads.virtual_cpu. > > Trying to exceed the number of CPUs with kern.threads.virtual_cpu > will not work unless you also set kern.threads.debug=1. You > really shouldn't need to do this, but we use it for testing > and debugging. This is handy to know; so basically, my expectation from reading the code around PTHREAD_SCOPE_SYSTEM was correct: a single CPU system with PTHREAD_SCOPE_PROCESS (the default) can still get itself blocked in the kernel by a single blocking call (as in the USB bulk read device issue). So he can avoid using the sysctl's, which would be evil, but he could test without modifying his program, if he had to. Thanks for the info! -- Terry