O que você vai aprender
Diferenciar processos e threads.
Comparar threads de usuário e de núcleo.
Distinguir concorrência de paralelismo em hardware multicore.
Aplicar a Lei de Amdahl para estimar ganhos.
Um processo, várias frentes de trabalho
Um servidor web atende milhares de clientes; um jogo calcula física, IA e som ao mesmo tempo. Criar um processo inteiro para cada tarefa seria caro — cada um com seu espaço de endereçamento e PCB pesado.
As threads resolvem isso: vários fluxos de execução dentro de um mesmo processo, compartilhando memória, mais leves de criar e trocar. E com multicore, podem rodar de fato em paralelo.
Roteiro da aula
núcleo→Concorrência ×
paralelismo→Lei de
Amdahl
Definiremos thread, compararemos os modelos de implementação e separaremos dois conceitos sempre confundidos: concorrência e paralelismo.
O que é uma thread
O que é compartilhado e o que é privado
A divisão entre compartilhado e privado é o coração das threads:
- Compartilhado entre as threads: o código, os dados globais e a heap, os arquivos abertos, o espaço de endereçamento.
- Privado de cada thread: a pilha (variáveis locais e chamadas), os registradores e o contador de programa.
Esse compartilhamento é o que torna threads poderosas (comunicação por memória, sem cópias) e perigosas (condições de corrida — tema da Aula 6).
Processo vs. thread em números
| Aspecto | Processo | Thread |
|---|---|---|
| Espaço de endereçamento | Próprio | Compartilhado |
| Custo de criação | Alto | Baixo |
| Custo de troca | Alto (esfria TLB) | Menor (mesma TLB) |
| Comunicação | IPC (pipes, mensagens) | Memória compartilhada direta |
| Isolamento | Forte | Fraco (uma derruba o processo) |
Passo a passo: somando um vetor com threads
Threads de usuário e de núcleo
Thread de núcleo. Conhecida e escalonada pelo próprio SO, mapeável a cores físicos.
Implicações de cada modelo
| Usuário | Núcleo | |
|---|---|---|
| Quem gerencia | Biblioteca, sem o SO saber | O próprio SO |
| Troca | Rápida (sem syscall) | Mais cara (entra no kernel) |
| Bloqueio em E/S | Bloqueia todo o processo | Bloqueia só a thread |
| Paralelismo real | Não (1 core por processo) | Sim (mapeáveis a vários cores) |
O escritório e os funcionários
Concorrência vs. paralelismo
| Aspecto | Concorrência | Paralelismo |
|---|---|---|
| Definição | Tarefas em progresso no mesmo intervalo | Tarefas executando ao mesmo tempo |
| Hardware mínimo | 1 core (intercalado) | Múltiplos cores |
| Natureza | Estrutural (como organizar) | De execução (simultaneidade real) |
| Exemplo | Multitarefa num core | 4 threads em 4 cores |
Paralelismo. Várias tarefas executando ao mesmo tempo, em cores diferentes.
De concorrência a paralelismo
concorrentes→Trabalho
divisível?→Mapear a
vários cores→Paralelismo
real
A Lei de Amdahl
Exemplo: se 90% paraleliza (p = 0,9), o ganho máximo é 1/(0,1) = 10×, por mais cores que se adicione. Se só 50% paraleliza, o teto é 2×. A parte sequencial é o gargalo — por isso reduzir a fração sequencial costuma render mais que somar cores.
Verifique seu entendimento
Com threads de usuário puras (muitos-para-um), uma chamada de E/S bloqueante de uma thread:
Multicore embarcado: o ESP32
O microcontrolador ESP32, popular em IoT, traz dois núcleos. O FreeRTOS rodando nele permite fixar tarefas a um núcleo específico (afinidade): por exemplo, a pilha Wi-Fi em um core e a aplicação no outro, evitando que o rádio interfira nos prazos da aplicação.
É um exemplo concreto de paralelismo de verdade em embarcado: duas tarefas executam ao mesmo tempo, e a separação por core melhora o determinismo — concorrência transformada em paralelismo controlado.
Armadilhas conceituais
• Tratar concorrência e paralelismo como sinônimos — um é estrutura, o outro é execução simultânea.
• Esperar ganho linear ao adicionar cores — Amdahl limita pelo trecho sequencial.
• Esquecer que memória compartilhada entre threads exige sincronização (Aula 6), ou surgem condições de corrida.
Quando vale paralelizar
Revele o cálculo
Se 80% de um programa paraleliza, qual o ganho máximo com infinitos cores?
Revisão relâmpago
Para onde isto leva
As threads abrem caminho para:
- A sincronização e as condições de corrida (Aula 6), inevitáveis com memória compartilhada.
- O escalonamento de múltiplas threads em vários cores (Aula 5).
- O custo de troca de contexto (Aula 3), do qual as threads se beneficiam por não esfriarem a TLB.
Resumo da aula
Atividade em grupo · Paralelizar ou não?
Em trios, avaliem quais tarefas ganham com paralelismo em hardware multicore.
Roteiro
- Listem 4 tarefas: somar um vetor grande, ler um arquivo sequencial, renderizar quadros, atualizar uma variável compartilhada.
- Classifiquem cada uma: ganha com paralelismo? Por quê?
- Identifiquem onde a parte sequencial limita o ganho (Amdahl).
- Discutam o risco de condições de corrida na tarefa compartilhada.
Mini-quiz · Aula 4
20 questões sobre esta aula. Escolha e veja a explicação na hora.
📌 Resumo — leve isto para a prova
- Threads compartilham o espaço do processo; têm pilha e registradores próprios.
- Threads de núcleo permitem paralelismo real e bloqueio independente.
- Concorrência é estrutura; paralelismo é execução simultânea em multicore.
- A Lei de Amdahl limita o ganho pela fração sequencial (teto = 1/(1−p)).
- Memória compartilhada exige sincronização para evitar condições de corrida.