*BSD News Article 84278


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.sgi.com!news.mathworks.com!EU.net!Austria.EU.net!siemens.at!pc5829.hil.siemens.at!not-for-mail
From: Ingo Molnar <mingo@pc5829.hil.siemens.at>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Threading
Date: 5 Dec 1996 16:17:12 GMT
Organization: Siemens AG Austria
Lines: 28
Message-ID: <586si8$bdh@zwei.siemens.at>
References: <554o8n$9hb@wormer.fn.net> <jangusE01IB0.A4v@netcom.com> <JdHwnPO.smartsignal@delphi.com> <55nqeo$7d2@plains.nodak.edu> <3289939D.414A@wgold.demon.co.uk> <1996Nov13.165401.2044@wavehh.hanse.de> <56ffr0$o01@Mercury.mcs.net> <1996Nov18.094942.21368@wavehh.hanse.de>
NNTP-Posting-Host: firix.siemens.at
X-Newsreader: TIN [UNIX 1.3 unoff BETA release 961006]

Martin Cracauer <cracauer@wavehh.hanse.de> wrote:

: BTW, it is not useful to use kernel threads to avoid the blocking
: system call problem. Kernel-level threads require much more work on
: resheduling, the solution at user level definitivly faster.

not trying to flame anyone, just a sidenote: Linux reschedules a 
true kernel thread in about 160 machine cycles on a Pentium. Timed 
from user space to user space. [ie. 1.6 usecs on a 100 MHz Pentium]

As far as blocking calls are concerned, the switching is even faster,
since the system is already in the kernel when the system call
turns out to be blocking: the kernel switches in about 30 cycles
from one thread to the other.

[the above numbers are all hot-cache numbers]

Now i really fail to see how you can make this faster in a user-space
solution. It is theoretically >slower<, since blocking system calls
either have to return, or you have to poll the system state via 
select(), both slower (and conceptually wrong) solutions.

Btw, you can use kernel threads on SMP Linux as well, having one thread 
on one CPU, the other on the other CPU[s] for example. Can you do that
with user-space threads?

-- mingo