Primitive Concurrency in Elixir

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Timeline 1 2 3 4 Primitive Concurrency Generic Server Data Processing Actor Model We’re here

Slide 3

Slide 3 text

So, what are we gonna tackle now?

Slide 4

Slide 4 text

Concurrency Concurrency & Concurrency vs Parallelism 01 The VM & Processes Erlang is about writing high available systems - system that runs forever 02 Server Process An informal name for process that runs for a long time(or forever) 03 Runtime Considerations Some internal considerations about the BEAM 04

Slide 5

Slide 5 text

Who am I? Randson! I’m a software engineer, Writer, video editor. Interested in cartoon draw. - Back-end with Elixir; - Increasingly learning. Trying to make the world a better place to live, through technology.

Slide 6

Slide 6 text

Concurrency 01. Basic of Concurrency & Parallelism

Slide 7

Slide 7 text

Although they’re often used interchangeably, concurrent and parallel refer to related but different things. Concurrent or Parallel?

Slide 8

Slide 8 text

A concurrent program has many thread of control. These threads may or may not run in parallel. Related but Different

Slide 9

Slide 9 text

A parallel program may or may not have more than one logical thread of control. Related but Different

Slide 10

Slide 10 text

— Rob Pike Concurrency is about dealing with a lot of things at once. Parallelism is about doing a lot of things at once.

Slide 11

Slide 11 text

Concurrency & Parallelism are often confused because traditional thread and lock doesn’t directly support parallelism Beyond Sequential Execution

Slide 12

Slide 12 text

If you want to exploit multiple cores with thread and locks. Your only option is to create a concurrent program and then run it in a parallel hardware. Beyond Sequential Execution

Slide 13

Slide 13 text

Concurrent programs are often nondeterministic. They will give different results depending on the precise timing of events. Beyond Sequential Execution

Slide 14

Slide 14 text

Parallelism, by contrast, doesn’t necessarily imply nondeterminism. Languages that supports allows you to write parallel code without introducing the specter of nondeterminism. Beyond Sequential Execution

Slide 15

Slide 15 text

Concurrent How to Illustrate? Concurrent & Parallel Parallel

Slide 16

Slide 16 text

Concurrent What’s concurrency? And Parallelism(only)?

Slide 17

Slide 17 text

Concurrent & Parallel Elixir track Erlang track

Slide 18

Slide 18 text

Parallel Every is student is assigned to do a five christmas card!

Slide 19

Slide 19 text

— Rob Pike Concurrency is about dealing with a lot of things at once. Parallelism is about doing a lot of things at once.

Slide 20

Slide 20 text

Concurrency is not parallelism Explains the difference with Go channels examples. https://www.youtube.com/watch?v=oV9rvDllKEg

Slide 21

Slide 21 text

Processors have stopped getting faster. Using new hardware doesn’t mean you program will be fast. These days, if you need more performance, you need to exploit more processors and that means exploiting parallelism. These aren’t new, why so hot now?

Slide 22

Slide 22 text

Not at all. It allows you to create software that’s responsive, fault-tolerant, multi-region, and(if you’re in the right approach) simpler than traditional sequential software. Is it just about exploiting multiple cores?

Slide 23

Slide 23 text

Concurrent software for a concurrent world Beyond multiple cores

Slide 24

Slide 24 text

Distributed software for a distributed world Beyond multiple cores

Slide 25

Slide 25 text

Resilient software for a unpredictable world Beyond multiple cores

Slide 26

Slide 26 text

Simple software for a complex world Beyond multiple cores

Slide 27

Slide 27 text

Models 1 2 3 4 Threads & Locks Actors CSP Lambda And others…

Slide 28

Slide 28 text

It’s everywhere. Even client-side web programming is concurrent. I hope this talk can help you understand concurrency. ;) How will this affect me?

Slide 29

Slide 29 text

So, what about Elixir?

Slide 30

Slide 30 text

The VM & Process 02. Erlang is about writing high available systems - system that runs forever

Slide 31

Slide 31 text

What BEAM stand for? Is the Virtual Machine(VM) at the core of the framework Erlang Open Telecom Machine(OTP) It stands for Bjorn’s Erlang Abstract Machine. The predecessor of the BEAM was JAM and stands for Joe’s Abstract Machine(JAM). Created by Joe Armstrong.

Slide 32

Slide 32 text

High Availability To have a system that “runs forever” we have to tackle some things first: - Fault-Tolerance - Scalability - Distribution

Slide 33

Slide 33 text

Fault-tolerance Minimize, isolate, and recover from effects of runtime.

Slide 34

Slide 34 text

Scalability How to handle high load of data without re-deploying our code?

Slide 35

Slide 35 text

Distribution We can run our app in multiple machines(even if the machine isn’t in our continent).

Slide 36

Slide 36 text

Fault-tolerant How to achieve HA? Scalability Distribution

Slide 37

Slide 37 text

High Availability If we address these challenges, our systems can constantly provide service without downtime. Concurrency play an important role here. In BEAM, the unit of concurrency is a process.

Slide 38

Slide 38 text

Don't confuse BEAM process with OS process!

Slide 39

Slide 39 text

BEAM CPU/Scheduler OS Thread CPU/Scheduler OS Thread CPU/Scheduler OS Thread CPU/Scheduler OS Thread Process Process Process Process

Slide 40

Slide 40 text

BEAM Process Lightweight & Cheap OS Process Heavy & deals with more things

Slide 41

Slide 41 text

Process The basic concurrency primitive is called Erlang process. A typical erlang VM can run thousands or even millions of process. It only uses the available CPU cores, parallelizing execution as much as possible.

Slide 42

Slide 42 text

Process - Fault Tolerance They (processes) are completely isolated from each other. They don’t share any memory with another process running inside the VM. If something bad happens, it has only a local impact.

Slide 43

Slide 43 text

Process - Scalability Process communicate via asynchronous messages. A typical system in Erlang can be divided into a large number of concurrent processes. Erlang system is scalable because they can take advantage of all CPU.

Slide 44

Slide 44 text

Process - Distribution Communication works the same way regardless of where they were born. Process have a “mailbox” in which they can process messages inside. The mailbox is just a queue of messages inside of a process.

Slide 45

Slide 45 text

Process As you can see, concurrency is a crucial element in Erlang. With I/O operations happening, the VM delegates to separate threads/service the execution, not blocking it.

Slide 46

Slide 46 text

Erlang in Action

Slide 47

Slide 47 text

Server Process 03. Is Flow, GenStage or Broadway a choice to process data?

Slide 48

Slide 48 text

It’s common to have long-running process A simple process can serve millions of requests An informal name for a process that run for a long time (or forever) Server Process

Slide 49

Slide 49 text

Make use of endless tail recursion Not a problem for a function that run itself forever To implement a server process, you just need an endless loop Server Process

Slide 50

Slide 50 text

defmodule ServerProcess do def start, do: spawn(&loop/0) def loop do # process the message loop() end end

Slide 51

Slide 51 text

Keep a process internal state update while it’s alive Process messages coming from calls Messages are always sequential Server Process - You can:

Slide 52

Slide 52 text

pool = Enum.map(1..100, fn -> ServerProcess.start() end) Server Process

Slide 53

Slide 53 text

Each process has its own state They communicate with each other by messages You can have both mutable and immutable states Server Process - You can:

Slide 54

Slide 54 text

But be aware! Processes can fail and die

Slide 55

Slide 55 text

They’re isolated, so it’s not a problem for other processes currently running inside the VM Without proper treatment, the process dies losing its internal state Server Process

Slide 56

Slide 56 text

Which guides us to?

Slide 57

Slide 57 text

Runtime Considerations 04. Internal considerations about the BEAM

Slide 58

Slide 58 text

Runtime considerations Despite being the best type of concurrency, it still has some flaws The mailbox of a process may become a bottleneck which affects the overall throughput Maybe the flaws are related to how you organize your supervision tree

Slide 59

Slide 59 text

Runtime considerations A mailbox size of a process is limited by available memory If a process constantly falls, the mailbox will continuously increase causing a crash to the application Larger mailboxes can significantly affect performance.

Slide 60

Slide 60 text

Runtime considerations Always try to create a process that handles one thing alone

Slide 61

Slide 61 text

Thanks! Do you have any questions? orandson@gmail.com — https://rands0n.com

Slide 62

Slide 62 text

References - https://medium.com/platform-engineer/understanding-jvm-architecture-22c0ddf09722 - https://msdeep14.github.io/diff-os-erlang-process/ - https://www.manning.com/books/elixir-in-action-second-edition - https://pragprog.com/titles/pb7con/seven-concurrency-models-in-seven-weeks/

Slide 63

Slide 63 text

Thanks! orandson@gmail.com — https://rands0n.com