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."
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.
"...today consumers have been conditioned to think of beer when they see a bullfrog..."
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.