[Corelinux-public] Re: Class Library and Framework Requirements forum msg #7915 (Threads)

[Jacob C. <jac...@ho...>]

Relevant forum message links:
https://sourceforge.net/forum/message.php?msg_id=7915
https://sourceforge.net/forum/message.php?msg_id=7870


Frank asked me to bring up my post to this forum concerning threads
(https://sourceforge.net/forum/message.php?msg_id=7870).  After re-
reading it I am surprised I forgot to include a relevant link that
I didn't quite reference in my post but was presenting food for thought
based upon it:  
http://www-4.ibm.com/software/developer/library/java2/index.html.

A quick summary of my thoughts:
Frank has said that he wishes to go "right to the metal" for threading
support.  To me this means overlooking the good pthreads 
implementation that is available for linux (glibc-linuxthreads) and
writing our own.  Keeping the above IBM article in mind, we have
three options for implementation:
1)  one-to-one -- why bother as this is currently supported by the
available posix threads implementation
2)  one-to-many -- two things:  there is already a pthread-compatible
implementation of userland-scheduled threads (GNU Pth) AND this
model will absolutely not make use of SMP systems.
3) many-to-many -- this hasn't been done yet for linux and to me is
the most exciting prospect (as well as the most difficult) and would
greatly benefit the project and the linux development community in
general.  problem is this means writing our own scheduler with
the added burden of insuring that context switches on mutex and 
conditional operations are MORE efficient than what is currently
done in the kernel (I've not delved into the kernel code so this
may be relatively easy to achieve or not).

Given these options, I feel we really only have one choice to make:
Do we want to use the current posix threads implementation to support
our multi-threading classes or do we instead attempt to implement a 
many-to-many threading model for linux.  I favor the latter even though
it is the mroe difficult because we will get better performance when
it comes time to scale massively upward AND on non-SMP systems.

What do the rest of you think?

--
Jacob