> 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/modelo-de-atores.md).

# Modelo de atores

Com modelo de atores podemos modelar nosso sistema concorrente onde cada unidade de execução é um ator:

* possui identificação única
* possui estado privado (não compartilha estado), ou seja, apenas o ator é responsável por modificar seu estado interno
* se comunica através do envio de mensagens, seja por meio de canais, filas, etc

<figure><img src="/files/4JefWfLeVsTcO0Jvd52a" alt=""><figcaption></figcaption></figure>

Como podemos ver na imagem acima, é possível concluir que um ator é  bastante semelhante a um *objeto em OOP*.

> Me perdoem

A grande diferença é que o *ator é feito exclusivamente para cenários de concorrência*, onde a implementação do ator pode ser baseada tanto em kernel threads quanto user threads, caso o runtime tenha a implementação.

O ponto principal para entendermos aqui é que o **estado não é compartilhado**, ou seja, é como se tivéssemos uma cópia única de todos os atributos do ator em diferentes threads mas com diferentes valores, aumentando assim o uso de memória total do sistema.

Com atores, *eliminamos* a necessidade de sincronização com locks.

> Há vantagens e desvantagens em ambas as abordagens, lembre-se de que não existe bala de prata