From owner-freebsd-hackers Tue Jan 5 14:50:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA24309 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 14:50:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sturm.canonware.com (canonware.com [204.107.140.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24235 for ; Tue, 5 Jan 1999 14:50:05 -0800 (PST) (envelope-from jasone@canonware.com) Received: from canonware.com (mg134-218.ricochet.net [204.179.134.218]) by sturm.canonware.com (8.8.8/8.8.8) with ESMTP id OAA23551; Tue, 5 Jan 1999 14:45:18 -0800 (PST) (envelope-from jasone@canonware.com) Message-ID: <369296F4.AE24010B@canonware.com> Date: Tue, 05 Jan 1999 14:49:24 -0800 From: Jason Evans X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 2.2.7-STABLE i386) MIME-Version: 1.0 To: Kelly Yancey CC: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads question/problem... References: <36881978.CFE748CD@freedomnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kelly Yancey wrote: > > one more thing, a dirty secret in FreeBSD is that all threads are done as > > ONE process, if you have multiple CPUs you do not gain the advantage of > > multiple processors, you have to design a hybrid fork/thread model. > > > > Argh. Is this going to be fixed in 3.0? Does anyone intend on fixing > it? I mean, even Linux has kernel support for threads, I should think > that FreeBSD...the king of server OS'es...could at least do the same. > For the time being this isn't a problem, as I only have a single CPU, > but I'm really going to need FreeBSD to support scheduling threads on > separate processors by the time I finish the project. I *really* like > FreeBSD, but if I have to I suppose Linux will be the target platform if > 3.0 can't schedule threads independantly. Things aren't quite that simple. Linux's 1-1 kernel threads model has some problems, such as slow thread switching (as compared to a user-land threads implementation), slow thread creation, and some scalability issues I've noticed when creating large numbers of threads. To ask if FreeBSD's threads library is going to be "fixed" to work like Linux's threads library is IMO a poor question, since my observation has been that there are more performance problems that reach out and bite the programmer with LinuxThreads than with FreeBSD's user-land threads. Implementing a threads library that performs well for a wide range of applications is a very difficult (though feasible) task. Thus far, none of the free OSes have come up with such a beast. Jason -- Jason Evans Email: [jasone@canonware.com] Web: [http://www.canonware.com/~jasone] Home phone: [(650) 856-8204] Work phone: [(415) 808-8742] Quote: ["Invention is 1% inspiration and 99% perspiration" - Thomas Edison] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message