Strawman proposal: making libthr default thread implementation?

[Julian Elischer]

Kip Macy wrote:

> I believe that the views that Peter has expressed are held by quite a
> few. I initially integrated bike_sched in my development branch for
> the purpose of playing with different locking strategies. More
> recently I've integrated it into my stable branch after discovering
> that it greatly improved the stability of threaded applications. As a
> consequence of it being in my stable branch it has been integrated
> into a widely watched development project. I'll leave it to the
> developer on that project to discuss it on -current. As someone who
> has yet to make substantial contributions to FreeBSD it is not my
> place to advocate for or against KSE. However, I will say, without
> equivocation, that KSE needs a fair amount of TLC  in the form of
> re-factoring and bug fixes for it to have a place on future hardware.
>
>     -Kip
>
>
I wrote the threading code into the system with the aim of supporting as 
many threading
models as I could. In this light, you will notice that 1:1 threads is 
fully supported.
It was always imagined that as time went on, various models would fall 
by the wayside.

The first arrow in the came when it was found that KSE for some of the 
newer architectures
(alpha and ia64) would be far harder than expected due to the fact that 
thread state is not always
stored where you would expect it to be.  This happenned fairly early on 
and necessitated
a change in course part way through. it never really recoverred from 
this. The code to
store a blocking thread and jump to another (newly created) one was 
never able to be
really optimised, but it worked (kinda). The big problems are that a lot 
of code assumes things
that are just not true when some of the threads are not resident in the 
kernel and have no
actual trace in the kernel at all.

It would have been good to see an app that could use M:N affectively, 
and there is some
indication that some Java VMs may come under this category as I have 
heard of java VMs
with 10,000 threads of which most are not involved with I/O. However I 
have never
seen any sign of such a beast with my own eyes.

If it come to pass that M:N threads are judged to be "unsuitable" then 
that is a decision
that I can live with, but never be let it be said that I walled FreeBSD 
in to only having
the option of 1:1 threads.   I might add, as I did before that the 
double level scheduer
with threads hanging off the KSEGRP until they can be run by the main 
scheduler when
there are enough "opennings" for that process/ksegrp is orthogonal to this
discussion and if that is all removed in Peter's skunkworks project then 
that is a separate
issue that must be addressed under a different banner.  Simplifying the 
scheduler
by removing that just allows a process to overwhelm the scheduler with 
its own threads but it
could be allowed to do that equally for both M:N and 1:1 threads.,
(Peter is this part of what you did?)


>>
> _______________________________________________
> 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"