>
> Well, as far as I know the 2.0 series of kernels have a global lock
> around all the kernel code wich effectively implies that only one
> proccess could be in the kernel at the same time this is the so
> called global lock. Now int the 2.1 and 2.2 series the kernel has
> been moved to a fine grained lock wich implies that only one proccess
> can be in the same locked kernel code, but the locked code is a
> little part of the kernel, not the whole kernel, so the speed is
> better.
>
> About the threads part; I don't really understand the NT's text (and
> so other things about NT). It's true that the threads in linux are in
> user space, but they are like any other proccess and the time is
> divided by the scheduler, not by the app. If a program spawns two
> threads there will be (if I remember correctly) a total of four
> processes two for the threads, + one for the program + one for a
> thread spawned by linuxthreads in glibc which controls the signals
> and locks between the threads, this "control thread" is closed
> automatically when all the other threads have finished.
I don't understand the "user-space" point. Threads on linux are
_kernel_ threads... they are distinct 'processes' in every sense of
the word, each having its own context (proc structure as it is known
in most unix circles). Some machines do this in userspace, where
there is one kernel process and some library code actually interlaces
execution of each user thread onto that one (or more if specified)
kernel threads. If you run 10 threads, you get 11 processes, one of
them to manage the 10 actual threads running. IE I always see only
N+1 processes on my machines when running N thread applications.
Perhaps part of this is a terminology problem, (user space vs
kernel space)??
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
