Re: tlug: Thread Programming.

[Adrian Havill <havill@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