> 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/sincronizacao-com-locks.md).

# Sincronização com locks

O sistema operacional fornece algumas primitivas para construção de mecanismos de sincronização (locks), como **futex** e instruções atômicas. Entretanto, essas primitivas são muito genéricas e requerem uma implementação mais robusta de lock, pois o Kernel obedece um design minimalista e tenta não impor nenhum mecanismo de lock, deixando que diferentes linguagens de programação possam implementar diferentes tipos de locks.

Vários tipos de locks podem ser implementados, mas vamos explicar brevemente o conceito de dois: *spinlock e mutex*.

### Spinlock

Um lock baseado na técnica "busy-waiting", que é precisamente um loop onde a thread verifica o valor de uma variável compartilhada atomicamente. O spinlock não causa **troca de contexto** de threads, mas pode provocar um aumento do uso de CPU devido ao loop.

### Mutex

Mutex refere-se a *mutual exclusion*, ou **exclusão mútua**, onde a thread é colocada em um estado de (wait) até que o recurso seja liberado por outra thread (wake). Isto pode ser implementado por meio de *thread signaling*, que são basicamente sinais que podemos enviar às threads.

A vantagem é que a CPU não é consumida durante o tempo de espera da thread, porém há uma latência maior devido à **troca de contexto** das threads. E também pode-se gerar um problema onde duas ou mais threads ficam bloqueadas pra sempre por conta de um lock mal utilizado ou "perdido", que se chama **deadlock**.

<figure><img src="/files/XqKWw2arnD5H5LLnwrvF" alt="" width="258"><figcaption></figcaption></figure>

&#x20;Com mutex, podemos fazer com que a thread que chegou primeiro tenha acesso exclusivo ao recurso. Qualquer outra thread que tentar acessar o mesmo recurso, **seja pra leitura ou escrita**, vai ter que esperar o lock ser liberado...

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

Existem outros tipos de locks, como **semáforos e rwlocks**, mas por enquanto vamos deixar apenas esses dois, pelo que na segunda parte do guia abordaremos em detalhes a implementação de locks em cada linguagem.

***

Entretanto, podemos implementar alternativas em cenários de concorrência de modo a evitar o uso de locks. Quando o compartilhamento de memória e uso de locks passa a ser um grande problema, uma alternativa é implementar algumas "peças" de concorrência onde o e**stado não é compartilhado** e a comunicação entre diferentes peças passa a ser através do **envio de mensagens**.\
\
Estamos falando do **modelo de atores**.
