A thread in the most general definition is a processing unit context which can be saved and restored by the execution environment. Threads provide indepedent streams of execution within a shared memory system. Most modern general purpose operating systems provide out of the box facilities for threading.
Threads are traditionally contrasted againsted processes, which don't traditionally share memory. When a lot of shared data must be read and written then threads accel by providing lower overhead than the traditional multiporcess model.
Threads haven't always been supported as first class citizens. Over the years there have been two major approaches to implementing threads I'm aware of.
A native thread is known to the underlying scheduling units of the kernel. Generally, each thread can have a different priority and will be queued with all other threads within the system. This approach delegates a lot of more complex issues such as lock contention to the operating system. If a single thread gets blocked on an IPC (including kernel system calls) call then all other threads are free to continue execution. Additionally each thread may execute on different physical CPUs.
Green threads are handled by a library in the execution environment. The library will determine when to run each thread. At least two major downsides occur as a result of the kernel not being aware of the threads: any blocking system calls will result in all threads being halted until the call returns; the application may only execute on a single logical CPU. Major upsides to this model include simplier locking mechanisms and fewer memory consistency problems between threads.