when I have no idea what I'm doing, or why?

Multi-threading is a tough concept for me to grasp. I've tried several times but no luck.

Can some one recommend a good well written book that explains the How, Why, and When of Multi-threading (doesn't matter the language)?

I can't recommend a book. But I can recommend writing some code and playing with it. You have all the tools at your fingertips for free. And plenty of examples of code also for free. What language is your favorite? Start with that and take small steps.

Test it, understand what's happening, then take another step.

disclaimer: haven't done a huge amount with it

how to:

https://www.kernel.org/pub/linux/ker.../perfbook.html
for the classic way of pthreads and such

http://www.usingcsp.com/cspbook.pdf
a scientific look

as to why and when
usually to process a large amount of data that can be processed in parallel
when you have a large amount of data that can be processed in parallel
for example finite element method simulations or skeletal animation in games or.. the list goes on

you shouldn't do it "just 'cuz" as it does have an overhead and will pull cpu cores out of sleep

To me, it's really a very simple concept. Let me try to explain.

The basic "unit of work" that Linux "dispatches" is called a process, and it consists of: the code that's being executed, a private virtual-memory address space, a list of open files, and so on. At any moment in time, most of these processes are "waiting" for some reason. Maybe they're waiting for an I/O operation, or a network packet. Maybe they're just waiting for something to do. Only a few processes are "runnable," and the Linux kernel's "dispatcher" tries to keep them running, doling out "time slices" according to an algorithm that tries to be "fair."

Within a process, there's always at least one "thread of execution," but there might be more. "Threads" share all of the resources of the process to which they belong, but may run independently of one another. For instance, on a multi-core CPU, several cores might be simultaneously running different [distinct ...] threads that belong to the same process. They get "time slices" in the same way, and the process is considered "runnable" if any of its threads are runnable.

It is completely unpredictable "what will happen next." The Linux dispatcher can choose to run anything, anywhere, at any time, for as long of a time-slice as it may choose to give. Furthermore, a process/thread might not use-up its entire slice, if it "goes to sleep again" waiting for something to happen.

Since it is necessary to allow threads and processes to synchronize their activities with those of others, the kernel provides various "synchronization and notification mechanisms," such as mutual-exclusion gates ("mutexes"), semaphores, signals, condition variables and so on.

User-land programs often use a standard library called "POSIX threads" as their interface for using the kernel's facilities, so that those programs do not have to be so operating-system specific. This library exposes a standard set of facilities in a single way, and it is implemented "appropriately" on each operating system.

A why case:

Say you have an application that needs to use the network. Making a request over the network may take some time. If you make a non-threaded network call the program waits until the network call returns, this may make the application look like its crashed due to it waiting.

In a threaded version, you'd write the network call in its own thread. This means the network call can do its own thing whilst the main program can continue happily and doesn't appear to have crashed. Once the network call has finished it could either handle the result or flag that it has finished so the main thread can check and act accordingly.



N.B.
Your main program is your first thread, but not always thought of as a thread because if it doesn't spawn another thread then the concept is moot.



A Typical Issue:
Conceptually its like having two programs doing two different things, but in actual fact threads share resources and memory and is like using both your hands at once. In this analogy be careful of pulling something in two different directions because something will go wrong. What that means is, if two threads try to access the same variable at the same time the results may be unexpected, this is where mutex's come in, they lock the variable whilst one thread completes using it, this forces the other thread to wait until it is safe to do so.




Here's a set of examples at YoLinux:
http://www.yolinux.com/TUTORIALS/Lin...ixThreads.html