My suggested path for threading.
julian at elischer.org
Sun Oct 29 03:56:14 UTC 2006
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.
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
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.
More information about the freebsd-threads