Re: [gentoo-dev] real concurrent multithreading with posix threads (pthreads)

[Brandon Low]

Stupid no reply to mangling.

Well I'll have to go beat up my professor then... Thanks for information, 
I had thought he was wrong, but discussed with him later and he convinced 
me.  (I love proving professors wrong).

--Brandon

On Sat, 06/29/02 at 19:53:32 -0400, Marko Mikulicic wrote:
> Brandon Low wrote:
> > Well, I just happen to be taking an operating systems class ATM and yes in
> > linux the normal behavior is that glibc handles thread scheduling, but all
> > the threads are scheduled within the parent process' time slice.  If you
> > NEED to have threads that run on different processors, and are scheduled
> > at the kernel level, from what I have thus far learned it appears that
> > Solaris or WinNT/2k/XPpro are the places to be.
> >
> > Hope this information is helpful.
> >
>
> What?!?
>
> Linux can schedule kernel threads since 1.3.x
> please read http://linas.org/linux/threads-faq.html.
>
> I have a SMP machine with a nice CPU meter wich let me easly see
> when which CPU is used, and I assure you that running multiple threads
> in linux occupies multiple CPUs.
>
> The problem with linux thread scheduling is the opposite:
>   commercial threading implementations do M:N threading. that is
> M kernel threads each scheduling N user threads. Why: because
> user-mode context-switchs are faster than kernel-mode, but
>   user-mode threads cannot be distributed between processors, so
> commercial OS implement a mix of the two models to achieve best
> performances.
>   Linux doesn't yet seriously implement M:N threading but work is being
> done (look at NGPT). Linux has a very fast kernel context switch, so
> that M:N threads are still not a major issue.
>
> The glibc (libpthread) thread implementation uses the clone
> system call (man clone), which permits to multiple kernel processes
> to share the memory space, file descriptors, signal handlers,...
>
>
> Marko