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

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.

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.

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