[MUD-Dev] Thread models and Linux

[J C Lawrence]

Off-list there been some traffic on the Linux thread model and why
Linus refuses to implement M<->N thread supports for Java (he
contends that Java is fundamentally flawed).  The following explains
some of the background usefully.  From a Q&A on Slashdot:

  http://slashdot.org/article.pl?sid=00/07/20/1440204

>From Question #6:

--<cut>--
6) Threading and Linux by Chainsaw

Unix programmers seems to dislike using threads in their
applications. After all, they can just fork(); and run along instead
of using the thread functions. But, that's not important right now.

What is your opinion on the current thread implementation in the
Linux kernel compared to systems designed from the ground up to
support threads (like BeOS, OS/2 and Windows NT)? In which way could
the kernel developers make the threads work better?"
--<cut>--

The answer:

--<cut>--
Ingo: thats a misconception. The Linux kernel is *fundamentally*
'threaded'. Within the Linux kernel there are only threads. Full
stop. Threads either share or do not share various system resources
like VM (ie. page tables) or files. If a thread has 'all-private'
resources then it behaves like a process. If a thread has shared
resources (eg. shares files and page tables) then it's a
'thread'. Some OSs have a rigid distinction between threads and
processes - Linux is more flexible, eg.  you can have two threads
that share all files but have private page-tables. Or you can have
threads that have the same page-tables but do not share
files. Within the kernel i couldnt even make a distinction between
'processes' and 'threads', because everything is a thread to the
kernel.

This means that in Linux every system-call is 'thread-safe', from
grounds up. You program 'threads' the same way as 'processes'. There
are some popular shared-VM thread APIs, and Linux implements the
pthreads API - which btw. is a user-space wrapper exposing already
existing kernel-provided APIs. Just to show that the Linux kernel
has only one notion for 'context of execution': under Linux the
context-switch time between two 'threads' and two 'processes' is all
the same: around 2 microseconds on a 500MHz PIII.

programming 'with threads' (ie.: with Linux threads that share page
tables) is fundamentally more error-prone that coding isolated
threads (ie. processes). This is why you see all those lazy Linux
programmers using processes (ie. isolated threads) - if there is no
need to share too much state, why go the error-prone path? Under
Linux processes scale just as fine on SMP as threads.

the only area where 'all-shared-VM threads' are needed is where
there is massive and complex interaction between threads. 98% of the
programming tasks are not such. Additionally, on SMP systems threads
are *fundamentally slower*, because there has to be (inevitable,
hardware-mandated) synchronization between CPUs if shared VM is
used.

this whole threading issue i believe comes from the fact that it's
so hard and slow to program isolated threads (processes) under NT
(NT processes are painfully slow to be created for example) - so all
programming tasks which are performance-sensitive are forced to use
all-shared-VM threads. Then this technological disadvantage of NT is
spinned into a magical 'using threads is better' mantra. IMHO it's a
fundamentally bad (and rude) thing to force some stupid
all-shared-VM concept on all multi-context programming tasks.

for example, the submitted SPECweb99 TUX results were done in a
setup where every CPU was running an isolated thread.  Windows 2000
will never be able to do stuff like this without redesigning their
whole OS, because processes are just so much fscked up there, and
all the APIs (and programming tools) have this stupid bias towards
all-shared-VM threads.
--<cut>--

--
J C Lawrence                                 Home: claw at kanga.nu
---------(*)                               Other: coder at kanga.nu
http://www.kanga.nu/~claw/        Keys etc: finger claw at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev