What is a thread and how does it differ from a process?

Published on 2026-10-20 by frfrand

Hilos y procesos explicados con ejemplos: memoria compartida, concurrencia, paralelismo, bloqueos y cuándo conviene usar cada uno.

A thread is a unit of execution within a process. The same program can have several threads working concurrently and sharing an important part of their resources, such as process memory.

The difference with an independent process matters when designing servers, desktop applications, or tasks that need to do several things at once.

The example of a restaurant

Imagine a restaurant. A complete kitchen can represent a process, while several people working inside that kitchen represent threads.

They share ingredients, tools, and space, which facilitates collaboration. But if two people modify the same order list at the same time without coordinating, they can produce errors.

A different process is more like another kitchen with its own resources, although both can communicate and share certain services.

How do processes and threads differ?

Processes usually have isolated memory spaces from each other, while threads of the same process share memory and other resources.

That shared memory allows exchanging information quickly, but it also introduces risks: two threads could modify the same value simultaneously and leave it in an unexpected state.

That is why concurrent programming uses mechanisms such as locks, semaphores, and communication queues.

Is concurrency the same as parallelism?

Not exactly. Concurrency means organizing several tasks so that they progress during a common period. Parallelism implies executing work simultaneously on different processing resources.

A person can cook two dishes by alternating steps: there is concurrency, but not two people cooking at the same time. With two cooks there could be parallelism.

The operating system, the programming language, and the hardware influence how threads actually execute.

What are threads for?

They can be useful in servers that handle multiple operations, programs with interfaces that must not become blocked, and tasks that wait for network or disk responses.

For example, an application can keep its interface available while another part waits to download information. But it does not mean that any work is sped up by multiplying threads.

Tasks that consume CPU intensively may have different limits depending on the language and the runtime.

What about Python and the GIL?

In typical CPython implementations, there is a mechanism called Global Interpreter Lock (GIL) that affects the simultaneous execution of Python bytecode in traditional configurations.

That explains why creating many threads in Python usually does not speed up CPU-intensive calculations linearly. For certain jobs, multiple processes or specialized extensions are used.

The Python ecosystem is also evolving with no-GIL compilation options. That is why it is worth checking the version and configuration your application actually uses instead of repeating absolute rules.

What is a race condition?

It occurs when the outcome of a program depends on an execution order that is not properly controlled.

For example, two threads read that ten units of stock remain and both try to reserve the last one. If the logic is not synchronized or does not use correct transactions, an inconsistency can occur.

It is not necessarily solved by using fewer threads: access to shared resources must be designed well.

When is it worth using separate processes?

When you need stronger isolation, want to take advantage of multiple cores in certain runtimes, or run components with different responsibilities.

However, processes also require communication and can consume more resources. The decision depends on the workload, the language, and the level of isolation needed.

Do more threads mean more performance?

Not always. Too many threads can increase context switches, memory usage, and coordination. If they all wait for the same database, creating one hundred threads will not eliminate the bottleneck.

It is worth measuring before increasing concurrency and setting appropriate limits for each load.

And in ArduMaker?

Services deployed within an ArduMaker VPS can use processes, threads, or workers depending on how each application is developed. The infrastructure provides resources; choosing the right concurrency model is part of backend design.

In short: a process is an execution environment and a thread is a unit of work within it. They share advantages and risks worth understanding before attempting to speed up an application.

Sources: Python threading module · What is a kernel in ArduMaker.