a thread

Imagine a busy kitchen run by one cook working from a single recipe. The cook can do only one step at a time, so the salad sits untouched while the soup simmers. Now imagine that same kitchen, same recipe, same pantry and same stove, but with three cooks who all read from the one recipe and share the one pantry. Each cook keeps their own little notepad of where they are in the steps, and the three of them make progress side by side. A thread is one of those cooks: a single, sequential flow of execution that lives inside a running program and shares almost everything with the other threads in that program.

More precisely, a thread is the smallest unit the operating system can actually schedule onto a CPU. Every thread inside a process shares that process's code (the program's instructions), its global data, its heap (the pool of memory the program allocates as it runs), and its open files and other resources. But each thread has its own private pieces: its own stack (for local variables and the chain of function calls it is in the middle of), its own set of CPU registers, and its own program counter, which is just a pointer to the next instruction this particular flow will run. So all threads see the same shared memory, but each one remembers its own place in the work. When the OS switches the CPU from one thread to another, it saves this small private state and loads the next thread's.

Why this matters: because threads share memory, two threads can hand data to each other simply by writing and reading the same variable, with no copying and no kernel round-trip. That sharing is exactly what makes threads powerful and exactly what makes them dangerous. If two threads touch the same variable at the same time without coordinating, the result is a race condition and the program can produce wrong or random answers. Making that sharing safe (locks, semaphores, and so on) is the job of synchronization, a separate topic; a thread by itself gives you concurrency, not safety.