Share
Embed
Transcript
63 slides
-
Timeline 1 2 3 4 Primitive Concurrency Generic Server Data
Processing Actor Model We’re here -
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 -
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. -
Although they’re often used interchangeably, concurrent and parallel refer to
related but different things. Concurrent or Parallel? -
A concurrent program has many thread of control. These threads
may or may not run in parallel. Related but Different -
A parallel program may or may not have more than
one logical thread of control. Related but Different -
— Rob Pike Concurrency is about dealing with a lot
of things at once. Parallelism is about doing a lot of things at once. -
Concurrency & Parallelism are often confused because traditional thread and
lock doesn’t directly support parallelism Beyond Sequential Execution -
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 -
Concurrent programs are often nondeterministic. They will give different results
depending on the precise timing of events. Beyond Sequential Execution -
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 -
Parallel Every is student is assigned to do a five
christmas card! -
— Rob Pike Concurrency is about dealing with a lot
of things at once. Parallelism is about doing a lot of things at once. -
Concurrency is not parallelism Explains the difference with Go channels
examples. https://www.youtube.com/watch?v=oV9rvDllKEg -
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? -
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? -
Models 1 2 3 4 Threads & Locks Actors CSP
Lambda And others… -
It’s everywhere. Even client-side web programming is concurrent. I hope
this talk can help you understand concurrency. ;) How will this affect me? -
The VM & Process 02. Erlang is about writing high
available systems - system that runs forever -
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. -
High Availability To have a system that “runs forever” we
have to tackle some things first: - Fault-Tolerance - Scalability - Distribution -
Distribution We can run our app in multiple machines(even if
the machine isn’t in our continent). -
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. -
BEAM CPU/Scheduler OS Thread CPU/Scheduler OS Thread CPU/Scheduler OS Thread
CPU/Scheduler OS Thread Process Process Process Process -
BEAM Process Lightweight & Cheap OS Process Heavy & deals
with more things -
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. -
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. -
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. -
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. -
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. -
Server Process 03. Is Flow, GenStage or Broadway a choice
to process data? -
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 -
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 -
defmodule ServerProcess do def start, do: spawn(&loop/0) def loop do
# process the message loop() end end -
Keep a process internal state update while it’s alive Process
messages coming from calls Messages are always sequential Server Process - You can: -
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: -
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 -
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 -
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.