Date: Fri, 20 Oct 1995 08:28:59 -0600 From: aflundi@sandia.gov (Alan F Lundin) To: freebsd-hackers@freebsd.org Subject: Re: NetBSD/FreeBSD (pthreads) Message-ID: <199510201429.IAA12025@sargon.mdl.sandia.gov> In-Reply-To: "Ron G. Minnich" <rminnich@Sarnoff.COM> "Re: NetBSD/FreeBSD (pthreads)" (Oct 20, 9:10am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 20, 9:10am, "Ron G. Minnich" wrote: > Subject: Re: NetBSD/FreeBSD (pthreads) > > I implemented a simple version of plan9 rfork() a little while ago (well, > a year ago). You could rfork and end up with shared data space and file > table. I also implemented a very simple lock/unlock primitive that was > [ ... ] > > For my money this is about as good as kernel threads. There's not the > additional complexity in the kernel (have you ever seen what LWP did to > sunos? No? good.). > > This code has been available gratis for a year. I can't convince anyone > to pull it into core for netbsd or freebsd, but I'll make the offer > again: you want it, let me know. The code, btw, is less than 100 lines > for each change. In fact the fastlock code is something like 25 lines. > I've implemented them as LKMs and directly as part of the kernel. I've been really surprised that there hasn't been a great deal more interest in this (than I've seen anyway). Rob Pike argues pretty well, I think, that kernel threads are a really bad idea, and that the rfork paradigm is more efficient, more powerful, and much simplier to implement (this is that hard to find combination for which I use the adjective "elegant"). His argument goes something like: any time you put threads in the kernel you've fixed the "weight" of the thread, i.e., what is shared between the threads. While with rfork you essentially create "variable weight" threads -- sharing the attributes between processes that are needed for that particular problem. He also noted that adding kernel threads adds a significant "weight" to the process. Larry McVoy has argued that putting "lightweight threads" in the Solaris 2 kernel has made threads about as heavy as normal processes, and Solaris 2 processes now are very heavy, and so is strongly in favor of the rfork concept. There's other evidence that the rfork concept is a good one. After the fact (of making the decision to use rfork in Plan-9 rather than traditional threads), a survey was conducted on the source on the system, and it was found that rfork was almost always called with different attributes being shared, confirming that the flexibility of user defined attribute sharing is used in practice. I haven't thought about it a lot yet, but I'd expect that a user-land library could easily be written using rfork that looks just like pthreads. And I haven't seen or been able to think of any drawbacks or weaknesses to the rfork approach. In any case, I think Ron's rfork implementation for FreeBSD deserves a close and careful look before the kernel gets burdened with a traditional "thread" addition. For those interested in reading more, the Plan-9 overview paper at http://plan9.att.com/plan9/doc/9.html has a section on rfork and its rational. Also there are other documents at ftp://plan9.att.com/plan9/doc/* that probably discuss this more (I'm not sure what's there any more as it has had a fairly major reorganization). --alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510201429.IAA12025>