> 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="https://1347906346-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FADWkcUWoXJQdqxwxxE7z%2Fuploads%2Fy6trlOW7uYgt3lkdBok1%2FScreenshot%202024-12-22%20at%2020.44.33.png?alt=media&amp;token=8571745f-9963-474e-a189-018c291d2fc3" 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