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)

Erlang built-in techniques for building soft real time Applications

By Geovane Fedrecheski

Made with Slides.com

Erlang built-in techniques for building soft real time Applications

  • 536

More from Geovane Fedrecheski