O documento discute a concorrência em programação, comparando modelos como o de Erlang e Go, e a importância de evitar condições de corrida. Ele explora como Erlang, com seu modelo de ator, permite a criação de processos leves que se comunicam por mensagens sem compartilhar estado, o que facilita a concorrência e a resiliência. Além disso, menciona práticas de programação e possíveis problemas associados aos diferentes modelos de concorrência.

1. enfrentando os demônios da
programação moderna

2. Episódio I
O Diabo da Concorrência
| “In a concurrent world, imperative is the wrong default.”
Tim Sweeney, CEO da Epic Games

3. O que é concorrência?

4. O que é concorrência?

5. O que é concorrência?

6. Concorrência x Paralelismo

7. Concorrência x Paralelismo

8. *meramente ilustrativo, não é bem assim
Process e Thread

9. Race Condition

10. ● Dependência de várias tasks de um dado em comum
● Não-determinístico
Race Condition 🏃🏾♀️

11. Race Condition 🏃🏾♀️

12. CRuby: Global Virtual Machine Lock (GVL)
Evitando Race Condition ✋🏾🏃🏾♀️

13. Evitando Race Condition ✋🏾🏃🏾♀️
Node.JS: Event Loop

14. Como evitar esses problemas?
● Boas práticas (encapsular o estado, etc)?
● Evitar concorrência?
● Trabalhar com forks de aplicação
● …?

15. Ruby
Javascript

16. E se a gente só não
compartilhasse estado?

17. E se a gente só não
compartilhasse estado?
Tipo, de verdade? 🤯

18. Episódio II
De Volta para o Futuro
| “Reject modernity; embrace tradition.”
Algum conservador no twitter

19. Erlang
● Quase 40 anos de existência
● Pensada para resolver problemas de alta disponibilidade em telecom:
○ Distribuição
○ Tolerância a Falhas
BEAM
● Máquina virtual do Erlang
● Modelo de runtime desenhado para resolver os problemas citados

20. Actor Model
(bem, mais ou menos…)

21. Processos: Erlang Actors
● Unidades vivas e encapsuladas (como Processos do SO)
● Tudo é um Processo
● Se comunicam por meio de mensagens
● Não compartilham memória (!!!!)
● São muito leves (rodando em uma máquina comum pode chegar a milhões de processos)!
● Caso não consigam fazer o que precisam, eles morrem 💣

22. Actors

23. Mensagens de processos e Mailboxes ✉
● Mensagens podem ser qualquer coisa (um inteiro, um `map` ou até uma função)
● São não-bloqueantes
● Sabendo o id do processo (ou o nome dele), é possível enviar mensagens para qualquer um
● O processo destinatário nem precisa estar na mesma máquina que o remetente (!)

24. Coding Time! 💻

25. Se um processo der erro?
Podemos supervisionar processos!

26. Coding Time! 💻

27. Então, se processos são...
● Atômicos
● Se comunicam por mensagens
● Não compartilham estado

28. Então, se processos são...
● Atômicos
● Se comunicam por mensagens
● Não compartilham estado
Quer dizer que podemos fazer um
código concorrente de verdade? 🤔

29. SIM!
Não só concorrente,
mas paralelo também!

31. Um processo pode ocupar uma
thread indefinidamente?
Não. Isso é chamado de preemptive
scheduling

32. “o que linguagens fazem por segurança
de memória (como GC), Elixir também
faz por segurança de concorrência”
.
— Nathan Long em Elixir is Safe

33. Na prática,
quando vou usar isso?

34. Na prática,
quando vou usar isso?
Bem, não todo dia…

35. Na prática,
quando vou usar isso?
Bem, não todo dia…
Mas…

36. Em Elixir/Erlang, tudo é processo
Teste de websockets. Conexões simultâneas
Inclusive conexões com o servidor, por exemplo :)

37. E o ?

38. Concorrência em Go: CSP, Channels e Goroutines
Sender(s) Receiver(s)

39. Características
● Implementação em semáforos
● Arquitetura de threads parecida com a do Erlang
● Co-operative scheduling
● Goroutines são opcionais da linguagem
● Simples de implementar: `go func()`

40. Possíveis problemas
● Co-operative scheduling == block?
● Estado compartilhado ainda é possível
● Não há comunicação entre nodes
● Comunicação em channels não é 100% async
● Goroutines não se conhecem

41. Go e erlang possuem focos diferentes
● Golang:
○ Rápido deploy e execução
○ Fácil adoção
● Erlang/Elixir:
○ Tolerância a falhas
○ Distribuição
Em Go, concorrência é um detalhe de design;
em Erlang, é o ponto central da arquitetura
.

42. Finalizando...

43. Erlang e Beam: concorrência + resiliência by design
● Processos isolados e Actor Model*
● Preemptive Scheduling
● Árvore de Supervisão
● OTP
● Funcional

44. Pera, funcional?! 😥

45. Continua...
os alquimistas estão chegando 🤔

46. Referências
- Exploring Ruby’s Multi-threaded Weirdness (21/03/2021)
- Introdução ao Node.js (Single-Thread, Event-Loop e mercado) (19/03/2021)
- Frequently Asked Questions about Erlang (21/03/2021)
- JURIC, Sasa. Elixir in Action, 2019
- Erlang Scheduler Details and Why It Matters (21/03/2021)
- Who Supervises The Supervisors? (22/03/2021)
- Elixir is Safe (07/04/2021)
- Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby (22/03/2021)
- COSTA, Gabriel et al. Escalabilidade de sistemas web em diferentes arquiteturas. TCC. 2020. (22/03/2021)
- Effective Go - The Go Programming Language (04/04/2021)
- Go vs Elixir: A concurrency comparison (03/04/2021)