Here is a little analogy : think of a computer program as a list of things to do (instructions to execute), like the shopping list you have on a "post-it". Then, imagine you are the processor "executing" the list, ie sequentially doing the things on your list one by one. But while you are shopping, you suddently remember that you have another list on which the next item is "stop at the office to get that important document". So you might decide to interrupt your shopping (first list) to stop at your office on the way to grab that document (second list). While you are at your office, you might decide to do some other things on the second list before resuming with the tasks of the fist list.
So what is a thread ? In this example, the threads would be the lists. There would be 2 threads. And the processor (only one : yourself) is executing both lists, switching from one to the other once in a while.
Now you might wonder why have two lists in this case ? You might as well have only one list with your shopping and office work combined. Yes. But in many circomstances, this would not be efficient. Let's say you have a list to do the laundry (gather the clothes, start the machine, wait for it to finish, put the clothes in the dryer, wait for it to finish, fold the clothes and put them away), and a second list to cook the dinner (a receipe for example). Remember that you, the processor, must execute the lists sequentially so if you combine the lists into one (one thread) you would have to do all the laundry before starting cooking. So in this case, better have two threads and start them "simultaneously". So you'll start the laundry, then while the washing machine is working, instead of waiting, you would switch to the cooking and start your receipe. Then, you would interrupt yourself when the washing cycle is completed, start the dryer, and resume cooking.
So that's one processor executing two threads, switching from one another at key moments (when one thread is waiting for something, the processor switches to the other one so it doesn't waste its time).
Now back to our shopping and office work. In this case, there is no waiting. You must do all your shopping and all your office work no matter what. So once again, one could argue that there is no need to have two lists (2 threads). But what if you could delegate some work to somebody else ? So you grad your cell phone, call the office and give your office work list to your colleague. This way, you'll do your shopping, and he'll do the office work. Each of you would have its own list. That's 2 processors executing two threads. And actually, your colleague was probably already executing his own list when you interrupted him. So he switched its context to execute your office work list, then he resumed its own list when he was done. So we actually had 2 processors, executing 3 threads.
Let's look again at you and your washing machine. If we go a step further, you can see your washing machine as one processor executing its thread of things to do to "wash clothes". You are another processor executing the "do the laundry" and "cook the dinner" threads. At one point, you and your washing machine will need to synchronize one another. That is, when the washing cycle is complete, the "wash clothes" thread will let the "do the laundry" thread know that its job is completed. This way, you will pause your "cook the dinner" thread, swich to the "do the laundry" thread to put the clothes in the dryer and star its "dry the clothes" thread, then resume your "cook the dinner" thread. So we now have 3 processors (you, the washing machine, and the dryer), executing 4 threads at different point in time and with synchronization between threads ("do the laundry", "cook the dinner", "wash clothes", and "dry clothes").
So in conclusion, threads are an abstract concept that allow programs to start various independant tasks that could run in alternance on the same processor or concurently in multiple processors. The threads could be totally independant, or they could share data (something to be really careful with !!). They can also "talk" to one another through synchronization signals when the job of one thread is dependant on the job of another one. Threads can be very powerful, but also very tricky !!! In any way, there're really fun to play with !!!!