From owner-freebsd-threads@FreeBSD.ORG Wed Apr 16 11:44:30 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E0C837B401; Wed, 16 Apr 2003 11:44:30 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2DDE43FA3; Wed, 16 Apr 2003 11:44:26 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h3GIiNZ48121; Wed, 16 Apr 2003 14:44:23 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 16 Apr 2003 14:44:23 -0400 (EDT) From: Jeff Roberson To: Daniel Eischen In-Reply-To: Message-ID: <20030416144217.K76635-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: deischen@freebsd.org cc: jeff@freebsd.org cc: freebsd-threads@freebsd.org cc: John Polstra Subject: Re: May I add pthread_[gs]etconcurrency to the threads libraries? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 18:44:30 -0000 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