Threads are closely related to processes. A process is a program loaded into memory, complete with all the resources assigned to the program, but a process is static and does nothing by itself.
A thread executes program commands, following a path through the code. Every process possesses one initial thread. Optionally, the initial thread (also called the primary thread) may create other threads. All the threads belonging to one process share the assets of that process. They all follow instructions from the same code image, refer to the same global variables, write to the same private address space, and have access to the same objects. Think of a process as being house that is inhabited by threads.
While an operation without threads does accomplish similar tasks, the process of doing so is less versatile. For a single-threaded application, initiating a subprocess (or child process) requires temporarily tabling the main process and only resuming when the subprocess is completed. In earlier versions of Windows, all applications were single-threaded of necessity, even though Windows itself performed something like a multithreaded process—sharing processor time among multiple applications so each had its own chance to execute.
At the same time, background processes—such as spell-checking, image-rendering, or file maintenance—are often relegated to low priority while GUI processes, which are immediately visible to the user, take precedence. Without threads, the allocation of resources often results in a slow response from the GUI elements when tasks of this nature do become active. Threads, while not in themselves a cure-all, do permit a smoother time-share in such circumstances.