From owner-freebsd-hackers Wed Feb 4 22:53:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA22955 for hackers-outgoing; Wed, 4 Feb 1998 22:53:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA22935; Wed, 4 Feb 1998 22:53:37 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id XAA10957; Wed, 4 Feb 1998 23:53:34 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd010930; Wed Feb 4 23:53:24 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id XAA08485; Wed, 4 Feb 1998 23:53:20 -0700 (MST) From: Terry Lambert Message-Id: <199802050653.XAA08485@usr08.primenet.com> Subject: Re: implementing linux's clone() To: jb@cimlogic.com.au (John Birrell) Date: Thu, 5 Feb 1998 06:53:20 +0000 (GMT) Cc: dyson@FreeBSD.ORG, perlsta@sunyit.edu, hackers@FreeBSD.ORG In-Reply-To: <199802050548.QAA07862@cimlogic.com.au> from "John Birrell" at Feb 5, 98 04:48:26 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" > > I haven't documented things in detail, because frankly, other things have > > gotten in the way of our pthreads stuff, and I have held-up someone else > > who has been working on a real pthreads capability. > > And that little pig is sitting here waiting, waiting, waiting... > Never mind, he's having singing lessons. Jeremy Allison (at Whistle) has recently fixed a nasty problem in accept(). Along with the return code patches, this has apparently got the user space pthreads functioning. Along with this and a patch I made (and Jeremy improved on, once it could actually be compiled and run) to the STL to support draft 4 mutex initialization (which can not be static in draft 4), this is apparently enough to allow STL based threads using applications to function under FreeBSD. Unless you arrange for a cooperative scheduling mechanism, and/or you are running SMP, kernel threads are, IMO, vastly overrated (just as kernel threads in SVR4 derived systems, like Solaris, and in Linux are overrated). At this time, kernel threads buy you SMP scalability at a high relative cost. There is no guarantee that if your thread gives up the quantum the scheduler promised it (by making a blocking system call), that the scheduler will not turn around and stab your application in back by giving the next quantum (ie: the remainder of yours) to a competing process. This entails full standard process context switch overhead. Without quantum affinity, thread group affinity, the value of using kernel threading vs. call conversion threading is higly questionable, IMO. Even with SMP, without CPU affinity, you will probably pay a stiff L1 cache miss penalty as kernel threads in a process migrate willy-nilly between CPU's, and a full context switch overhead probability is based on the number of kernel threads in your application vs. the number of total kernel schedulable entites ready to run on average, taken in combinitorics of NCPU at a time. Personally, I would be *very* happy to see even a user space pthreads brought up to draft 10 (the final POSIX draft). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.