threads

[Diez B. Roggisch]

Hi,

> If the above is not suitable for threading, please give me a short
> example of something that is.

Its not suitable for threading. The reason is that threading itself doesn't
give you magically more computational power. Threading simply allows for
severeal threads of execution - hence the name - to be performed
(quasi-)parallel. Its similar to multi-processing: you can start several
processes (programs, so to speak), and they appear to work simultanously.
This is achieved by interrupting each process after a certain amount of
time, put it to sleep and continue to execute another process. This is done
at so short time-slices that it appears to the human user that everything
works in parallel. 

Threads and processes differ in what scope they run in. In a modern OS like
*NIXes and e.g XP/NT, all processes run in separate portions of memory, and
can't access other processes memory. This can only achieved explicitely by
inter process communication, which is a wide topic and I won't dive into it
right here.

OTH Threads are parallel threads of execution "inside" one process. They all
share the same memory and thus variables and data-structures. The
responsibilities are now reverse: You can access everything, so to prevent
thread A from altering a datum thread B is currently working on, you have
to somehow serialize/synchronize access to that datum. This is done using
semaphores, mutexes or locks - things you can read about in the api docs.

Now when do you _need_ threads then? This easier asked than answered, and
sometimes a question of choice or taste. But I think these are some
indicators:

 - you want several parts of your program to be responsive to user input
while they perform some actual work. I bet you have expirienced locked GUIs
in programs that were doing some stuff, like decompression an archive or
the like - this could be avoided by a special gui-thread that allows you to
tinker with menus/buttons while the work is done in the background.

 - if you actually have a mulitprocessor-machine, the quasi from
quasi-parallel vanishes. Then one processor can execute one thread, and
another one the other. Of course this scales only up to the number of
processsors you have.

 - in languages that don't features like coroutines/generators, sometimes
applicatioin logic is much more natural when expressed in different
threads, where each thread has his own call-stack, state and so on. This is
e.g. the case in JAVA. However, there _is_ a cost for that, as the so
called context-switch between threads isnt't for free, and synchronizing
can eat up precious time.

 - some people use threads to handle blocking io. This is similar to the
point above - if you have a net-based protocol, its much more natural to
implemnt when you don't have to care if and when its waiting for input and
then would pass back execution to a point where your program waits for all
your sockets to return with data. Then you'd have to dispatch to the
appropriate part of the protocol-implementation. A thread just would sit on
the socket and wait until it returns. Then the logic goes on uninterrupted.

Hope that shed some light on it for you,

Diez