Mailing List Archive
Support open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tlug: Thread Programming.
- To: email@example.com
- Subject: Re: tlug: Thread Programming.
- From: Adrian Havill <firstname.lastname@example.org>
- Date: Thu, 9 Mar 2000 21:28:41 +0900 (JST)
- Content-ID: <Pine.LNX.email@example.com>
- Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
- In-Reply-To: <38C78E42.160E5BB9@example.com>
- Reply-To: firstname.lastname@example.org
- Sender: email@example.com
On Thu, 9 Mar 2000, Fredric Fredricson wrote: > If you are developing in Linux and you want to make some kind of > server application I advice you to consider multi-process in favor > of threads. > > I can see three major drawbacks for threads: > * A failed thread crashes the whole process, that is the whole > application. > * Threads adds a lot of complexity to a C++ program since the > thread support is built into the language like in Java. Yes-- if this is your first threaded program, you will probably need to relearn your C/POSIX APIs and learn which function/system calls are "reentrant"-- safe for threads and which to avoid, (It could be worse-- most of the MacOS is completely non-reentrant), not to mention worrying about reentrancy of your own programs. Java started with a new API from scratch, so they made sure that everything in the API was thread-safe (they made a few mistakes, but not too many). Most of the newer system calls and newer portions of the C and POSIX standards are also designed to be thread-safe. > * It is difficult to debug and presents plenty of opportunity for > mistakes. You have not experienced debugging hell until you attempt to debug your first thread-syncronization related problem (where the bug only appears "once in a blue moon", and conveniently never appears when you fire up the debugger). Makes C pointer/memory access debugging look easy. :) > Threads have two major advantages: > * Performance (in most OSes) > * Fun! Two more advantages: It's a lot easier for threads to share memory, and the performance is excellent. Of course, there are mechanisms to do this with processes as well, but they are not as fast as are more cumbersome to setup. Granted, it's the fact that threads can share memory that make debugging threaded programs noctoriously difficult for novices to program, as you often must think non-linearly. Also, threads make it easy for one process to spread it's workload across multiple CPUs. Thread based programming really flexes SMP machines muscles. In general, a process can only be running on one CPU at a time. Multi-process servers also use SMP, but it's more work and less efficient to have them work on the same dataset. Threads get there speed because there's less for an OS to keep track of... less overhead in terms of security/memory checking, bookkeeping (PIDs, etc.). Some OSes support threads by treating them as a special kind of process (IRIX 5.3), so while the threads were "light", they weren't as "light" as they could be in terms of spawning performance. > But if you use Linux the performance part is questionable. Windows > does not like processes and multiple processes cause a lot of > overhead. In Linux this is not really the case and most server > applications I have seen (like Apache) uses multi-process. If you take a look at the commercial servers, such as Netscape Enterprise, Zeus, and IIS, they _do_ handle requests via threads rather than processes for performance. Apache emphasis isn't fast-- it's correctness. Granted, Apache isn't slow either-- it gets around the process overhead (launching a process/fork() etc is the most expensive system call-- opening a file is the next) by attempting to pre-allocate servers so it doesn't have to do it on the fly, as spawning processes is slow. FastCGI, PHP, Java servlets are all get a massive speed boost (compared to CGI) because they usually don't have to launch an extra process to handle every request. -------------------------------------------------------------------- Next Technical Meeting: March 11 (Sat) 13:00 Temple University Japan * Topic: "What's new in Perl 5.6" Guest speaker: Simon Cozens (TLUG Perl guru) Next Nomikai Meeting: April 20 (Thu) Linux Conference 2000 Spring Ed. -------------------------------------------------------------------- more info: http://www.tlug.gr.jp Sponsor: Global Online Japan
- Re: tlug: Thread Programming. I apologize in advance if this is off-topic !!!
- From: Fredric Fredricson <Fredric.Fredriksson@example.com>
Home | Main Index | Thread Index
- Prev by Date: Re: tlug: Thread Programming. I apologize in advance if this is off-topic !!!
- Next by Date: tlug: New Member
- Prev by thread: Re: tlug: Thread Programming. I apologize in advance if this is off-topic !!!
- Next by thread: tlug: New Member
Home Page Mailing List Linux and Japan TLUG Members Links