On Sat, Jul 12, 2008 at 07:05:43PM +0100, Mindaugas Rasiukevicius wrote:

quoted text
> - Do you have a real-world scenario, that is application, when you need many
>   threads on UP system which do not do any blocking (no I/O, no syscalls, no
>   or limited synchronisation)?

As far as I can tell, this is the fictional application that M:N is targeted
at: tens of thousands of threads running in userspace, doing nothing but
synchronizing among themselves. In other words, an app that does nothing. 10
years ago that might have seemed new and cool, even necessary, but people
have begun to get to grips with multithreaded programming and it's now
obvious that thread synchronization is to be avoided at all costs.

Even that fictional app will break down with more than one CPU, unless you
are willing to replicate the entire multiprocessor aspect of the scheduler
in userspace. If you do that, the thread library's scheduler then needs to
talk to the kernel scheduler to effectively schedule threads on other CPUs.
Not only are you now doing twice the work, you're calling into the kernel to
get things done. The dog begins to chase its tail.

Note that, if your application blocks in kernel while doing I/O (reasonable
applications talk to the outside world) SA adds a lot of overhead. I suspect
this is one reason why for years Sun advised the use of bound threads with
their M:N library. Maybe they had other reasons.

quoted text
> - Avoiding the overhead of user-space <-> kernel-space switches, run queues,
>   full context switch - that would definitely increase the performance. But I
>   doubt that very significantly, keeping in mind that context switch is
>   performed, let's say, every 100 ms (traditional RR time).

It's worth pointing out that in comparison to the SA libpthread, context
switches occur much less frequently with the 1:1 library.

Andrew