A few words on threads

Warning: many strong personal opinions and broad
generalizations to follow.

Someone asked a question about Ruby threads, and the
answers he recieved depressed me, so I thought I'd add my
own two cents.

I'm always amazed, working in an embedded/real-time
programming field as I do, at the aura of mystery and deep
magic that still seems to surround threads whenever they
are brought up in a scripting-language context.  Personally
I can't imagine working without threads for many types of
program.  Threads are practically required for any modern
non-trivial network programming.  Threads are, IMHO, right
above basic file I/O in terms of "concepts that every
programmer needs to have at least a basic knowledge of". 
They are not deep, arcane mysteries used only by gurus in
specialized fields.  They are basic tools of everyday
programming.

In essence, a multi-threaded program is one in which, at
least conceptually, several paths of execution are being
executed at once.  This doesn't (necessarily) have anything
to do with having multiple physical CPUs.  Modern operating
systems simulate concurrent processing using time slices. 
A well-designed operating system takes advantage of
multiple processors by distributing native threads evenly
across the processors; but this is a detail of
implementation that is completely hidden by the OS.

The unix fork() call does not create a thread.  It creates
a Process.  The difference is: a process gets a complete
copy of the environment it's parent process was executing
in.  This means that a copy is made of all the memory
associated with the parent process.  A thread, on the other
hand, executes in the *same* environment as it's parent and
sibling threads.  They all have access to the same
variables, the same data structures.  There are a couple of
results of this:  first, threads are *much* more efficient,
in both memory and processor usage, than processes.  A
native thread can be created very quickly, and the extra
memory overhead it incurs is minimal, just enough to hold
it's stack.  Modern operating systems like Linux and NT are
designed to juggle native threads very efficiently.  The
fact of shared memory also means that threads can work very
intimately with each other; the flip side of this is that
they can very easily get in each other's way and corrupt
shared memory.  These problems have spawned a whole family
of synchronization schemes which, when used properly, can
yield programs where dozens of threads work together in
perfect clockwork harmony.

POSIX threads, aka Pthreads, is a definition of a standard
threading *API*, not an implementation.  Many operating
systems implement Pthreads.  Having a Pthreads
implementation does not mean that the OS implements threads
in a certain way; rather, it means that any hacker coding
for the OS knows (for example) that they can call
spawn(&func), and it will start a thread whose entry point
is 'func'.  They also know that they have access to a
well-defined set of synchronization primitives such as
mutexes.

The meaning of "native threads" in a language is simple: it
means that the language allows the programmer to create
multiple threads which are then scheduled by the OS's
scheduler.  These native threads can take advantage of any
threading optimizations in the kernel.  But the most
important advantage is the preemptiveness of the kernel's
scheduler: there is no way for a single thread to hang up
the entire program, unless the programmer explicitly
arranges for it.  Perl provides an interface to native
threads, as does Python (although I've heard that Python's
implementation is fairly crude).  In Ruby, on the other
hand, when certain system calls are made, the whole program
halts until the call returns.  This can wreak havoc in
programs where certain threads are time-sensitive - for
instance, if a network thread needs to send a heartbeat
packet many times a second to keep a connection alive.   

It's possible to create programs in Ruby which work around
this factor; but there's a certain amount of
trial-and-error involved. To the Ruby beginner who has just
read the Pickaxe, there's no way of knowing that this will
happen until his program mysteriously fails.  Errors caused
by ignorance of Ruby's cooperative threading model fall
into the particularly nasty  "unexpected side-effect"
category of bugs.  ("Why are none of my socket threads
communicating?!! All I added was a thread that reads from a
config file! They have nothing to do with each other!")

All of this, plus the fact that informal testing shows Ruby
threads to be unbelievably slow, is why I'm overjoyed to
hear that native threads are in the works for 2.0.  Until
then, despite Ruby's being one of my all-time favorite
languages, I generally can't even consider it for any
project beyond simple utility scripts.

Related reading: I've heard that the book "Programming with
POSIX(R) Threads" by David Butenhof is the best
introduction to threading concepts in general, and the
POSIX API in specific.  I haven't read it myself.

- Avdi Grimm

P.S. Does anyone here have any theories on /why/ threads
are still percieved as such an arcane topic in the UNIX and
scripting language communities?

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/