From owner-freebsd-hackers@FreeBSD.ORG Fri May 23 13:22:32 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 7BC1937B401 for ; Fri, 23 May 2003 13:22:32 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B784D43FA3 for ; Fri, 23 May 2003 13:22:31 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4NKMHwQ008965; Fri, 23 May 2003 16:22:17 -0400 (EDT) Received: from localhost (eischen@localhost)h4NKMH3d008962; Fri, 23 May 2003 16:22:17 -0400 (EDT) Date: Fri, 23 May 2003 16:22:17 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3ECE3FBE.7EBE5ED5@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 20:22:32 -0000 On Fri, 23 May 2003, Terry Lambert wrote: > 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. We can easily correct for dlfoo() being called by different threads concurrently, so I don't include that in being "thread-safe". As it stands now, rtld-elf is not thread-safe even without calls to dlfoo(). > > > 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). If I am reading you correctly, then no. Scope process threads will block in the kernel, but upcalls will be made to the originating KSE and new threads will be scheduled. -- Dan Eischen