Date: Wed, 16 Apr 2003 14:44:23 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: John Polstra <jdp@polstra.com> Subject: Re: May I add pthread_[gs]etconcurrency to the threads libraries? Message-ID: <20030416144217.K76635-100000@mail.chesapeake.net> In-Reply-To: <Pine.GSO.4.10.10304161411120.1115-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Apr 2003, Daniel Eischen wrote: > On Wed, 16 Apr 2003, Jeff Roberson wrote: > > On Wed, 16 Apr 2003, Daniel Eischen wrote: > > > > > On Wed, 16 Apr 2003, John Polstra wrote: > > > > > > > Hi Guys, > > > > > > > > Sergey Osokin sent me patches to add the standard > > > > pthread_[gs]etconcurrency functions to our various threads > > > > libraries. I reviewed them and they're OK. The functions don't do > > > > anything significant, but they fill the need for this part of the > > > > API. > > > > > > > > OK if I commit them this weekend? The changes don't change anything > > > > else. They just add stuff. > > > > > > I'm about to implement them for real in libpthread. I'd appreciate > > > you not adding them to that. I've got a slew of other changes that > > > I want add to it very soon. > > > > > > They don't seem to make sense for libthr and libc_r unless it > > > returns ENOTSUP. libthr is 1:1, so it is meaning less there > > > as well as libc_r. > > > > It is not meaningless. Please go ahead and implement stubs if you like. > > I intended to implement a thr_setconcurrency that these can eventually > > use. I was just going to implement it as a simple counter on the proc > > instead of using a full blown KSE structure just for this. > > > > 1:1 means one kernel thread for each user thread. It doesn't say anything > > about how many of those threads may run at a given time. It also doesn't > > force any scheduling scope or scheduling algorithm. > > OK, I was under the impression that libthr would always schedule > threads (KSEs) to as many processors as possible. It'd be neat > to eventually softly bind them (KSE's in general) too :-) > > -- > Dan Eischen > If by softly bind them you mean CPU affinity, ULE does this. It does not support hard binding at the moment. I think KSEs are overengineered as a mechanism for enforcing concurrency. Really a counter of running/runnable threads in the proc would suffice. I'm starting to warm up to the idea of moving kse out of the rest of the system. It could be confined to kern_mn.c or whatever it is eventually called. Cheers, Jeff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030416144217.K76635-100000>