Long ago, at the brink of the Information Age, a computer only had a single CPU that only could run a single program at a time. If multiple people had to use it, you used time sharing: make an appointment for a time slot.
A bit later came cooperative multitasking. Which meant: we increase the frequency of the time slices a fair bit, to about 5 a second at first, but thousands later. So you can load and run multiple programs at the same time, as long as they're all considerate of one another. Give each other the room they need to run. Which was actually quite hard, as access to many resources wasn't shared. Hey, we have no printer drivers or print spooler, so be gentle when accessing it, ok?
To make that actually work, the Virtual Machine was born. Like, if you had a 80386 CPU, you could go big and wide, by giving all resources to a single process, or you could go many and small, by dividing the available resources into virtual 8086 machines. Chop up the ram into 1 MB chunks and use all the extended functionality for the OS. As long as the OS took care of all the devices, it worked very well. That requires that the OS runs in protected/supervisor mode and that it is automatically triggered if a client tries to access something it shouldn't.
Now is chopping up the memory into pieces that are all the maximum size a child process can access an easy thing to do, but it's not very efficient. It is much better if the client thinks it has all the RAM it
can use, but actually only has the RAM it
does use. And most often that is done by paging: if a client process tries to access memory somewhere, quickly insert a block of 4kB of RAM on that location.
While all of that works quite well, it is a bit slowish. Simply because you have to switch between user mode and protected mode all the time, to access resources. And because you have to do all that paging. And depending on the OS, communicating with other processes can be a hassle.
To fix that, threads were born: while you do get a new stack for each sub-process you create and the registers are saved when it gets activated, you share all the other resources with the main program. The good: it is faster and you only have to set up everything once. The bad: no protection! You have to supply that yourself. So, it's exactly like cooperative multitasking.
A thread is basically just a location the CPU starts executing commands from at intervals. A single "main" function. If you exit that, processing stops. So you normally make a loop, that is like this:
function Main();
var
Terminated: Boolean;
begin
Terminated := False;
while not Terminated do
begin
// the work you want to do goes here
end;
end;
Well, that's an endless loop if you never change the state of Terminated. But because the address space is shared between your thread and the main process, both can do that. The main process can order the thread to stop by setting it to True. The good and the bad, in one go. Because if both try to access it at the same time, Bad Things happen.
So, the main thing with threads is: make sure it behaves! Don't try to access any memory or resources you didn't allocate yourself within that tread. And prevent exceptions.
How to use them?
There's basically two ways: SMP (symmetric multiprocessing) and tasks. In the first instance, all the threads do the same thing, for the same amount of time. This is easiest to set up, but hardest to get good use out of. And the second one is that you create each thread when needed and give it all resources it needs at the start. When it is done, it reports the result and disappears. More bookkeeping with a chance of erratic threads, but it makes best use of the available resources (like the CPU time).
In the first case (SMP), you divide the RAM and data up front (like, thread 1 does everything starting with "A..C"). Accessing resources meant for your sibling threads is a good way to crash. And in the second case (tasks), you make a copy of all the data the thread is allowed to access up front.
That's about it. If you feel you need a lot of mechanisms to partition things, like critical sections, or to communicate, like semaphores, it's probably better to revise the design and see if you can do it without them.