My suggested path for threading.

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