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

[Frank V. C. <fr...@co...>]

Jacob Christen wrote:
> 
> 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

Jacob,

Could you clarify one-to-one, one-to-many, and many-to-many?

Thanks
-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux