Date: Tue, 01 Nov 2005 07:26:30 -0700 From: Scott Long <scottl@samsco.org> To: Marc Olzheim <marcolz@stack.nl> Cc: stable@freebsd.org, Max Khon <fjoe@samodelkin.net> Subject: Re: HEADS UP! 6.0-RELEASE coming Message-ID: <43677B16.4040706@samsco.org> In-Reply-To: <20051101130245.GE5237@stack.nl> References: <436116D3.908@samsco.org> <20051031151809.GA83253@stack.nl> <20051101004042.GA28233@samodelkin.net> <20051101112900.GA4903@stack.nl> <20051101123321.GA39888@samodelkin.net> <20051101130245.GE5237@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Olzheim wrote: > On Tue, Nov 01, 2005 at 06:33:21PM +0600, Max Khon wrote: > >>Hi! >> >>On Tue, Nov 01, 2005 at 12:29:00PM +0100, Marc Olzheim wrote: >> >> >>>>Linking against -lthr (or even -lc_r!) instead of -lpthread solves gdb >>>>"The program no longer exists." problem for me on RELENG_6. >>> >>>Well, yes, but that's not the same. While running on M:N KSE, all sorts >>>of locking needs to be correct, which with non M:N threading you can get >>>away with some (intentional or not) sloppiness. So debugging a fully >>>threaded program with a non M:N threadlib is not always useful. >> >>I do not think that maintaining M:N thread lib is feasible, given the lack >>of resources. Solaris has already moved from M:N to 1:1. Linux (NPTL) is 1:1 >>as well. > > > Well, each threading system has it's own application. Having an easy way > to have one multithreaded process use multiple CPUs is a big win in any > case. Especially in computationally intensive tasks... > > Marc There is little difference between 1:1 and M:N from the application's point of view. Both will allow multiple application threads to run concurrently on multiple CPUs, and both will allow other process threads to run when the current thread blocks in the kernel. The difference is in the details with how they are scheduled and what kernel resources they use. 1:1 has the advantage of being much less complex to implement and maintain, while M:N has the theoretical advantage of cheaper thread context switches. That theory hasn't panned out, though, due to synchronization requirements and the technical requirements of proper TLS support. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43677B16.4040706>