concorrencia101
  • Introdução
  • First things first
  • Agradecimentos
  • Parte I - Concorrência no sistema operacional
    • O que é o programa no sistema operacional
    • Escalonador preemptivo de tarefas
    • Uma nota sobre escalonamento cooperativo
    • Propriedades de um processo
    • Clone de processo (forking)
    • Clone leve de processo (thread)
    • Todo processo tem uma thread principal
    • Uma nota sobre paralelismo
    • Principais desafios em cenário de concorrência
      • Race condition
      • Sincronização com locks
      • Modelo de atores
    • E o I/O?
      • Latência de CPU vs Latência de I/O
      • Chamadas bloqueantes
      • Chamadas não-bloqueantes
      • Assincronismo e escalonamento cooperativo
    • Vamos colocar em prática...
  • PARTE II - Concorrência em diferentes linguagens
    • Definindo ambientes de execução
    • Concorrência em C
      • Forking de processos
      • Threads
      • Race condition e sincronização de threads com mutex
      • Desafios com o uso de threads
      • Thread Pool em C
      • Green threads
      • Modelo de Atores
      • Trabalhando com I/O
    • Concorrência em Ruby
      • Forking de processos
      • Threads
      • Race condition, YARV, GVL e paralelismo em Ruby
      • Modelo de Atores
      • Trabalhando com I/O
Powered by GitBook
On this page
  1. Parte I - Concorrência no sistema operacional
  2. Principais desafios em cenário de concorrência

Race condition

PreviousPrincipais desafios em cenário de concorrênciaNextSincronização com locks

Last updated 4 months ago

Se nosso programa tem 2 threads que fazem uso de um recurso compartilhado (como memória ou até mesmo arquivo no disco), e o estado final do recurso compartilhado depende da ordem de execução das threads, então temos um problema de race condition, ou condição de corrida.

Condição de corrida é um problema devido ao uso de concorrência, pois não conseguimos determinar se e quando uma thread será executada.

Quando race conditions se tornam data races

Quando o recurso compartilhado for a memória do programa, e uma das threads estiver tentando fazer uma operação de escrita, podemos ter uma sub-categoria mais específica de race condition que é data race.

Data races são mais graves pois podem gerar corrupção na memória do programa, afetando seu funcionamento e até causando segmentation fault dependendo do caso. Para evitar data races, o uso correto de mutexes, semáforos ou barreiras deve ser levado em conta.


Sabendo dos problemas inerentes a concorrência, temos que ter em mente que, sempre que tivermos um cenário de race condition, precisamos sincronizar o acesso ao recurso.

E a sincronização precisa ser feita mediante a implementação de locks.