My suggested path for threading.

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
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-threadsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threa
ds
To unsubscribe, send any mail to
"freebsd-threads-unsubscribefreebsd.org"