Date: Tue, 29 Dec 1998 00:28:07 -0500 (EST) From: Kelly Yancey <kbyanc@freedomnet.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: (where are linux threads?) Re: pthreads question/problem... Message-ID: <Pine.BSF.3.96.981228234246.6617B-100000@mail.nerds4rent.com> In-Reply-To: <Pine.BSF.4.05.9812281915110.2148-100000@bright.fx.genx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Dec 1998, Alfred Perlstein wrote: > > can someone join in and tell us both where the interfaces to the new linux > threads are hidden in freebsd? > > i thought it was "options COMPAT_LINUX_THREADS" in my kernel file > and -DCOMPAT_LINUX_THREADS in /etc/make.conf but i can't find it. > > is it default now? where are the functions to interface with them > natively? > [ snip ] > > Your complaint about 1-1 threads is valid in a sort of sense, however it's > been discussed to death here and on -current. The general concensus is > that 1-1 threads suck, the informed concensus is that you don't thread for > processor intensive work, only for IO intensive work, threading across SMP > destroys/thrashes cache benefits, your best bet is to use the hybrid > thread/processor mechanism, it's not easy, but it's faster. > <Long Flame> Doesn't it seem obvious to anyone other than myself that the current interest in porting Linux's 1-1 threads is a pretty good indication that people want 1-1 threads in FreeBSD? Is the only way we are going to get this functionality is to borrow it from Linux? My problem is that I am a pretty ardent FreeBSD supporter...and I'm not particullarly fond of Linux. But it would seem that FreeBSD is getting bested in the rather developer-visible realm of thread support. Perhaps I should change my view of FreeBSD's relationship to Linux. I'm sorry that I missed that discussion. Was any consideration made for a hybrid thread mechanism like Solaris's? Where multiple user threads were serviced by a single kernel thread (and there exist multiple kernel threads that can be distributed among processors). It seems to me (albeit I am just one programmer) that the distinction of threads for I/O intensive applications and processes for CPU intensive applications creates a good bit of extra complexity that inhibits development. As I understand it, threads are indended as "lightweight processes" which share code, data, etc with other peer threads to form an entire task. No mention of whether or not the process is I/O intensive or CPU intensive. The question isn't necessarilly about what is optimal, but rather what is the easiest to maintain. What exactly is wrong with writing a program using threads that is CPU intensive? Does it mean that my program doesn't execute as quickly as it would have if it had been written using multiple processes? Big whoop...that is the developer's problem, not the operating system's. As far as destroying caching benefits, what is the possibility of tying a thread to a CPU? Once a thread is scheduled on a certain CPU, would it be possible to give preference to that CPU in future scheduling decisions? That keeps you caching and still allows for load balancing if one CPU is idle. It seems to me that we are backing down in the operating system's responsibilities in favor of giving each application developer extra responsibilities. Which way ends up costing more man-hours in the long run? Would we rather have a more full featured OS and more applications written natively for it, or would we rather be "right"? So the time being, the answer is: just write all your multi-threaded applications using a combined threaded/multiple process model. Sure, add IPC bloat to share the data that you could have easily shared with threads. Sure, manage the bogosity of managing both thread pools and process pools. But damnit, that code will be as fast as imaginable on FreeBSD. But oh, did we mention that you could have avoided all the hassle by simply developing for Solaris, Linux, BeOS, and god knows what other operating systems actually schedule threads onto separate processors like a modern OS is expected to? </Long Flame> Sorry, but I am really astonished by FreeBSD's stance on implementing multithreading. I am working with others on a modular server archetecture which I at least was hoping would be multithreaded. But the problem is that since it is modular, we can't know whether the server as a whole will end up CPU intensive or not. So, now rather than having a relatively clean all threads implementation, I'm being told that since it was decided that threads are *best used* for I/O intensive apps, we would have to add an extra level of complexity to manage multiple processes each possibly with multiple threads to do the same task. Needless to say, I'm not happy. Let me quickly mention that I understand that this has been discussed before and I apologize for my late $0.02. I have no intention to start a flame war or otherwise lengthy emotional display. If anyone would like to kindly point out what I am missing or why despite this setback FreeBSD can plan on continuing it's record for server performace, please e-mail me directly rather than the list. Mind you, flames will be silently ignored. Finally, I am actually personally embarassed (other than for my many typos) for my advocacy for FreeBSD over Linux. I have until now pushed FreeBSD as the preferred server operating system, but when I find out that Linux seems to better support multithreading (increasingly a staple of modern programing), I have to think twice. I definately have to reconsider my development platform. Grumpy and disillusioned, Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981228234246.6617B-100000>