From owner-freebsd-hackers Thu Oct 19 18:30:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA08856 for hackers-outgoing; Thu, 19 Oct 1995 18:30:22 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA08781 for ; Thu, 19 Oct 1995 18:28:03 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7) with UUCP id LAA09401 for hackers@freebsd.org; Fri, 20 Oct 1995 11:14:12 +1000 (EST) Message-Id: <199510200114.LAA09401@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA17483; Fri, 20 Oct 1995 11:16:56 +1000 From: John Birrell Subject: Re: NetBSD/FreeBSD (pthreads) To: mira!sdsp.mc.xerox.com!leisner@werple.net.au (Marty Leisner) Date: Fri, 20 Oct 1995 11:16:56 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <9510192300.AA03362@willow.mc.xerox.com> from "Marty Leisner" at Oct 19, 95 03:58:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Marty, > But it does this via (I think...) all I/O being nonblocking, and if > it would block it then run another thread.... That's right. > I haven't looked at the code for a while, but kernel threads would be > much more efficient (if a task blocks on I/O, it blocks inside > the kernel, rather then muxing on select...) I guess kernel threads would be more efficient wrt blocking, but in our application (process control with scan times in 10's of milliseconds), we still see such a performance improvement over separate forked process. > I agree you can implement user-space pthreads efficiently if > multiple processor are compute bound...but this is not > why you have threads... We are using threads for precisely this. Our threads are (amongst other things) executing PLC programs and are not only compute bound, but memory bandwidth limited. Cache has no impact because we always overflow what ever the cache size is. > > Also, each kernel call will need context switches, which slow things > down... The number of kernel calls goes up with a user-space threaded application, and you may treat this as slowing things down, but relative to a set of separate processes performing the same task the speed up is remarkable. > > marty > > > -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137