Slashdot Mirror
Information for Managers - Understanding pthreads?
dnotj asks: "The boss (who is very technically astute) says: NO to using pthreads in any of our production applications. He wants us to do things the old fashion way (fork(), exec(), shared memory, etc). His reason for this is that he doesn't understand pthreads (by his own admission). Hence, he is limiting us to using methods and techniques that he understands. He is reasonable and would see our side (the developers) if presented with enough understanding in a satisfactory format. What I'm looking for are document technically detailed yet directed more towards management. Not something on the level of 'pthreads for Dummies', but more along the lines of 'pthreads for Managers'. Any suggestions? URLs or Books are fine."
You share just what you need to share , and keep everything else private. With threads all memory is common. Didn't they teach you to use protection, or something?
http://www.google.com/search?q=pthreads shows, for starters :
Threads are considered "lightweight" processes, in that they run within a process concurrent to each other and the process that owns them. They share address space, making implementation of the alternative easier. Going with your 1-4 above:
(1) Depends on what platform and how the threads are implemented. In some cases, you do see multiple entries in ps for a process running threads. Typically you see this in network deamons, but often that's because they use fork().
(2) They've been around a very long time. Dijkstra (the guy who developed the shortest path algorithm for graphs) also developed a lot of stuff for threading in the 1960s. Though, fork() and exec() have probably been around longer.
(3) Correct. Threads share memory. The trick is to make sure you eliminate race conditions so that one thread doesnt blow away what another thread is working on while it's working on it. There's two major ways of doing this: Semaphores and Monitors. pthreads use semaphores because they're a little easier to work with in C, whereas monitors generally need support from the programming language (eg, Java implements monitors, but can add your own semaphores to Java code if you wish).
(4) POSIX has a Threading specification. iirc, pthreads in one such implementation.
Uses: Within an OS Kernel, in GUIs, server apps, less overhead than using fork() et al. Useful in massively parallel computing applications where a lot of data gets shared. Like everything else in programming, it really depends on what's being developed.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
God that is stupid. OK, let met put it another way.
Computer work with machine code. High level languages are for people who cannot program in machine code.
OK, Alan Cox gets my het off because DOES program in Machine code, and I have too, but the thing is, threads are easier to maintain than a state machine because usually the two things are separate while in a state machine the bloody states have a complicated interaction.
Obviously the model where you fork 10000 threads off to anything is not viable. But for many apps threads make it easier to maintain the thing and keep separate things separate. A UI which has a separate thread for the UI and a thread for the program for instance is a VASTLY better model to program in than the stupid Event based crap that you see everywhere. See Java Swing vs. Java AWT for an example. And definitely see BEOS for an example.
Thread reduce latency because a single process with a state machine has to wait in blocking IO while a thread can go on. See Netscape that hangs in all windows because a TCP connect blocks in pone window for a good and extremely irreitating example. And Mozilla does the same. For that matter, IE too but in IE you can switch it off!
In general, if things are logically different things that run on their own (The UI vs the program that does something in the background) they belong in different threads. If you do not believe me, install BeOS one day ons a 200 Mhz machine and see how much more snappy it than Linux on your multi Ghz machine because the UI things (in their own thread) repond immediately even then the background thing that they control do not. State machines are simply to difficult to handle than seprate threads but because everryon uses them all our programs have godawful latency in the User Interface.
Also, one important thing. ALL computer programs that have an active GUI have two processors in it. The computer AND the user's brain. The part that the user controls is the GUI. That belongs in another thread.
And one last thing. Thread spawning on Linux is very, very good. Mucho better than under most Unixes AFAIK and therefore the "too much overhead" is crap. On Linux at least. And most program will get along just fine with 2-10 threads.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
You know, there are a lot of practical disadvantages to threads.
...except that the read thread is usually written with blocking reads and it's hard to recover when you want to kick that thread out of the read to terminate or restart cleanly.
Threads can be a lot harder to debug.
I don't think gdb really understands threads very well. Other application support is spotty as well. Actually, Solaris has pretty good thread-aware debugging and has good threading tools like deadlock tools.
People who write threaded applications also seem to think it makes life easier. They say - I'll just have a read thread and a write thread and a processing thread.
So people end up using select() anyway. And then they still need interprocess communication to kick the read thread out of the select sometimes.
I think you have to be a better programmer to use threads - you have to be aware of the normal issues plus all the threading issues. Avoid cancelling threads. You have to be very clear how you do signal handling. You have to lock all your data. Don't use fork+exec AND threads. You have to keep track of multiple threads, especially during error conditions.
And you have to be a much better debugger to debug someone else's threaded application.
Not that there aren't good applications for threads, just be aware of the complications.