When Will Linux Have Real Threads? 18
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?"
Microsoft is dissembling; Linux has threads (Score:1)
What has everyone confused is that Linus (with good reason) thinks that the NT and posix-style threading model is ugly.
The Linux kernel definition is summed up by the clone() system call. Threads are processes that happen to share certain resources that fork() would split. They are not second-class citizens, parasites on a parent process.
If you narrow your definition of threads enough to require the design that Linus has rejected, then you can make the claim without exactly lying, but it's an awfully Clintonesque truth.
Heresay, (Score:1)
Not being a very prolific linux programmer, take what I have to say with a grain of salt.
From what I understand, Linux context switch time is very short. It can switch between processes faster than many operating systems can switch between threads. What exactly is it that you are looking for in Linux's thread implementation that it lacks?
A search for "linux windows nt thread clone fork context" should turn up some good discussions.
Re:Linus hates threads (Score:1)
There are three issues involved in this issue: 'raw' context switch times, kernel context switch times versus a purely user-mode context switch, and the problems the Linux scheduler has with lots of simultaneously runnable processes and threads. There is also an advanced debate here about cache effects that makes some people argue that these differences are often mostly moot.
Linux is asserted to have one of the fastest context switch times going; I have seen reputable linux-kernel people say that Linux switches its processes faster than most systems can switch their allegedly lightweight 'threads'. (I have not done measurements myself, and it would be somewhat challenging to level out other factors. Would-be measurers could do worse than to benchmark Linux against Solaris x86 and Windows (possibly Windows NT) on the same machine. Also, possibly Larry McVoy's lmbench micro benchmarking suit already has suitable test programs.)
In any N:M thread environment you may be able to get away with a certain amount of thread context switching that takes place entirely at user level. Such context switches can obviously take place very fast, faster than one that involves the kernel if both are coded as well. However, I don't know how much of this actually happens in typical use of Solaris's N:M threading, though. N:M threading does have the advantage that it needs less resources on the kernel side (eg, no need for a kernel stack and context information for each user-level thread), and may be amenable to very clever implementations on the user side to also reduce the resource load.
Independant of those two issues is the Linux kernel scheduler's problem with lots of processes that are all runnable at the same time. This definetly causes problems that do not appear in an N:M threading model, and definetly causes problems against a more 'efficient' scheduler. This problem has the net effect of slowing down context switch times when there are a lot of processes. I don't know how much the slowdown is when compared to systems with slower context switching.
And finally: cache reload effects. There is an argument that the amount of time it takes to reload cold CPU caches in a new thread (because each thread is presumably working on different data, and possibly in different code) will completely dwarf the context switching overhead itself, kernel or otherwise, for threads that do real work (instead of benchmarking ping pong context switching times). There are some people who argue that this means that huge amounts of threads are very bad: as the amount of threads rises and as the amount of context switching rises, you spend an ever increasing amount of the CPU merely reloading caches instead of getting any useful work done.
I am not entirely convinced that this is a real effect. Presumably a well written threaded program only uses threads when it needs to, to isolate work on different things. In that case, however the program is written (threaded vs state machine or whatever) it is going to have to switch back and forth between different chunks of data with the associated cache switching; all that threading should add is a small amount of extra cache reloads for the thread-specific data that's also needed (eg, different stacks for each different thread). Unless the amount of data each thread works with is very small, one would assume that the extra thread data is small compared to the data the program has to touch anyways.
Whether Linus is wrong about all this depends in part on what sort of use he sees Linux mostly being put to. There are tradeoffs involved: a scheduler that is very good for 500 runnable processes is likely to have a noticeable chunk of unnecessary overhead for only 2 runnable processes. If most of the environments you are aiming at only have 2 runnable processes, well, you may want to make the tradeoff in favour of the smaller, simpler, faster for the common case scheduler. I believe that Linus has in the past been reluctant to put in code that only helps 'big iron' while hurting ordinary machines because most of the machines that run Linux are ordinary machines. (Also, 'big iron' people are competent enough to make their own kernel variants if they want to; look at SGI's efforts.)
GNU Pth (Score:1)
Re:Linus hates threads (Score:1)
I think one of the best definitions of Open Source I have read is that it's the easiest way to fork a project.
They'll provide you with almost everything you need to make a fork - that's what's required here and it's not supposed to be easy.
Now so far as your "'official' version of Linux", there are already several forks of the Linux kernel by IBM for mainframes and other such forks. Join one of them if you give a fuck - but me? I like to harass people on slashdot. Thank you.
-- Eat your greens or I'll hit you!
threads vs processes (Score:2)
What linux doesn't have is Posix threads, as Linus seems to feel that they are brain dead, something cobbled together before people really understood what the trade offs were. Linux will get them when someone who understands Posix threads and the linux kernel writes them, in a manner Linus accepts. There are very few people who could do that. But perhaps IBM will pay a few smart people to do it.
So, are you sure linux threads don't do what you need? Yes, they are not Posix compliant.
Java and threads (Score:2)
Threads are one of those things which, if you think they're simple, it's because you haven't understood them yet. Java makes it a bit easier to deploy threads, but it doesn't make designing threaded applications significantly easier, because the real design problems have to do with fundamental concurrency issues, and can't be magicked away by a language like Java. In some respects, Java can make things worse because it's not always possible to tell except by trial and error what the concurrency behavior of some of its library routines is.
Re:Linus hates threads (Score:2)
Solaris for example, offers N:M threading, which is one of the reasons it is considered to be better suited to large-scale back-end systems like database servers. My daytime employer uses MySQL on an 8-way Solaris box with as many as 8,000 simultaneous connections! (Yes, we've spent a great deal of time minimizing the # of connections but we just get *that much* usage of our system...) Linux would come pretty close to choking on such a setup.
-JF
Re:Linus hates threads (Score:2)
The second link has the most meat and the third link has lots more links to lots more thread-related topics.
And the obligitory: Don't forget, Linux is open-source, if it doesn't do something you want it to do, feel free to implement it yourself. Or bug other people about it until someone does. If it never gets done, then you have to ask yourself, "is it really so good?"
-=-=-=-=-
I stand corrected (Score:2)
But as for state machines, in fact state machines were what I was writing all the times I have written my own scheduler, but I strongly suspect having a kernel developer write a thread scheduler once and have everyone use it is far more efficient than to have every application developer write their own state machines.
While the kernel can deal with it, user-space state machines can't deal with the problem of blocking on a resource. This can only be handled by a kernel scheduler. On a preemptive multitasking but single-threaded system, you achieve efficiency by scheduling a new process when a process blocks; one a multithreaded system, you can schedule a new thread, which may be any thread in any process (or to use the BeOS term, a "team").
There's no way to handle this with user-space threads of any kind, whether they're implemented as some kind of state machine or faked up to look like real preemptive threads.
Michael D. Crawford
GoingWare Inc
Re:Portable thread library for Linux and others (Score:2)
Alan Cox said, "A computer is a state machine. Threads are for people who can't program state machines.". In other words, kernel hackers are way (way, way, way, way!) past the complexity of threads.
The poster who said Linus hates threads was mistaken. Linus has trashed POSIX pthreads mercilessly, but I don't think he's ever made a general statement against threads or their usefulness (as is clear from that poster's own references, he very much wants a good Linux thread model). Other kernel notables have--eg, Larry McVoy and Ted T'so.
Re:I stand corrected (Score:2)
Everyone's written state machines--it's a standard CS exercise. Of course, your scheduler was probably more challenging than a textbook DFA because you had more events coming at you with less predictability, and how to react wasn't as obvious. I think Alan is implying that a raw computer has way more events; the complexity of the state machine grows exponentially with the number of event types; you have to cope with all sorts of unexpected combinations that don't make any sense; and if you mishandle even one of them, you're may be hopelessly lost.
In your scheduler, you were probably responding to alarms and yields. If you'd had to respond to hardware interrupts, page faults, and clock ticks, it probably would have taken a lot longer to get working! You were benefitting from the kernel presenting all that complexity as a simple process context. That's what Alan is saying (tongue-in-cheek, I hope!)
I strongly suspect having a kernel developer write a thread scheduler once and have everyone use it is far more efficient than to have every application developer write their own state machines.
Unless I'm misinterprenting, you sound like you aren't familiar with the Linux kernel. You might like the approach they have taken--check out the clone system call (copied from Plan9).
The future of FreeBSD threads looks promising... (Score:2)
Portable thread library for Linux and others (Score:3)
I'm pretty perplexed why Linus should think that thread programming is harder. This makes me wonder whether he's ever really tried in a serious way - a lot of programs are much easier to write when you use threads.
Just ask anyone who's had to write their own task scheduler for private use within one program, as I have when writing my Raindrops screensaver [goingware.com] for the Mac, or when I wrote a test tool for MacTCP, that enables up to 64 TCP streams and UDP pseudo-streams between any combinations of a Mac on a network - I wrote that in 1990 at Apple, well before threads were available on the Mac OS and it was a pain.
But personally I don't see the point of having threads not implemented in the kernel. It means all your threads block if any of them do. That's the point of kernel threads. I think solaris threads work the way they do because the solaris schedular isn't so efficient, so it's more efficient to multitask some of your threads in user space.
This also relates to why multithreaded programs are more efficient and responsive than single threaded ones, even on uniprocessor machines. If your process blocks to await a resource in a single threaded program, you get to wait while time is wasted. This is OK for servers where avergage efficiency is the main concern but is not appropriate for interactive or near-real-time use.
With a multithreaded program, if one thread blocks for a resource, another thread can run, and if it's another thread in the same program your program's utilization of the CPU will be greater. This is especially the case if the kernel is preemptible and multithreaded, as it is on the BeOS and can be with experimental patches on the Linux kernel.
For an experiment, using the same machine, compare the interactice responsiveness of Windows, the BeOS [be.com] and Linux, and I can assure you that even for uniprocessor machines the BeOS will be much more efficient, because all native BeOS programs are multithreaded. Threading is available on Linux and Windows but are not yet that widely used.
Michael D. Crawford
GoingWare Inc
Resource blocking (Score:3)
WTF??? You mean you don't have a way of checking whether a resource is available without blocking your thread so that you can go do other processing while the resource is unavailable?
I have done a lot of programming on proprietary pidgin-language controllers where I have had 4 or 5 state machines going at once (describing the behavior of real-world machinery, generally) and not one of these devices supports threading. (Well, one does now, but nobody uses it because it's so hard to debug.)
While it is re-inventing the wheel, the advantage of doing your own threads by implementing multiple state machines is that you can make your own decisions about what is important. In an embedded environment this can make the difference between an app that will and one that won't work on the available hardware.
Linus hates threads (Score:4)
For some great background information read:
here [linuxcare.com]
here [linuxcare.com]
and here [linuxcare.com]
No, not everything linked there is going to be entirely 100% perfectly relevant, but it's good background for understanding. Those articles also have links to other articles discussing various issues relating to good coding practice and thread-programming under Linux etc.
Then, if you want to compare Microsoft threads to Linux threads, at some point someone (probably Linus) pointed out that Linux can fork() many times faster than Microsoft can spawn a new thread, and in fact creating a new thread and fork()ing a new process under Linux both consumed exactly the same amount of overhead, so trying to claim that Microsoft's thread-based model was more resource-friendly than a Linux/UNIX-like multi-process programming model is ridiculous. You might find this discussion in one of the links referenced above, you might not, I'm not gonna go through the effort of looking for it though.
-=-=-=-=-
Linux has threads, but... (Score:5)
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:
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) (Score:5)
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.