When Will Linux Have Real Threads?

An Anonymous Coward asks: "After reading the article detailing Microsoft's gripes about Linux, one gripe that wasn't specifically mentioned came to mind, "When will Linux have *real* threads?" Many of the developers I work with, including myself, prefer Solaris as an enterpise platform over NT/2K as well as Linux and *BSD because it offers truly lightweight threading and better thread scheduling than the others. Linux does have thread libraries available but they all map threads to Linux kernel processes. Also, all of the thread synchronization and scheduling tweaks that you can do in a program on Solaris don't seem to work as expected/desired on Linux. Are there any projects out there that are trying to put true threading in the Linux kernel and libs?"

Comments

Linux has threads, but...

[Chris Siebenmann]

As a number of people have already said, Linux has kernel-supported threads (multiple threads of execution in a single memory space, where one thread performing blocking IO does not block other threads). The Linux kernel does not have a special implementation of 'threads' as distinct from normal processes; instead threads are processes that share (among other things) their virtual memory mappings. Linux also has a nearly complete and correct implementation of POSIX threads, in glibc.

However there are a few things Linux does not have in its thread model:

• Full POSIX thread semantics. Various people (including Linus) think that some of the pickier requirements of POSIX threads are either braindamaged or very hard to implement in the kernel without performance hits or both. Some of this is worked around by the POSIX thread library that is part of glibc, but at a performance cost.
• A system for using many user-level threads and fewer kernel-level threads. I don't know if there are any obstacles preventing this from being implemented entirely in user space, though. The N:M model is apparently common in various other Unix systems implementation of kernel supported threads.
• Efficient kernel scheduling for huge numbers of simultaneously runnable processes or threads. The Linux scheduler does not cope well when you have hundreds or thousands of threads all ready to run.

  This is a problem for the obvious implementation of Java runtimes, as Java programs often spawn very large numbers of threads for various reasons. IBM, among others, have proposed scheduler patches to deal with this; however, all of the patches have hurt performance for the usual/common case of only one or two runnable processes on the system. This is getting to be a hot issue for active several-way SMP machines too (which may have a process or two per processor, adding up to eight to sixteen runnable at once), so patches may get accepted at some point or may start appearing in 'enterprise edition' kernels from various distributions.

Also as people have said, Linux does not need any special minimal 'thread' kernel object: Linux process objects are already as fast (or faster) and as lightweight as thread objects in other systems. Only on some old legacy Unix systems do 'processes' necessarily equate heavy-weight, slowly scheduled and heavily resource-consuming objects. Both Linux and Plan 9 show that full-scale regular processes can also be lightweight and fast, and easily be used to represent threads too.

start with glibc (not slashdot)

[The Pim]

First, thank you for basing your complaint on Microsoft marketing material, vague anecdotes, and loaded terminology. That said, ...

The "linuxthreads" add-on to glibc is heavily used and actively developed--a quick look at the mailing lists and changelogs will convince you. Both POSIX pthread compliance and performance are high priorities, and many users evidently find the thread support quite "real".

As for performance, I do know that a Solaris-like model is under consideration for glibc, although plenty of people (especially kernel developers) have well-founded objections. It might help if you could provide details on why you don't find the current model "lightweight" enough, such as performance numbers from a real application. You might even get some ideas on how to improve your application.

As for features, new functionality is always being added to linuxthreads. If you described exactly which functionality you need on the glibc lists (and on the kernel lists, if applicable), or pointed out shortcomings in existing functionality, you'd probably get some helpful replies. It's acknowledged that some things aren't there yet, but this is most definitely considered a bug (by glibc people, at least), and the priority of bugs is influenced by user input.

Hoping for a new project to appear is misguided when the glibc/linuxthreads wizards have done most of the job, and remain active and responsive. Your best bet is to work with them.

P.S. Linus does not hate threads--think of how ridiculous it would be for a SMP kernel hacker to condemn concurrency within a single address space. He added clone() to Linux, which enables just that! What he hates are POSIX threads.