Date: Mon, 12 Aug 1996 20:48:27 +0300 (EET DST) From: Narvi <narvi@haldjas.folklore.ee> To: Terry Lambert <terry@lambert.org> Cc: Igor Khasilev <igor@jabber.paco.odessa.ua>, freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD vs. NT Stability Message-ID: <Pine.BSF.3.91.960812203137.7380D-100000@haldjas.folklore.ee> In-Reply-To: <199608121654.JAA25508@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Aug 1996, Terry Lambert wrote: > Obviously, the ideal mechanism is combined kernel and user threads, > with cooperative scheduling of kernel process quantums in user space > against the thread contexts that are blocked awaiting quantum. This > will result in the best overall utilization with the fewest true > context switches. > And is FreeBSD going to get this? It would be cool... Multi-threaded servers for different things (http, etc) are becoming to emerge more. > > The primary benefit of kernel threads is SMP scalability of parallelizable > algorithms. The secondary benefit of kernel threads is in terms of > quantum allocability as a gross measure of how zealously you want to > let your threads compete with other processes which are also competing > for quantum. > > > There are a number of usenet discussions on threading between myself > and engineers at Sun and elsewhere; you can look them up on Dejanews. > > > Since kernel threading is heavily related to SMP scalability of > processes, the SMP group of FreeBSD has dealt some with the issue. > One very good engineer has implemented kernel threading on FreeBSD, > and the code has been submitted; from what I understand, the code > will be integrated into the final SMP release, with only minor > changes. > Are there any plans for integration with the user level pthreads implemetation? Sander > > The resoloution of the kernel threading quantum and context switch > problems (current problems for both SVR4 and Solaris threading, which > are derived from the same Sun code base) will have to wait for better > async->sync call conversion. In all likelihood, this will be implemented > by adding a system call for a more generic "aiowait/aiocancel" that > is not so I/O bound, and an alternate system call vector to allow all > potentially blocking system calls to be converted to queued calls > plus a user space context switch. In this way, the kernel threading > problem of blocking thread execution and throwing away perfectly good > quantum on process context switches, can be eliminated. > > > Regards, > 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?Pine.BSF.3.91.960812203137.7380D-100000>