Date: Wed, 16 Apr 2003 12:03:18 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: freebsd-threads@freebsd.org Subject: Re: May I add pthread_[gs]etconcurrency to the threads libraries? Message-ID: <Pine.BSF.4.21.0304161150560.44009-100000@InterJet.elischer.org> In-Reply-To: <20030416144217.K76635-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Apr 2003, Jeff Roberson wrote: > > 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. kern_kse.c :-) M:N threads will run on any scheduler that knows about threads. This goes along with what we were discussing about separating the threadding system from the scheduling system. KSE threading is a misnomer. ALmost everywhere you see the term "KSE" being used in userland threading discussion it shuold be replaced by: "upcall context" (or UPCTX?) which is closely connected with a UTS instance. Originally KSEs were a simple method a fairness. Not perfect but simple and effective. By limiting the KSEs to the number of CPUs one could limit the ability of a process to flood the run queue. While it was envisionned as a part of splitting up the proc structure, it SHOULD have been envisionned as part of the scheduler. Unfortunatly we hadn't come up with the idea of having a separate upcall-context structure yet, so it was doing double duty as that as well, which clouded the picture. When that was split out as part of the threading system, the KSE that was left was plainly part of the scheduling system. (and an implementation detail at that) If we had had an upcall-context structure to start with, it is likely that I would have first gone for a simpler threads--only (but unfair) scheduler, and KSEs would have been only created when someone tried to make it fairer. :-) > > Cheers, > Jeff > > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0304161150560.44009-100000>