On Fri, 15 Mar 2002, Malcolm Kavalsky wrote:
> I have been following this "thread" for a while, and feel impelled to
> "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.
> Linux has a very efficient process model and if you are writing any
> 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 ...
> 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
> >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.
> > Shlomi Fish
> >>Nadav Har'El | Thursday, Mar 14 2002, 2 Nisan 5762
> >>[EMAIL PROTECTED] |-----------------------------------------
> >>Phone: +972-53-245868, ICQ 13349191 |Why aren't fishmongers generous? Their
> >>http://nadav.harel.org.il |business makes them selfish.
> >>To unsubscribe, send mail to [EMAIL PROTECTED] with
> >>the word "unsubscribe" in the message body, e.g., run the command
> >>echo unsubscribe | mail [EMAIL PROTECTED]
> >Shlomi Fish [EMAIL PROTECTED]
> >Home Page: http://t2.technion.ac.il/~shlomif/
> >Home E-mail: [EMAIL PROTECTED]
> >"Let's suppose you have a table with 2^n cups..."
> >"Wait a second - is n a natural number?"
> >To unsubscribe, send mail to [EMAIL PROTECTED] with
> >the word "unsubscribe" in the message body, e.g., run the command
> >echo unsubscribe | mail [EMAIL PROTECTED]
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
Shlomi Fish [EMAIL PROTECTED]
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: [EMAIL PROTECTED]
"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]