Date: Wed, 24 Nov 1999 08:25:27 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: Jason Evans <jasone@canonware.com> Subject: Re: Threads and my new job. Message-ID: <19991124082527.F1408@tar.com> In-Reply-To: <19991122185220.D301@sturm.canonware.com> References: <19991122185220.D301@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 22, 1999 at 06:52:20PM -0800, Jason Evans wrote: > Walnut Creek has hired me as a full time employee to work primarily on > improving and expanding FreeBSD's threads support. This is very exciting > to me, and I hope my work will be of benefit the FreeBSD community. This is great news. > There is a lot of work to be done in order to make FreeBSD's threads > support truly excellent, For sure. About 9 months ago I spend some time thinking about the FBSD threads library and how to upgrade it. I concluded that one way to go was as follows: 1) Add "kernel thread" support to the existing uthread library, so that a user at run time could create either "user threads" or "kernel threads" (ie. PTHREAD_SCOPE_PROCESS or PTHREAD_SCOPE_SYSTEM). Initially all threads in a process would have to be one or the other, ie. they couldn't be mixed within a process. At the same time, possibly split the uthread code into libpthread so it links to libc. The "kernel threads" would be rforked processes (or _clone'd processes similar to what exists in the linuxthreads port (see http://lt.tar.com). SMP threading would be supported. 2) As stage 2, make the kernel mods that would permit more efficient user threads, as well as mix and match user/kernel threads (of KSE's), along the lines of the recent discussion in the -arch mailing list. The logic for the two step process was that most (but not all) of the work to do step 1 is work that you will have to do to complete step 2 even if you integrate the steps. Also, the detailed code review in step 1 would help you define the specific details of the kind of kernel support you need to implement step 2. Also, there would be a faster payoff from your work. I'd guess that 90-95% of threaded apps really benefit from either kernel threads or user threads, but the mix/match, which is much more complex, only benefits a small percent of real world apps. I think the existing uthread code can be split into four categories: 1) Generic pthread code that works regardless of the threads model. There is a lot of code in this category. 2) Code that is needed only for "user thread" syscall blocking. This might well be 50% or more of the code. It is not needed for kernel threads, and if you add scheduler activations, or some other kernel notification scheme regarding blocked syscalls, this code just drops out of the user thread case as well. You'll get great code simplification and much better performance. My concept was to encapsulate this portion of the code with a flag like: if (_need_syscall_blocking_code) { ........ } Then, if you create a kernel thread, you require (for step 1 purposes) all subsequent threads to be kernel threads and you set _need_syscall_blocking_code to FALSE. Of course, when you implement step 2, this code goes away. This is code analysis and segregation you need to do at some point. 3) Code that is "user thread" specific. This is primarily code that is user thread scheduler related. This would be encapsulated with a flag like "_have_uthreads" similar to the above. This is code you will have to segregate, analyse, and probably modify substantially for step 2. Isolating it early doesn't hurt, and the review may give you a much better grip on the details you need when you implement step 2. 4) Code that is related to libc's lack of thread support. Specifically the abscence of locks for the FILE structure (other libc structures need locks too). This code should eventually go away if libc is improved to better support threads. There's no need to flag this code for execution purposes, but it might help to mark it somehow for future reference. 5) You would have to add (and flag) the new kernel thread code. However, I think this would be very minimal. Creating rforked kernel threads is really very simple, and as long as you're not grafting multiple user threads on each kernel thread, you need almost no support in the pthread library. This new code would either drop out or need to be rewritten for step 2, and thus would be something of a waste. But, I'd guess it might take 2 days of so of coding (plus testing) to do. There would be a side benefit though, in that you'd have some code to test against when you get to step 2. You could test for performance as well as bugs. Your step 2 code is going to be much more complex and bug prone, so you may want a more stable reference for testing. I guessed that all of step 1 was roughly a man month of work. Maybe 1 week of coding/analysis, and 3 weeks of testing/debugging. Splitting libc might add more to this. Please use these thoughts as you see fit. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991124082527.F1408>