Date: Thu, 3 Apr 2003 19:01:27 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: "Geoffrey C. Speicher" <geoff@speicher.org> Cc: freebsd-threads@freebsd.org Subject: Re: 1:N threading Message-ID: <Pine.GSO.4.10.10304031856050.4135-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.05.10304031856550.3285-100000@speicher.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Apr 2003, Geoffrey C. Speicher wrote: > On Thu, 3 Apr 2003, Daniel Eischen wrote: > > > On Thu, 3 Apr 2003, Geoffrey C. Speicher wrote: > > > > > OK, so we've got 1:N threading (libc_r), 1:1 threading (thr), and M:N > > > threading (KSE). Each model has its own merit depending on the > > > application. > > > > > > However, it would still be nice if the 1:N model didn't block the whole > > > process when a thread blocks. Is there any reason to hold onto a pure > > ^ in the kernel. > > > > > userland implementation of 1:N? Can libc_r be implemented in terms of > > > KSE? > > > > Libc_r will go bye-bye. The KSE library will give you 1:N > > as long as you don't use pthread_setconcurrency() and don't > > create any PTHREAD_SCOPE_PROCESS threads. > > Two questions: > > 1. You meant PTHREAD_SCOPE_SYSTEM, right? Sorry, yes. I always seem to make that mistake. > 2. Does always using PTHREAD_SCOPE_PROCESS give 1:1 threading > that would also replace libthr? Yes, it would give the same effect. With the current KSE architecture, there is a small overhead for scope system threads, but with a few, probably minor, changes to the kernel and UTS we can get rid of that. Performance tuning comes last :-) -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304031856050.4135-100000>