Date: Fri, 20 Oct 1995 11:16:56 +1000 (EST) From: John Birrell <cimaxp1!jb@werple.net.au> To: mira!sdsp.mc.xerox.com!leisner@werple.net.au (Marty Leisner) Cc: hackers@freebsd.org, jb@cimlogic.com.au Subject: Re: NetBSD/FreeBSD (pthreads) Message-ID: <199510200114.LAA09401@werple.net.au> In-Reply-To: <9510192300.AA03362@willow.mc.xerox.com> from "Marty Leisner" at Oct 19, 95 03:58:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510200114.LAA09401>