This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.
- From: Evgeniy Polyakov <johnpol at 2ka dot mipt dot ru>
- To: Kaz Kylheku <kaz at zeugmasystems dot com>
- Cc: Chris Friesen <cfriesen at nortel dot com>, linux-kernel at vger dot kernel dot org, libc-hacker at sources dot redhat dot com, libc-alpha at sources dot redhat dot com
- Date: Wed, 31 Jan 2007 11:47:56 +0300
- Subject: Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.
- References: <66910A579C9312469A7DF9ADB54A8B7D5C2B90@exchange.ZeugmaSystems.local>
On Tue, Jan 30, 2007 at 01:16:22PM -0800, Kaz Kylheku (kaz@zeugmasystems.com) wrote:
> Evgeniy Polyakov wrote:
> > I described in details why and how M:N model better, and its drawbacks
> > include all issues mentioned by Ulrich Drepper, but nevertheless its
> > advantages are far too superiour than those which can be
> > provided by 1:1
> > model.
>
> M:N threading is an unnecessary performance hack that's needed by people
> who are living in a C or C++ exile away from some language that has
> lexical closures, generators or first-class continuations. Not having
> these niceties, they resort to emulating them with threads. The proper
> thing to do is to rewrite the code to use state machines which can be
> driven by any available thread. Or else, write yourself a
> source-to-source transformer that will give C the lexical closure,
> generator, or continuation features that you need to express the
> solution that way.
>
> There is no need to retain any vestiges of a user space threading
> implementation when you have the real thing.
>
> Programs which appear to benefit from that model are badly optimized or
> badly designed. A smartly written program uses an available thread to do
> as much work as possible, until that thread happens to block or its time
> slice burns up.
Do not mix languages like Erlang, specialy designed for concurrent
programming, with M:N threading model - they are completely different,
but you do not want to see this. As you pointed, one thread can do as
much as it need until it is blocked, and what next? Allocate new real
thread? You may want to see how things like JVM work, I seriously doubt
spwning new thread each time task blocks is a way to go. Even having
epoll does not help in many cases. And you forgot the price of
rescheduling in kernelspace and userspace - even with signals it differs
two times, with more intellegent case it differs in 20 times!
Virtual machine can have thousands of threads, actually it cant, since
it will kill Linux in rescheduling.
--
Evgeniy Polyakov