Date: Sat, 28 Oct 2006 21:14:33 -0700 From: Julian Elischer <julian@elischer.org> To: Julian Elischer <julian@elischer.org> Cc: peter@freebsd.org, Daniel Eischen <deischen@freebsd.org>, gnn@freebsd.org, Kip Macy <kmacy@fsmware.com>, David Xu <davidxu@freebsd.org>, threads@freebsd.org Subject: Re: My suggested path for threading. Message-ID: <45442AA9.4040306@elischer.org> In-Reply-To: <4544264F.5050703@elischer.org> References: <m2ejssstiw.wl%gnn@neville-neil.com> <Pine.GSO.4.64.0610281018130.12299@sea.ntplx.net> <m23b98ryth.wl%gnn@neville-neil.com> <200610290815.25252.davidxu@freebsd.org> <4544264F.5050703@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > I suggest that we remove the fairness code. > that will remove a lot of the complexity. > then both libraries will be more independent of each other > and the scheduler. (libthr already doesn't use it, and libpthread doesn't need it.. so it just adds complexity) > > libpthread will have system and process scope threads. libthr > will have only system scope threads but will probably be the more > efficient library for the larger set of processes, while libpthread > will be more efficient for a smaller set. > > Given this, I suggest the following path: > > 1/ remove the fairness code.. > I can do this in the 2nd part of next week. I will be on vacation then. > > > 2/ When it is up to it, make libthr the default threading library. > I say this because MOST threading applications are very simplistic in their > use of threading and the simpler threading infrastructure for 1:1 threading > allows for easier optimisation. They usually use threading for IO > parallelization and in this case, 1:1 and M:N devolve to effectively > the same thing except that M:N has more overhead. 1:1 is more efficient > in this case. > > 3/ Keep libpthread around. I believe strongly that there is a class of > threaded app where M:N (after optimization) can leave 1:1 in the dust. > This class of program instantiates many objects, each of which has a backing > thread to implement some form of active behaviour. These threads usually > never go to the kernel and typically come to life from a mutex or > condition variable and then go to sleep again waiting on same. I have > seen a test example of this class where M:N gave an order of magnitude > speed up. > > 4/ continue to adhere VERY STRONGLY to our current practice of making > the libraries RUN_TIME COMPATIBLE. (i.e. libmap can switch between them) > > > I strongly believe that the problems people have reported with "KSE" are > not problems with M:N threading as they are not using M:N threading but > problems with the complexity added to the scheduler by the fairness > attempt. I believe removing this will almost certainly fix those problems > and if it doesn't it will narrow the search significantly. > > > > _______________________________________________ > 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?45442AA9.4040306>