Date: Thu, 5 Feb 1998 06:53:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jb@cimlogic.com.au (John Birrell) Cc: dyson@FreeBSD.ORG, perlsta@sunyit.edu, hackers@FreeBSD.ORG Subject: Re: implementing linux's clone() Message-ID: <199802050653.XAA08485@usr08.primenet.com> In-Reply-To: <199802050548.QAA07862@cimlogic.com.au> from "John Birrell" at Feb 5, 98 04:48:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802050653.XAA08485>