> For the complete documentation index, see [llms.txt](https://concorrencia101.leandronsp.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://concorrencia101.leandronsp.com/parte-i-concorrencia-no-sistema-operacional/principais-desafios-em-cenario-de-concorrencia/race-condition.md).

# Race condition

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*.

<figure><img src="/files/ipc5z4nrDQP55H4SHJHV" alt="" width="563"><figcaption></figcaption></figure>

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

## 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.&#x20;

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