Erlang for Soft
Real-Time IoT Applications
Geovane Fedrecheski
Universidade de São Paulo
Escola Politécnica da USP
geonnave@gmail.com | geovane@lsi.usp.br
Summary
- Erlang programming language
- Soft Real-Time
- Research on Hard Real-Time
- Conclusions
Erlang
- In early 80s, Ericsson Telecom engineers found no programming language suited to attend:
- Fault-tolerance (and hence distribution)
- High-availability
- Soft Real-Time
- Hot code swapping
Then they created Erlang
Erlang
Runs in the BEAM (Bjarne's Erlang Abstract Machine) Virtual Machine
- Distributed
- Fault-tolerant
- Soft Real-Time
- Hot swapping
- Functional language
- Immutability
- Isolated processes
- Message passing
Other ! {self(), 10}. % async send
receive % block *this* process
{Other, NewNumber} ->
io:format("got ~d", [NewNumber])
after % timeout
5000 -> halt()
end.
receive % process "Other" is waiting a message
{Origin, Number} ->
Origin ! {self(), Number * -1}
end.
OTP
(Open Telecom Platform)
supervisor
gen_server
gen_fsm
fault-tolerance
hot swapping
Processes
or, Erlang's "objects"
in-VM,
user-land processes!
communicate via message passing
Fault-tolerance
Soft Real-Time
-
All principles of Hard Real Time except
- A missed deadline does not represent a failure
- It is just considered "less good"
- Low chance of timeouts is acceptable (e.g the system will be timely 97% of the times)
Examples:
- Telephony systems
- Video games
- Internet of Things
a mix of
web and embedded devices
so, how does Erlang fits
with soft real-time?
- Its Runtime System was made with this in mind:
- "phone calls shall behave like a real-life conversation, but if lag appears, (hopefully) nobody is going to die"
- Another thing is that they wanted an alternative to C.
Garbage Collection
private memory (stack, heap)
per-process generational GC
Java serial and Concurrent GC
still nondeterministic, but better than stop-the-world GCs
Scheduler
Preemptive
round-robin, preempt at ~2000 reductions
Four priority levels:
- Low
- Normal
- High
- Max (reserved)
Erlang Runtime Sytem =~ Operating System
run queue low
Scheduler
blocked waiting processes
in-queue waiting
Running
blocked waiting
run queue normal
Problems with Erlang native scheduler
- No deadline spec for processes
- Starvation may occur when using high and normal priority with strange spawning patterns
Solution: HARTE a Hard Real-Time scheduler to run as a service in the BEAM
- accepts tasks and put on queue as LOW priority
- use a Deadline Monotonic scheduling algorithm
- modifies the priority of the task to be run as HIGH
Research
Conclusions
- Erlang's core features for Soft Real-Time are:
- Per-process garbage collection
- Preemptive scheduler
- If it were to be Hard Real-Time, problems to solve are:
- A strictier scheduler
- A deterministic GC
- Real time message passing
Conclusions
IoT:
- Not all applications require Hard Real-Time boundaries
- Network is always a weak point on latency
- Using Erlang as high level, "best-effort" Real-Time platform seems reasonable
Obrigado!
Appendix
"Leverages Erlang VM, while also being successfully used in web development and the embedded software domain"
% hello.erl
-module(hello).
-compile(export_all).
hello() ->
io:format("~s~n", ["Hello world!"]).
# hello.ex
defmodule Hello do
def hello do
IO.puts "Hello World"
end
end
- Macros
- Polimorfism
- Tooling
- Erlang compatible (w/o run-time cost)
Copy of Erlang built-in techniques for building soft real time Applications
By Geovane Fedrecheski
Copy of Erlang built-in techniques for building soft real time Applications
- 562