You're confusing a bunch of stuff. I'll try to explain some terminology here. I'll have to simplify a lot, because some of these things are terribly complicated.
A process is an operating system thing. It has nothing to do with your physical hardware. Your OS has to manage programs and their data, so they don't get mixed up. Think of taking a program, the data that belongs to it and stuffing them both in a box. This box is your process.
Inside each box is at least one thread. Like processes, threads aren't a physical hardware thing. They, too, are provided by your OS for management reasons. You can think of a thread the way you'd think of a secretary. She takes the part of the program that needs to be executed, the data that belongs to it and hands it over to a worker. Threads, like secretaries, fill a managerial role; the actual work is done elsewhere.
That elsewhere is a processor core. That's your worker in this analogy. Unlike processes and threads, cores are a hardware thing. They're a physical part of a processor. It's here that the actual work is done.
Your OS can hire extra secretaries for your programs on-demand, but the number of workers is fixed (you'd need to upgrade your processor). Which worker a secretary turns to is usually handled automatically by your OS. It spreads them out intelligently so you get to make the most out of your workers.
If you have more threads (secretaries) than cores (workers), they'll have to make queues. The cores then work through their queue one by one. They usually cycle through them, doing a bit of work for each of them. That way, no thread has to wait for too long.
This is how you could run multiple programs at once back in the old days, where your CPU had only one core.
So if you write a program that has multiple threads, it's automatically spread across cores by your OS. However, you only get a performance benefit from that if your CPU has multiple cores. Without multiple cores, it can only do one thing at a time.