My suggested path for threading.

[Julian Elischer]

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