On Fri, 15 Mar 2002, Malcolm Kavalsky wrote:
I have been following this thread for a while, and feel impelled to
comment:
Don't use threads !
This is the standard Use qmail instead reply to I want to do this with
sendmail. Perhaps pertinent, but not what the one who asked the question
wishes to hear.
I won't comment further, but I'll just say that some of the problems one
encounters with multi-threading exist in one form or another in
multi-processing. Furthermore, multi-threading waiting for
synchronizations can be avoided by using trylock and friends. This will
require a more complicated design, but is doable. (and there are many
times similar phenomena in multi-processing).
I heard an anti-threads rant from a different source, too. However, most
people find problem solving using threads much easier than
multi-processing games, regardless from which OSes they came from. So,
like it or not multi-threading is here to stay.
Regards,
Shlomi Fish
Linux has a very efficient process model and if you are writing any
reasonable
size program and don't want to get into trouble, then I suggest you
split it into
multiple processes and use IPC.
In my 20 years of programming experience, there are very few cases which I
have come across that warrant the use of threads.
The initial appeal of using threads (easy sharing of global data structures,
concurrent programming, low overhead task switching) is quickly dispelled
the minute you start wondering why your program is crashing/dead-locking.
After adding in lots of mutexes to protect all your data structures,
your program
slows to a crawl, and tracing it reveals that 99% of the time is spent
in lock/unlock
calls. Note also that C++ has certain effects that make use of threads
dangerous and
any library calls that you use automatically, need to be checked that
they are MT-safe.
Using processes on the other hand, usually ensures that each task truly
runs in parallel
and the OS protects each task from the other. You need to work a little
harder in the
beginning to setup the IPC, but once that is done, you are home free,
and can more easily
debug your application (each process individually, deterministically).
IPC ensures that
only data that you want to be shared will be, and only when you want it
to be. Note also
that C++ has certain effects that make use of threads dangerous. Any
library calls that
you use automatically, need to be checked that they are MT-safe, even
the most harmless.
Most windows programmers that I have met, are used to working with
threads, and it
is hard to change their habits to use processes. Also, realtime
programmers often are also
used to threads since originally most realtime OSes didn't support
processes, and if they
did then the context switches were too high. Linux, on the other hand,
has an excellent
low-overhead process model which removes 99% of the reason to use threads.
Ousterhout wrote a seminal article titled Why threads are bad which
goes into more
detail ( you can STW for it).
Just my 2 cents worth ...
Malcolm
Shlomi Fish wrote:
On Thu, 14 Mar 2002, Nadav Har'El wrote:
On Thu, Mar 14, 2002, Isaac Aaron wrote about RE: pthreads question:
The thing is, I Read the F Manual (over and over, even considered trying
mit-pthreads instead), did didn't think that I WANT to detach the thread?
(Why detach? I kind of like it... Better keep it).
That's where books are better than manuals - given their length, they can
also give examples and explain the ideas behind why certain things were
done the way they were done, and what they are good for.
I believe, but am not sure, that there are good tutorials and lectures
online about it too. STFW.
The book I'd recommend is David R. Butenhof's Programming with Posix Threads
(see e.g., http://www.amazon.com/exec/obidos/ASIN/0201633922/thealmostcomplet )
If I remember correctly, Butenhof was one of the people working on the
Posix threads standard, and talks a lot about the motivations of how and why
to do things (it talks only on C, of course - if you're looking for OOP
abstractions of threads look elsewhere; I just wrote my own).
You can find some useful abstractions for them here:
http://vipe.technion.ac.il/~shlomif/abstraction/ (under System-Services
Abstractions)
If there's anything missing let me know. And Nadav - you should know
better than to invent your own wheel. ;-)
This is the book I learned Posix threads from.
I learned POSIX threads from online and hard-disk resources, and from my
Structure of OS course. The pthreads API is not very hard or complex,
but of course preventing dead-locks, starvation and other multi-tasking
mishaps is something that requires a lot of though.
Regards,
Shlomi Fish
--
Nadav Har'El| Thursday, Mar 14 2002, 2 Nisan 5762
[EMAIL PROTECTED]
