# 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="https://1347906346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FADWkcUWoXJQdqxwxxE7z%2Fuploads%2F2ZspFQd3En9hAemGd84Q%2FScreenshot%202024-11-29%20at%2001.04.20.png?alt=media&#x26;token=470a6638-5153-4a1d-bdbf-edd754c19139" 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.**