The Windows Operating System has a number of key architectural concepts.  One of these is the concept of a thread because it forms a fundamental keystone of many of the tasks performed by the OS.

In Windows, a thread is a unit of execution.  This unit of execution is defined by the state of the processor at a given instant in time.  In a nutshell, it is all of the state information that is necessary to place a CPU in the same state.  Thus, it includes the values stored within the processor registers as well as memory presently used by the processor for state management.  Of course, the details of "processor state" really are machine dependent.

For example, with the x86 (IA-32) processor, the state of the processor includes the values stored in the general purpose registers (EAX, ECX, EDX, EBX,) the index registers (ESI and EDI,) the stack registers (ESP, EBP), the instruction pointer (EIP), segment registers (CS, DS, SS, ES, FS, and GS,) and machine state registers (EFLAGS, CRx registers).

If Windows decides to cease processing a particular thread and begin processing a different thread, it does so by storing the current processor state and then retrieving the processor state of the other thread.

One of the keys to this context is the stack.   This is because certain instructions rely upon the contents of the stack to process instructions.  For example the ret instruction on the x86 replaces the value in EIP with the value on the top of the stack.  Thus, when Windows changes the stack pointer (ESP) as part of switching threads and then executes a ret instruction, this results in the processor using the value on the stack as the instruction to execute next.  Thus, switching between threads can be done with the same code, but different stacks.

Threading in Windows is a fundamental part of the OS.  The low level part of the operating system (the micro-kernel) implements thread switching.  This, in turn, allows Windows to process different programs by switching between them as necessary.  If the computer has multiple processors, each processor is identical - at least in terms of its execution context - and thus the thread may be executed first on one processor and later on a different processor.  Note, however, that one thread may only be executing on one processor at one instant in time.  Yes, it could change processors from one instant to the next, but not on two processors at one instant.

Kernel drivers often must handle threading issues, because even though there are different execution contexts (register state and stacks) they may utilize the same code paths.  In other words, a single driver might be operating on behalf of multiple different threads at the same time.  For new kernel mode developers this might be very different than the environments to which they have become accustomed.  The advantage in the kernel environment is that it allows the OS to process many different requests, intermixing them as useful in order to optimize the overall performance of the system.

Thus, a thread is nothing more than the unit of execution used by Windows to perform tasks (or work) and provide useful services.