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."

Comments

Why ?

[noselasd]

Why would a manager need to know this ?
Secondly, if he wants to know it, and already understands fork/exec approache, it should be very easy for you developers to exlain what threads are, and the various synchronization primitives provided. Thats basically all he needs to know, the pthreads api in detail shouldn't concern him unless he wants to program.
What he might be concerned about is portability, remember pthreads are not fully supported on many platforms, and also there are many surprises on other platforms.
this chapter should be all he needs to know + portability issues.

Re:Why ?

[jo42]

Boss person needs to install HeadExtractionDevice_2.0.rpm

Linux is for people who hate Windows, BSD is for people who love UNIX

But separate processes ARE better.

[Kickasso]

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?

Re:But separate processes ARE better.

[sporty]

Better is always relative. It's relative to what you are doing, how you are doing it, where and how.

Forking has a context switch to deal with. That's a fact. Now if I was doing some heavy mathematical computation that required new processes every second for a long period of time, threads would win out.

If i need to split off the process once per day, forking is fine.

As for protection, it's a mutex lock. Learn to use them properly, no deadlocks or ill use of resources, and you are fine. It's extra work for using threads, but isn't it worth it if you save thousands of context switches on fork()ing per second if you need to do parallel processing to that scale?

Re:But separate processes ARE better.

[Blob Pet]

Didn't they teach you to use protection, or something?

Only in Sex Education and Operating Systems I.

Re:But separate processes ARE better.

[Anonymous Coward]

>> Forking has a context switch to deal with. That's a fact. Now if I was doing some heavy mathematical computation that required new processes every second for a long period of time, threads would win out.

Thread creation must have a context switch too... and even more, threads on linux are in fact processes. Process creation on modern Unixes is very cheap. (Windows is a totally different story - process creation is way more expensive than thread creation - that's why they push the concept of threads so agressively). AFAIK Threads are not really a big win in most cases. Sometimes, an user level thread implementation may be faster than a kernel thread implementation. (Read about KSE on FreeBSD and you'll know why). Threads are a win only if you're running on a SMP box, and even then, you must be careful how to use them(coarse locking vs fine grained locking).

As for programming concepts, threads may sometimes be a more elegant solution than using a state machine(threads vs socket multiplexing with select() for example).

>>If i need to split off the process once per day, forking is fine.

Bullshit.

>> It's extra work for using threads, but isn't it worth it if you save thousands of context switches on fork()ing per second if you need to do parallel processing to that scale?

As I said earlier, even threads have conext switches(depending on the implementation, a thread context switch might be cheaper(LWP on Solaris) than a process context switch, but it's a context switch in either case). Only when you're using some sort of user-level threads (ex. GNU/pth) you're context-switch free, but you cannot run on SMP.

People mistankely think that using threads will increase performance, but it's not true for many cases.

Re:But separate processes ARE better.

[Blob Pet]

a pretty good summary that i agree with
taken from http://basil.cs.uwp.edu/Cs370/notes/Threads.doc:

Advantages (Thread vs. Process):
-Much quicker to create a thread than a process.
-Much quicker to switch between threads than to switch between processes.
-Threads share data easily

Disadvantages (Thread vs. Process):
-No security between threads:
---One thread can stomp on another thread's data.
-For threads which are supported by user thread package instead of the kernel:
---If one thread blocks, all threads in task block.

Re:But separate processes ARE better.

[sporty]

>>If i need to split off the process once per day, forking is fine.

Bullshit.

Some context switches are cheaper than others :P Point being, fork has had a long running history of more expensive context switches copying code from a written to memory block and process creation vs threads. :P

This is the only time I'll respond to an AC since "bullshit" is apparently an argument now-a-days.

Re:But separate processes ARE better.

[edward.virtually@pob]

I wish I had bosses like that. Nice to know not everyone in the industry has bought into the threads hype. Threads are great for lazy programmers and bad for everyone else. I'm still waiting for a version of Mozilla that doesn't die when one sub-window dies on a bad page (due to defective flash, Java, whatever). Forked processes are properly isolated from each other, threads are not.

Re:But separate processes ARE better.

[LunaticLeo]

I must disagree with your advantages/disadvantages list. It was mostly accurate a decade ago and still true on some poorly designed operating systems (like Solaris).

> Advantages (Thread vs. Process):
> - Much quicker to create a thread than a process.
"Much" is the nit I am picking here. The main difference between a process and a thread is that threads share the VM. Modern operating systems do Copy-On-Write (COW) for process creation. Hence, the diff between threads and processes is the creation of Page Table Entries (PTEs) in the process example (but that isn't as dramatically slow as copying the pages). Given that VM issues are the biggest performance issue in proccess creation versus thread creation, with COW you should only see minor to moderate speed hit for process creation versus thread creation.

> -Much quicker to switch between threads than to switch between processes.
That is again an implementation issue, and not true in the general case. Solaris makes context switching between processes slow compared to context switching between threads. Don't think of Solaris as a good example of a performance operating system (they have other things just not performance). An old benchmark comparison I saw, (circa 1998), it was lmbench running on Linux and Solaris 2.5.1 on the same UltraSparce hardware. The bottom line is that Linux's process context switching was faster than Solaris' thread (LWP) context switching.

> -Threads share data easily

Urr! I know you meant that it is easy because you can just pass pointers versus using some data sharing API like SysV shared memory. But I think threads are difficult to share memory _effectively_. Either you lock shared resources, or you get clever with thread safe algorithms/data structures. And that stuff gets real HARD real FAST.

I just realized that you were including user space threading packages in your definition of threads. Yeah they can be pretty fast.

If you want to expand your mind beyond this simpletons game of debating threads. Check out event driven systems, and co-routines. There are different trade offs for sure, but they are easier to debug than threads.

Re:But separate processes ARE better.

[Blob Pet]

I think you make some strong points...

However, when you say...

But I think threads are difficult to share memory _effectively_. Either you lock shared resources, or you get clever with thread safe algorithms/data structures. And that stuff gets real HARD real FAST. ....

you have to realize that sharing data structures amongst processes are often times going to require using similar algorithms ( like your typical muliple writer/multiple reader ones) but with semaphores. The API might be different between using a pthread mutex and a semaphore, but where you place those p() and v() calls are essentially the same.

Re:But separate processes ARE better.

[sudog]

One fork() per second (especially in Linux where threads are "emulated" with clone()) has similar impact under Linux to using threads.

But why bother with threads? Use one process per CPU (if needed) and accept computational tasks using either shared memory or message-passing.

Event-queues! There's the ticket! Single-process event queues..! Ha ha! Be a masochist with me and join the event-queue fanclub!

Re:But separate processes ARE better.

[LunaticLeo]

you have to realize that sharing data structures amongst processes are often times going to require using similar algorithms

Your point it correct. I really wanted to make the point about debugging code using shared resources, not writing the code. I meant "effective" in the sense of limiting opportunity for bugs, and quickly killing the ones that show up.

It is easier to debug processes than threads (re: availability and maturity of tools). It is conceptually easier to focus on debugging known limitied shared resources.

A point I didn't originally make, was that context switching is most important when you are switching alot (duh!). First, you don't want to be switching alot that is called "load" and you are thrashing your caches whether or not it is threads or proceses. However, Context switching does naturally occur when you are message passing between two processes/threads (another reason micro-kernels are inevitably slow). I think message passing is really good, but the rate and size of messages can really blow performance with context switching, cache thrashing, and marshalling/unmarshalling. I still like it. :)

Re:But separate processes ARE better.

[lifeless]

> > - Much quicker to create a thread than a process.
> "Much" is the nit I am picking here. The main
> difference between a process and a thread is that
> threads share the VM. Modern operating systems do
> Copy-On-Write (COW) for process creation.

Modem UNIX-LIKE operating systems, yes. But the all-processes-descend-from-init model is not the only one in existance. In fact, Win32 doesn't have a native fork() call at all. And it does have at least one native pthreads library (http://sources.redhat.com/pthreads-win32/).

So, under Win32, thread creation is *much* faster than process creation, for a number of reasons (and COW is only part of that).

--Rob
(Cygwin pthreads maintainer)

Re:But separate processes ARE better.

[Anonymous Coward]

actually event queues ARE the ticket. if you have a hyperthreaded processor, using simple event queues and leaving process scheduling to the processor itself will yield better performance since the sharing is done physically in hardware. once process per virtual hyperthreaded CPU and message passing is the ticket.

Re:But separate processes ARE better.

[LunaticLeo]

under Win32, thread creation is *much* faster than process creation, for a number of reasons (and COW is only part of that)

I am aware of the init-fork model versus VMS/Win32 model of spawning processes without any inheritance.

I would love to know what makes spawn() or CreateProcess() (I think those are the respective calls) so much slower in the thread versus process? I realize creating the task struct and inititializing its parts is greater than thread init, but is it the same order of magnitude of slowness as on old non-COW operating systems?

Re:But separate processes ARE better.

[lifeless]

I can't speak for VMS - not with any accuracy anyway :}.

On WIN32, creating a process involves:
* Allocating a new thread and process kernel structs (~ Same overhead as COW fork())
* Map the process to be loaded into memory (COW fork() doesn't do this, but exec() does)
* Recursively resolve all unresolved symbols. - which includes looking through the oftimes long PATH variable, as win32 doesn't have a separate LD_PATH. (COW fork() doesn't do this, but exec() does)
* Attach all the loaded dll's (COW fork doesn't do this. exec() has something similar, IIRC).
* Finally, the WinMain function gets to run (fork() doesn't start at main again, but exec() does).

So, the fork + exec model is roughly the same overhead as CreateProcess. The fork(), serve and exit() model is much lower on unix-like os's that support COW fork() because theres less to do. And any OS that has no kernel fork() call is way behind to start with.

Hope that helps. I've probably missed something critical and will now die a flaming death. Oh well :].

Right...

[jasoncart]

I don't even know what pthreads are, but I can answer this one...

http://www.google.com/search?q=pthreads shows, for starters :

• A Pthreads Tutorial, written by Andrae Muys
• O'Reilly "Pthreads Programming"
• Pthreads Overview
• Introduction to PThreads

Re:Right...

[eggstasy]

Well I'm not an expert on anything but I studied them in my third year of college...
Pthreads stands for POSIX threads.
Threads are different "paths of execution" through a program that can be run in parallel. They have both advantages and disadvantages, without getting into a lot of technical details, they are generally regarded as "lighter" in terms of resource consumption and easier to code for.
The general idea is that when launching a new thread you launch a function in your program, so you can launch the music function in a game and then the graphics engine function and the keyboard reading function, etc, having them run simultaneously.

Re:Right...

[divbyzero]

As someone who does know what pthreads are and uses them frequently in a professional setting, I would recommend the O'Reilly book mentioned above. It contains a decent introduction to threading in general, a healthy dose of usage scenarios with detailed explanations, and a programmers' reference. If I remember correctly, it was written by some of the folks at DEC who designed most of the pthreads standard and wrote the first implementation. However, although it does a nice job of explaining the difference between threads and forked processes, it does not attempt to make any bias-free recommendations as to when forked processes might be more appropriate for a task.

what how why tutorial

[erinacht]

You said the manager was tech savvy - bit of an oxymoron, but Check here for a what/how/why tutorial on pthreads.

For you managers out there...

[sporty]

For you managers out there, it's good to listen to your developers and let them show you things. Sometimes when they wish to use a technology or method, it's for VERY good reason.

There are a lot of managers out there who distance themselves... so be happy they are learning the technology vs a 2 minute shpeel on why they should use something.

Whats the Royal diff btw threads and processes

[mnmn]

I've done some reading on these and Ive come up with:

(1) Threads are in the same process, so you would see just 1 in ps ax.
(2) Threads are new. Not many apps use it and older linuxen dont either.
(3) Everything is shared btw threads.
(4) Threads are a part of POSIX standard

I know nothing else. I couldnt find the why and how of it, and what condition will warrant the use of threads but not processes. Can someone give a clear and convincing reason to use threads over processes??(despite the overhead of learning it, and some incompatibilities across ports)

Re:Whats the Royal diff btw threads and processes

[noselasd]

> (1) Threads are in the same process, so you would see just 1 in ps ax.
On Linux , as far as the kernel is concerned, a thread is a process,
threads are shown as a process in ps. This will change much with the new 2.6 kernel(and newer ps/top utils)

>Threads are new. Not many apps use it and older linuxen dont either.
There are wast number of application that uses it(though not as common as forking/nonblocking programming yet)
Most desktops. Mozilla,OpeoOffice, Java, named, etc.

>(3) Everything is shared btw threads.
Not the stack.

Re:Whats the Royal diff btw threads and processes

[jeffy124]

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.

Oi?

[Kickasso]

fork() is a context switch, but so is pthread_create(), unless you have green threads which sux0r.

Yes, switching between different processes is usually slower than between threads in the same process. If this is your concern, you probably better off having exactly one thread/process per CPU.

Mutex lock is an excellent protection against deadlocks (you need to use it with shared memory anyway), but it's less useful against plain old fashioned core dumps.

Re:Oi?

[sporty]

Ah, but the cost of fork is higher in the process creation.... process :) What's worse, is the copying of memory on the changing of variables in a fork'd process. With threads, you know ahead of time what will be changing and can compensate for it.

This may seem harsh ...

[cyberkreiger]

... but really, what you have to do is tell the boss:

"I'm sorry boss, i love you and all, but i'm the engineer here, and decisions like these are none of your business. If you're sure it would be done better without pthreads, then fine, code up a testcase, and we'll see."

Re:This may seem harsh ...

[Havokmon]

Umm close. The message is right, the delivery is wrong. You don't tell your boss to do the footwork, that's why YOU'RE the peon. Besides, based on that delivery I can tell you right now: You need your day job. :)

"I understand you're lack of support for pthreads comes from an admitted lack of understanding of them. But having used them, I can tell you the only differences are A, B, C. If you're sure it would be done better without pthreads, then ok, I'LL code up a testcase, and we'll see how readable the code is, and how well it runs."

Keep in mind, because someone has the title 'Manager' doesn't mean they don't know a damn thing (I'm a 'Manager', but I'm also the only IT person. For me, it includes everything from Network Admin, to PBX Admin, to Programmer, to Invoice authorizer). Rather, it means they can explain themselves without coming across as a total ass.

Keep that in mind. (I always have a problem explaining things in an easy-to-understand way without making my opponant look like a moron.)

Communications Needed

[4of12]

By all accounts, if your perception is that:

• boss is technically astute
• boss hates pthreads cuz he doesn't understand `em

Then there's inherent contradictions.

You need to learn how to talk to your boss more, listen more, and, after listening, patiently explain with about 2 viewgraphs of bulleted items, the key features of threads and processes, with an even-handed listing of their respective pros and cons.

Then let him make a decision. Tell him your opinion is that pthreads is a better choice for this project, but you'll go with whatever he decides. In turn, express your appreciation for him holding up whatever decision and supporting you whichever way you go.

It wouldn't hurt your case if you explained that you've programmed in pthreads before, are familiar with the pitfalls and have encountered them previously, and think they are outweighed by the advantages. Tell him that only if it's true, though:)

Re:Communications Needed

[sql*kitten]

Then there's inherent contradictions.

Most likely, the bosses concern is that it might be more difficult to hire people who understand pthreads than people who understand forking. This is a very valid concern. That's one of the reasons for the popularity of Solaris, Windows, Oracle, Motif, Java etc - there's a huge pool of people who know how to develop and maintain applications on them. For a given application, Smalltalk might be the best language on purely technical grounds and for the next project it might be LISP, but most sane organizations will do both projects in C because everyone knows C.

Re:Communications Needed

[GeckoX]

Everyone knows c ehh?
Wow, I sure wish I knew the same everyone that you do ;-)

Re:Communications Needed

[Jahf]

If the boss really is knowledgeable, it's not necessarily a contradiction. He could be that "one in a million" truly good manager who really does understand pthreads and currently rejects them on their merits, but to help his employee save face is allowing the employee a chance to change his viewpoint without forcing it into an argument, thereby also finding out for sure if the employee really knows what he is talking about.

Nah.

Re:Communications Needed

[sudog]

Well it seems simple enough to me: Show him what it would take to write an event queue and then call him a pussy when he blanches!

Event queues dammit! select(), poll(), or signal-driven event queues are the way to go for anyone who wants to do something Really Impressive.

Re:Communications Needed

[Anonymous Coward]

sql*kitten, this is the first time I've ever agreed with your normally stupid non-insightful half-baked arguments.

For once, a manager is right...

[Anonymous Coward]

I'm thinking that if you can't give your manager a brief synopsis, then maybe he is right and you shouldn't be using pthreads...

Book Recoomendations:

[D.A. Zollinger]

Good: "Pthreads for Dummies"

Better: "Pthreads for Managers"

Best: "Pthreads for the Mentally Retarded"

Maybe the magager is right.

[Webmonger]

Could be your manager is making the right call? Obviously, the roles in your group aren't clear to me. In my team, I'm the lead programmer, and I'm pretty conservative about adopting tech.

I don't just need to understand a technology, I need a deep undertanding of its strengths and weaknesses before I can start including it in our programs in intelligent ways. In practice, it means that I experiment with new things before I'll let the team use them.

Re:Maybe the magager is right.

[sporty]

Well, that's probably a good reason the manager is asking for resources, nuh? Not to say that the manager won't be right in the end, but at least he/she is willing to become more informed.

This sounds to me like a misunderstanding...

[joto]

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).

I applaud your boss for his decision. There are many disadvantages of using threads, that I'm more than sure your boss knows about. See e.g. this discussion for more detail.

Now, granted, some applications will also benefit enough from threads to outweigh those disadvantages. It is rare, but it happens.

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."

If you have a boss that already knows enough technical stuff to micromanage your project in this way, I'm sure he is capable of googling out a pthread introduction himself. What you should be focusing on is explaining exactly why your projects needs threads, and why fork()/exec() won't cut it. This may also result in you accepting his decision, but that is as it should be.

AC summary

[nickos]

"A computer is a state machine. Threads are for people who can't program state machines." -- Alan Cox

Should your manager be a manager?

[slhastings]

If your manager is making limiting and consequential technical decisions becuase of his/her lack of knowledge on the subject should they be managing.

Book reference

[jholder]

Sun Microsystems Press has the best book I've read on the subject. "Better" than the traditional methods is up to your design. If you are spawning MANY processes per minute, on some implementaions pthreads will be much faster. There are some other payoffs as well, but really it comes down to what you are really trying to do...

Re:Book reference

[jholder]

Bah! I copied the wrong link, I meant the Klienman book.

Why are you asking us

[Anonymous Coward]

I mean, if you need to ask others then it means you don't understand pthreads either. No shame there, so please don't be offended. Now, with this in mind, why do you want to push this technology? To what ends young man, to what ends? I go with your conservative boss.

p.s. I'm a luddite that thinks hype = shyte.

Think this through....

[cybermace5]

Managers aren't always wrong.

Laugh, but it seems to be a common attitude that a manager is never right, and never will be.

Your manager is not there to code, he's there to keep all of you developers on task. Apparently, for some reason he needs to understand your code, in order to do his job to his satisfaction.

Actually, he may not NEED to understand pthreads at all. But I believe his approach is pretty smart in this case. Why should he allow you to adopt a new method, when you cannot explain it to him?

I wouldn't let you use pthreads either, if my paycheck depended on you getting your job done.

What's the difference?

[Tuxinatorium]

'pthreads for Dummies', 'pthreads for Pointy-Haired-Bosses'...

The C10K problem

[bob@dB.org]

may no be what you'r looking for, but gives a lot of insight into different ways of dealing with this (prosesses, thread etc) problem. from Dan Kegel The C10K problem

It's time for web servers to handle ten thousand clients simultaneously, don't you think? After all, the web is a big place now.

And computers are big, too. You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1500 or so. Let's see - at 20000 clients, that's 500KHz, 100Kbytes, and 50Kbits/sec per client. It shouldn't take any more horsepower than that to take four kilobytes from the disk and send them to the network once a second for each of twenty thousand clients. (That works out to $0.08 per client, by the way. Those $100/client licensing fees some operating systems charge are starting to look a little heavy!) So hardware is no longer the bottleneck.

technically astute?

[aminorex]

Threads are a fork that keeps all memory shared
except the stack. That's pretty darn simple, and
probably all he needs to know.

However, he's probably right. Threads are horribly
abused in most applications. They create bloat
and spaghetti code opportunities that lead to
user dissatisfaction and unreasonable maintenance
costs.

Threads should be used if you need SMP scaling
for a I/O intensive application, or shared memory
decomposition of a problem space dominates the
structure of the code. Otherwise, small
is beautiful, and asynchronous I/O is far more
efficient and elegant (which means maintainable).

The O'Reilly pthreads book is good.

[munro]

The O'Reilly pthreads book is a pretty readable and quick introduction for someone who knows C -- it explains the concepts, the API, and locking etc problems you will encounter and how to solve them.

It introduces the classic models with code examples and good diagrams and explanations (boss/workers, consumer/producer, peer workers etc) but it doesn't go much into real program or algorithm design with multiple threads of execution however, which is of course another can of worms (but you're already dealing with that sort of problem since you've said he likes you to use fork()s).

YMMV, I have a fairly old edition (1994 or something)...

Dear Slasdot;

[Anonymous Coward]

Dear slashdot. My company uses Linux. I've tried to explain to my technical manager (who is very astute) that I would really like to have Windows 2000 installed on my machine so I can play half life. He says "no" and that work computers are for work. Can I get a bunch of slashdot readers to email bomb him until I get windows 2000?

This says more about your mgr. than anything else

[DuckDuckBOOM!]

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.

Is your manager's name Mowgli, perchance? If he really were reasonable about these things, the answer would have been "Set up a couple of benchmarks; we'll beat on them awhile and use the method that yields the best result." And then, if the pthreaded model proved superior, he would study it until he did understand.

DDB (who's had to deal with entirely too many managers whose concept of "appropriate" or "proven" tech == "what I know & am comfortable with")

What you need to prove...

[Hard_Code]

...to your manager:

1) cost savings short term
2) cost savings long term

Anything else is just typical geek elitism. "Hey, let's use foobar technology because it's, well, COOL!"

If you are developing on Linux the new threads implementation shall kick ass anyway, so it should become sort of moot.

Processes are lightweight in linux

[xiox]

Processes are lightweight in linux. See e.g. this. If you are on Solaris or Windows then you might have to look at threads to get speed (but not security). It may be that threads are more lightweight in Linux nowadays, but process creation is fast under linux.

Processes get you a number of advantages above.

State machines are for macho programmer

[tigersha]

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.

Re:State machines are for macho programmer

[Anonymous Coward]

"A computer is a state machine. Threads are for people who can't program state machines." -- Alan Cox

God that is stupid. OK, let met put it another way.

What'd you expect from the guy who won't release the details of security patches?

Threads

[Anonymous Coward]

"A computer is a state machine. Threads are for people who can't program state machines." -- Alan Cox

some disadvantages...

[Polo]

You know, there are a lot of practical disadvantages to threads.

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. ...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.
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.

Threads are *way* overrated

[Panoramix]

Just a short rant on my experience and conclusions regarding threads. Me, having been formed in the "new age" school of programming (trained on the Commodore Amiga), always used threads. Used to design all my software with threads in mind. But not anymore. Since my jump to Unix, some five years ago, I've experienced a rather deep change of perception on this issue.

IMO, threaded code is much, much harder to implement correctly, and to debug, than single-threaded code. I used to blame the crappy thread support of many Unix libraries and tools. But now that gdb supports threads, along with pretty much everything else (except gprof, but the workaround is simple), I've found that it still is a PIA to debug all but the simplest threaded apps.

After years of hard work trying to determine what library calls are not reentrant, how are asynchronous signals delivered in each platform you support (God! Never, ever, ever mix threads and signals when writing portable code, not if you can avoid it), and which objects should be synchronized to get the best compromise between sync overhead and avoiding trashing the heap, you just fall in love with a design in which no locking is necessary at all. No ambiguities in library calls, no undocumented whatever_r() calls, no weird signal handling. A design in which a single core dump can tell you EXACTLY what was your program doing and why did it crash. Really, the simplicity and elegance of Unix programming without threads is just beautiful. The best adjective I can come up with is "liberating".

Of course, you do have to switch to a state-machine kind of mentality when designing your applications. It is not easy (was not easy for me, at least). But it can be done very cleanly and elegantly (for an example, look for the "State" pattern, the one in which you derive classes for representing your state machine states). If portability is not an issue, it can also be done very efficiently, if you use IO signals instead of select().

Now, having said all that, I'll now point out that I still use threads, because my code usually has to run on WIN32 too, and programming without threads there is hell (not that programming with them is much better). But I avoid threads as much as I can. I still worry about writing reentrant functions, because I find that to be a very good practice, even if no threads ae involved. But threads are used only when no other portable solution cuts it (like when checking asynchronusly for activity on non-socket descriptors, on WIN32).

A very good, brief pthreads tutorial

[n1ywb]

One of my instructors has written a very clear and concise pthreads tutorial. You can find it in postscript, pdf, and LaTeX formats.

It gets right to the point and includes simple C code examples showing how to create and manipulate threads, mutex's, and condition variables. It's still a draft, but you might find it usefull.

Here is the introduction to the paper:
"This document is intended to be a short but useful tutorial on how to use POSIX threads (pthreads). In this document I do not attempt to give a full description of all pthread features. Instead I hope to give you enough information to use pthreads in a basic, yet effective way. Please refer to a text on pthreads for the more esoteric details of the standard.

"In addition to talking about the pthread interface itself, I also spend time in this document discussion some issues regarding thread programming in general. While not specific to pthreads, it is a must that you understand these issues if you are to use pthreads--or any thread library--effectively."

Your impression of your boss may be incorrect

[Screaming Lunatic]

The boss (who is very technically astute)

Not trying to flamebait here. But if your boss is really technically astute, he should be able to do the research, assess the pros and cons, and make a decision.

He should be able to pick up a book, google for some benchmarks, and talk to some people either face-to-face or on Usenet and then make a decision. A manager should be able to make this decision based on the facts over the weekend.

A very good manager would be able to make the decision in an afternoon. The real difference between good management and bad management is the rate at which you can make well-informed decision.

It's da future man

[Anonymous Coward]

pipe/fork/exec is old school + way high overhead. Threads are thin + fast and will translate extremely well to parallel cpus (ie future architectures now that we (once again) can't make cpus faster and faster.) Getting experience with pthreads is good for longer term work. There are a few gotchas but you get used to them, mostly don't use statics within functions, make sure you clean up after threads exit (detach them), and of course don't leave any open files around or memory leaks. But there is a cleanliness to threads that fork/exec doesn't have (IMO).

Exactly

[Anonymous Coward]

His boss was tactfully saying "I do not trust my programmers' abilities well enough to implement this code using threads". He sounds like a wise man.

Perhaps your boss isn't clueless

[Anonymous Coward]

Threads suck. Fork() works much better. Don't forget, a fork() on linux is about as heavyweight as a thread on NT, and about THE SAME WEIGHT as a thread on linux. Linux threads are just clone()ed processes.

I see loads of Windows-programmers who have transitioned to Linux these days, and, to a man, they try and use threads. Fork() is so much cleaner, safer and neater for little or no performance hit (don't forget, local socket I/O is zero-copy on Linux, and shared mmap()ed files are, well, shared.)

Maybe the boss really knows what he's doing.

[TheLink]

Sun Tzu:
"Do not oppose those with their backs to the wall."
"Leave an escape route for a surrounded army."

Maybe the boss really knows that pthreads aren't the way to solve the particular problems they have. I'm not that technically astute so I wouldn't use threads for a production app. But from the little I know, if I'm the boss I'll require someone _very_very_ good at pthreads to implement a production app.

So what if this guy doesn't seem good enough to the boss?

So he gives him a way to prove he is good enough (explain why pthreads is better to the boss), AND also a way to save face if he isn't.

Better than risking:
a) Misjudging this guy capabilities and thus create resentment and making him less useful.
OR
b) Correctly judging his current capabilities but in the process obliterating this guy's ego/confidence and thus potentially making him less useful to you.

The tradeoff is a little loss in respect at technical matters by claiming to not understand pthreads (do recall that the subordinate still does believe that the boss is very technically astute).

There might be a better way to handle such a scenario. But I'm going to sleep :).

Re:Maybe the boss really knows what he's doing.

[TheLink]

Agh, yah that was redundant.

I need to sleep :).

Your examples

[TheLink]

You say Netscape/etc hangs in all windows when a TCP connect blocks in one window. That only happens if you are using Netscape with threads. Not if Netscape is in a separate process.

Your point that 2.5 different threaded browsers have that "one window blocks others" problem, seems to be more an example against using threads to me.

I think in most situations on Linux/FreeBSD it is best not to use threads. Use fork - default unshared memory, and then just explicitly share memory if necessary. Safer and easier to debug than "share everything".

And if one browser instance dies, it doesn't take the other 30 with it.

dummies and managers

[Anonymous Coward]

while conceptually they are very much different (and I mean "dummies" here as "unitiated" or just "ignorant") the sad fact is that as a whole the IT industry is set upon by an over abundance of many who bridge that gulf of terms very well. This is especially the case with government related projects and I can't help but wonder if this whole idea "Dummies vs. Managers" should in fact be a certified and thus annually required course for all management unless some way is made for them to "permenantly" test out due to a proven capacity to seek quality and avoid mindless red tape filler.

I just have to say that the poster here has my jealousy aimed squarely at him :) It is a very rare manager I have had that 1) had even the desire to understand the projects they managed (read: do their JOB) and 2) pragmatically and realistically admit their shortcomings. Of course number two, the astute reader will note, is in reality nothing but a manifestation of number 1.

Congratulations on having a manager who actually gives a crap. If only I could somehow bestow that care and concern upon the mindless snake-oil-salesmen we have, then that energy of them wandering around trolling up trouble instead of managing the people and projects under them would create a fantastic work environment with products we could be proud of. Who needs enemies when your officers are the ones causing more loss of ground and casaulties then any initiative by your enemies themselves?