A simple analogy: process = train, thread = carriage. Threads run within a process (
a carriage on its own cannot move). A process can contain multiple threads (a train can have multiple carriages)
Data is hard to share between different processes (passengers on one train find it hard to switch to another train, e.g. when transferring at a station)
Data is easy to share between threads of the same process (moving from carriage A to carriage B is easy)
Processes consume more computer resources than threads (running several trains costs more than adding several carriages)
Processes do not affect one another, but one thread crashing brings down the whole process (one train does not affect another, but if a carriage in the middle of a train catches fire, all its carriages are affected)
Processes can scale out to multiple machines, while threads are at most suited to multiple cores (different trains can run on multiple tracks, but carriages of the same train cannot run on different tracks)
Memory addresses used by a process can be locked, i.e. when one thread is using some shared memory, other threads must wait until it is done before using that memory (like the toilet on a train) — “mutex”. Memory addresses used by a process can be limited in how many may use them (like the dining car on a train, which only lets in a certain number of people; if it is full, you wait at the door until someone comes out) — “semaphore”