From owner-freebsd-threads@FreeBSD.ORG Sun Feb 1 11:27:17 2004 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 A92A616A4CF for ; Sun, 1 Feb 2004 11:27:17 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 100E943D1D for ; Sun, 1 Feb 2004 11:26:44 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i11JQAiw016499; Sun, 1 Feb 2004 14:26:10 -0500 (EST) Date: Sun, 1 Feb 2004 14:26:10 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-threads@freebsd.org Subject: Re: pthread_create() blocks if maxthreads reached? 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: Sun, 01 Feb 2004 19:27:17 -0000 On Sun, 1 Feb 2004, Julian Elischer wrote: >=20 > On Sun, 1 Feb 2004, Petri Helenius wrote: >=20 > > Craig Rodrigues wrote: > >=20 > > >Understood. Keep in mind, I am trying to "kick the tires" > > >on libpthread, to see how it reacts on crazy corner cases. > > >I can certainly increase the values of these sysctls, > > >but I think that pthread_create() should not block if > > >it hits a limit. > > > > > > =20 > > > > > I agree here, pthread_create() should not get blocked sitting somewhere= =20 > > because > > it would easily lead to situations where a "main" thread spawning off= =20 > > children > > is blocked and cannot report errors or pthread_join() threads that term= inate > > because of it=B4s blocked. >=20 > pthread_create() is not blocking.. >=20 > Pthread_create doesn't result in a system call. > creating new threads si a purely userland activity, > (well, the malloc for the thread may call sbreak, but as you are running > in the thread library that might be a synchronous activity anyhow I > think.. (Dan, does pthread_create() count as an entry into the > thread_scheduler?) It can depending on whether there are other higher priority threads waiting. pthread_create() results in a couple of internal locks being taken and can be (inherently) a preemption point. > In any case if it blocked in sbreak() it would be > awoken very quickly. >=20 > To see what is happenning, you have to understand wow these threads > work.. >=20 > when a thread enters the kernel and blocks, (**) a new kernel thread is > created, made runnable, and set to make an upcal back to the Userland > Thread Scheduler,(UTS) so that a new thread can be scheduled to replace > the one that blocked. The new kernel thread is used for the next > userland thread.. If the limit on kenrel threads is reached, then at the > point marked "**" above, no new thread is created, so no upcall occurs. >=20 > basically it's a shell game.. every time a kernel thread blocks, we > create a new one for the process to use instead, until you run out. when > we just don't make one. i.e. the syscall you made still blocks, but no > replacement thread is delivered to teh process to keep running. >=20 > The alternative would be to make EWOULDBLOCK a possible error return for > EVERY syscall.. i.e if you did a select(2) as the test program does, and > you recieved an EWOULDBLOCK.. what would you think/do? >=20 > Noe that this all applies ONLY to threads blocked in the kernel. you may > have thousands of threads in userland, blocked on userland constructs.. > they don't count. Only threads blocked while holding kernel resources. And you can see this with the sample program that I included in one of my last emails. I tested it with 20000 threads and they were all created just fine, but once they were running (blocked in select()) the program quickly ran out of resources (kernel threads). --=20 Dan Eischen